Is it worth to use slf4j with log4j2









up vote
60
down vote

favorite
24












I am not able to decide whether to use slf4j or not with log4j2. Based on online posts, does not look like it will have any performance hit but is it really required.



Also these points rule in favor of log4j2:



  • SLF4J forces your application to log Strings. The Log4j 2 API supports logging any CharSequence if you want to log text, but also supports logging any Object as is.

  • The Log4j 2 API offers support for logging Message objects, Java 8 lambda expressions and garbage-free logging (it avoids creating vararg arrays and avoids creating Strings when logging CharSequence objects).









share|improve this question



















  • 1




    Maybe. What if my application server includes slf4j and logback (or log4jv1)? Should I then be forced to install a third logger to use your application? Or maybe corporate security decides you may only use java.util.logging in production, what then?
    – Elliott Frisch
    Jan 6 '17 at 2:45











  • Thanks for writing. But, if every one is using log4j org wide the above argument will not hold valid.
    – Andy897
    Jan 6 '17 at 2:48






  • 3




    Using SLF4J means that replacing the implementation is very easy if company policy changes, e.g. when your company is acquired and new policies forced on you. Using SLF4J now, when you write the code, will take no more time than using Log4j directly. Replacing direct Log4j calls later will take a lot of time. SLF4J is a free investment/insurance for the future. Is that more important than Log4j 2 API features? Only you (or company policy) can decide that.
    – Andreas
    Jan 6 '17 at 3:08















up vote
60
down vote

favorite
24












I am not able to decide whether to use slf4j or not with log4j2. Based on online posts, does not look like it will have any performance hit but is it really required.



Also these points rule in favor of log4j2:



  • SLF4J forces your application to log Strings. The Log4j 2 API supports logging any CharSequence if you want to log text, but also supports logging any Object as is.

  • The Log4j 2 API offers support for logging Message objects, Java 8 lambda expressions and garbage-free logging (it avoids creating vararg arrays and avoids creating Strings when logging CharSequence objects).









share|improve this question



















  • 1




    Maybe. What if my application server includes slf4j and logback (or log4jv1)? Should I then be forced to install a third logger to use your application? Or maybe corporate security decides you may only use java.util.logging in production, what then?
    – Elliott Frisch
    Jan 6 '17 at 2:45











  • Thanks for writing. But, if every one is using log4j org wide the above argument will not hold valid.
    – Andy897
    Jan 6 '17 at 2:48






  • 3




    Using SLF4J means that replacing the implementation is very easy if company policy changes, e.g. when your company is acquired and new policies forced on you. Using SLF4J now, when you write the code, will take no more time than using Log4j directly. Replacing direct Log4j calls later will take a lot of time. SLF4J is a free investment/insurance for the future. Is that more important than Log4j 2 API features? Only you (or company policy) can decide that.
    – Andreas
    Jan 6 '17 at 3:08













up vote
60
down vote

favorite
24









up vote
60
down vote

favorite
24






24





I am not able to decide whether to use slf4j or not with log4j2. Based on online posts, does not look like it will have any performance hit but is it really required.



Also these points rule in favor of log4j2:



  • SLF4J forces your application to log Strings. The Log4j 2 API supports logging any CharSequence if you want to log text, but also supports logging any Object as is.

  • The Log4j 2 API offers support for logging Message objects, Java 8 lambda expressions and garbage-free logging (it avoids creating vararg arrays and avoids creating Strings when logging CharSequence objects).









share|improve this question















I am not able to decide whether to use slf4j or not with log4j2. Based on online posts, does not look like it will have any performance hit but is it really required.



Also these points rule in favor of log4j2:



  • SLF4J forces your application to log Strings. The Log4j 2 API supports logging any CharSequence if you want to log text, but also supports logging any Object as is.

  • The Log4j 2 API offers support for logging Message objects, Java 8 lambda expressions and garbage-free logging (it avoids creating vararg arrays and avoids creating Strings when logging CharSequence objects).






java logging log4j slf4j log4j2






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 7 '17 at 9:28









Remko Popma

19.4k64971




19.4k64971










asked Jan 6 '17 at 2:31









Andy897

2,50332864




2,50332864







  • 1




    Maybe. What if my application server includes slf4j and logback (or log4jv1)? Should I then be forced to install a third logger to use your application? Or maybe corporate security decides you may only use java.util.logging in production, what then?
    – Elliott Frisch
    Jan 6 '17 at 2:45











  • Thanks for writing. But, if every one is using log4j org wide the above argument will not hold valid.
    – Andy897
    Jan 6 '17 at 2:48






  • 3




    Using SLF4J means that replacing the implementation is very easy if company policy changes, e.g. when your company is acquired and new policies forced on you. Using SLF4J now, when you write the code, will take no more time than using Log4j directly. Replacing direct Log4j calls later will take a lot of time. SLF4J is a free investment/insurance for the future. Is that more important than Log4j 2 API features? Only you (or company policy) can decide that.
    – Andreas
    Jan 6 '17 at 3:08













  • 1




    Maybe. What if my application server includes slf4j and logback (or log4jv1)? Should I then be forced to install a third logger to use your application? Or maybe corporate security decides you may only use java.util.logging in production, what then?
    – Elliott Frisch
    Jan 6 '17 at 2:45











  • Thanks for writing. But, if every one is using log4j org wide the above argument will not hold valid.
    – Andy897
    Jan 6 '17 at 2:48






  • 3




    Using SLF4J means that replacing the implementation is very easy if company policy changes, e.g. when your company is acquired and new policies forced on you. Using SLF4J now, when you write the code, will take no more time than using Log4j directly. Replacing direct Log4j calls later will take a lot of time. SLF4J is a free investment/insurance for the future. Is that more important than Log4j 2 API features? Only you (or company policy) can decide that.
    – Andreas
    Jan 6 '17 at 3:08








1




1




Maybe. What if my application server includes slf4j and logback (or log4jv1)? Should I then be forced to install a third logger to use your application? Or maybe corporate security decides you may only use java.util.logging in production, what then?
– Elliott Frisch
Jan 6 '17 at 2:45





Maybe. What if my application server includes slf4j and logback (or log4jv1)? Should I then be forced to install a third logger to use your application? Or maybe corporate security decides you may only use java.util.logging in production, what then?
– Elliott Frisch
Jan 6 '17 at 2:45













Thanks for writing. But, if every one is using log4j org wide the above argument will not hold valid.
– Andy897
Jan 6 '17 at 2:48




Thanks for writing. But, if every one is using log4j org wide the above argument will not hold valid.
– Andy897
Jan 6 '17 at 2:48




3




3




Using SLF4J means that replacing the implementation is very easy if company policy changes, e.g. when your company is acquired and new policies forced on you. Using SLF4J now, when you write the code, will take no more time than using Log4j directly. Replacing direct Log4j calls later will take a lot of time. SLF4J is a free investment/insurance for the future. Is that more important than Log4j 2 API features? Only you (or company policy) can decide that.
– Andreas
Jan 6 '17 at 3:08





Using SLF4J means that replacing the implementation is very easy if company policy changes, e.g. when your company is acquired and new policies forced on you. Using SLF4J now, when you write the code, will take no more time than using Log4j directly. Replacing direct Log4j calls later will take a lot of time. SLF4J is a free investment/insurance for the future. Is that more important than Log4j 2 API features? Only you (or company policy) can decide that.
– Andreas
Jan 6 '17 at 3:08













1 Answer
1






active

oldest

votes

















up vote
82
down vote



accepted










Go ahead: program to the log4j2 API instead of slf4j



It's safe: the Log4j2 API offers the exact same guarantees as slf4j - and more.



Now that Log4j2 itself is separated into an API and an implementation module, there is no longer any value in using SLF4J.



Yes, it is good engineering practice to keep your options open. You may want to change to another logging implementation later.



For the last 10 years or so, building such flexibility in your application meant using a wrapper API like SLF4J. This flexibility doesn't come for free though: the disadvantage of this approach is that your application cannot use the richer feature set of the underlying logging library.



Log4j2 offers a solution that doesn't require that your application is restricted to the lowest common denominator.



The escape valve: log4j-to-slf4j



Log4j2 includes a log4j-to-slf4j bridge module. Any application coded against the Log4j2 API can choose to switch the backing implementation to any slf4j-compliant implementation at any time.



log4j-to-slf4j



As mentioned in the question, using the Log4j2 API directly offers more functionality and has some non-functional advantages versus using a wrapper API like slf4j:



  • Message API

  • Lambdas for lazy logging

  • Log any Object instead of just Strings

  • Garbage-free: avoid creating varargs or creating Strings where possible

  • CloseableThreadContext automatically removes items from the MDC when you're finished with them

(See 10 Log4j2 API features not available in SLF4J for more details.)



Applications can safely use these rich features of the Log4j2 API without being locked in to the native Log4j2 core implementation.



SLF4J is still your safety valve, it just doesn't mean your application should code against the SLF4J API anymore.




Disclosure: I contribute to Log4j2.




Update: There seems to be some confusion that programming to the Log4j2 API somehow introduces a "facade for a facade". There is no difference in this respect between the Log4j2 API and SLF4J.



Both APIs require 2 dependencies when using a native implementation, and 4 dependencies for a non-native implementation. SLF4J and the Log4j2 API are identical in this respect. For example:



Required dependencies are similar for SLF4J and the Log4j 2 API






share|improve this answer


















  • 4




    I understand. Let me rephrase my question. Are there any independent implementations of log4j2 API other than log4j2?
    – Ceki
    Jan 6 '17 at 17:06






  • 4




    The Log4j2 API and impl are not "tightly coupled". All these SLF4J implementations are all available: An application coded against the Log4j2 API can select the log4j-to-slf4j dependency instead of log4j-core and choose any of these SLF4J implementations you mentioned. The number of native implementations of the Log4j2 API is irrelevant.
    – Remko Popma
    Jan 7 '17 at 0:39







  • 11




    Problem is that you often have dependencies on libraries which themself use slf4j, so it's easier to just stick with that.
    – Davio
    Jan 8 '17 at 18:22






  • 12




    so, I should use an interface for an interface for an implementation? Yea, no thanks... Slf4j beat log4j to the punch by providing a good interface to implementation for logging... log4j2 should just implement slf4j api - if there's a missing feature, contribute it back, if slf4j won't take the new feature, then MAYBE there's a case for log4j2 api interfaces....
    – RockMeetHardplace
    Jan 9 '17 at 2:36






  • 3




    @RemkoPopma - you're still advocating against using the log4j interface. Yes, I get it - I can chain log4j2's interface -> slf4j's interface -> whatever implementation, but I'd just rather not abstract the abstraction - thanks but no thanks.
    – RockMeetHardplace
    Jan 9 '17 at 13:50










Your Answer






StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













 

draft saved


draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f41498021%2fis-it-worth-to-use-slf4j-with-log4j2%23new-answer', 'question_page');

);

Post as a guest






























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
82
down vote



accepted










Go ahead: program to the log4j2 API instead of slf4j



It's safe: the Log4j2 API offers the exact same guarantees as slf4j - and more.



Now that Log4j2 itself is separated into an API and an implementation module, there is no longer any value in using SLF4J.



Yes, it is good engineering practice to keep your options open. You may want to change to another logging implementation later.



For the last 10 years or so, building such flexibility in your application meant using a wrapper API like SLF4J. This flexibility doesn't come for free though: the disadvantage of this approach is that your application cannot use the richer feature set of the underlying logging library.



Log4j2 offers a solution that doesn't require that your application is restricted to the lowest common denominator.



The escape valve: log4j-to-slf4j



Log4j2 includes a log4j-to-slf4j bridge module. Any application coded against the Log4j2 API can choose to switch the backing implementation to any slf4j-compliant implementation at any time.



log4j-to-slf4j



As mentioned in the question, using the Log4j2 API directly offers more functionality and has some non-functional advantages versus using a wrapper API like slf4j:



  • Message API

  • Lambdas for lazy logging

  • Log any Object instead of just Strings

  • Garbage-free: avoid creating varargs or creating Strings where possible

  • CloseableThreadContext automatically removes items from the MDC when you're finished with them

(See 10 Log4j2 API features not available in SLF4J for more details.)



Applications can safely use these rich features of the Log4j2 API without being locked in to the native Log4j2 core implementation.



SLF4J is still your safety valve, it just doesn't mean your application should code against the SLF4J API anymore.




Disclosure: I contribute to Log4j2.




Update: There seems to be some confusion that programming to the Log4j2 API somehow introduces a "facade for a facade". There is no difference in this respect between the Log4j2 API and SLF4J.



Both APIs require 2 dependencies when using a native implementation, and 4 dependencies for a non-native implementation. SLF4J and the Log4j2 API are identical in this respect. For example:



Required dependencies are similar for SLF4J and the Log4j 2 API






share|improve this answer


















  • 4




    I understand. Let me rephrase my question. Are there any independent implementations of log4j2 API other than log4j2?
    – Ceki
    Jan 6 '17 at 17:06






  • 4




    The Log4j2 API and impl are not "tightly coupled". All these SLF4J implementations are all available: An application coded against the Log4j2 API can select the log4j-to-slf4j dependency instead of log4j-core and choose any of these SLF4J implementations you mentioned. The number of native implementations of the Log4j2 API is irrelevant.
    – Remko Popma
    Jan 7 '17 at 0:39







  • 11




    Problem is that you often have dependencies on libraries which themself use slf4j, so it's easier to just stick with that.
    – Davio
    Jan 8 '17 at 18:22






  • 12




    so, I should use an interface for an interface for an implementation? Yea, no thanks... Slf4j beat log4j to the punch by providing a good interface to implementation for logging... log4j2 should just implement slf4j api - if there's a missing feature, contribute it back, if slf4j won't take the new feature, then MAYBE there's a case for log4j2 api interfaces....
    – RockMeetHardplace
    Jan 9 '17 at 2:36






  • 3




    @RemkoPopma - you're still advocating against using the log4j interface. Yes, I get it - I can chain log4j2's interface -> slf4j's interface -> whatever implementation, but I'd just rather not abstract the abstraction - thanks but no thanks.
    – RockMeetHardplace
    Jan 9 '17 at 13:50














up vote
82
down vote



accepted










Go ahead: program to the log4j2 API instead of slf4j



It's safe: the Log4j2 API offers the exact same guarantees as slf4j - and more.



Now that Log4j2 itself is separated into an API and an implementation module, there is no longer any value in using SLF4J.



Yes, it is good engineering practice to keep your options open. You may want to change to another logging implementation later.



For the last 10 years or so, building such flexibility in your application meant using a wrapper API like SLF4J. This flexibility doesn't come for free though: the disadvantage of this approach is that your application cannot use the richer feature set of the underlying logging library.



Log4j2 offers a solution that doesn't require that your application is restricted to the lowest common denominator.



The escape valve: log4j-to-slf4j



Log4j2 includes a log4j-to-slf4j bridge module. Any application coded against the Log4j2 API can choose to switch the backing implementation to any slf4j-compliant implementation at any time.



log4j-to-slf4j



As mentioned in the question, using the Log4j2 API directly offers more functionality and has some non-functional advantages versus using a wrapper API like slf4j:



  • Message API

  • Lambdas for lazy logging

  • Log any Object instead of just Strings

  • Garbage-free: avoid creating varargs or creating Strings where possible

  • CloseableThreadContext automatically removes items from the MDC when you're finished with them

(See 10 Log4j2 API features not available in SLF4J for more details.)



Applications can safely use these rich features of the Log4j2 API without being locked in to the native Log4j2 core implementation.



SLF4J is still your safety valve, it just doesn't mean your application should code against the SLF4J API anymore.




Disclosure: I contribute to Log4j2.




Update: There seems to be some confusion that programming to the Log4j2 API somehow introduces a "facade for a facade". There is no difference in this respect between the Log4j2 API and SLF4J.



Both APIs require 2 dependencies when using a native implementation, and 4 dependencies for a non-native implementation. SLF4J and the Log4j2 API are identical in this respect. For example:



Required dependencies are similar for SLF4J and the Log4j 2 API






share|improve this answer


















  • 4




    I understand. Let me rephrase my question. Are there any independent implementations of log4j2 API other than log4j2?
    – Ceki
    Jan 6 '17 at 17:06






  • 4




    The Log4j2 API and impl are not "tightly coupled". All these SLF4J implementations are all available: An application coded against the Log4j2 API can select the log4j-to-slf4j dependency instead of log4j-core and choose any of these SLF4J implementations you mentioned. The number of native implementations of the Log4j2 API is irrelevant.
    – Remko Popma
    Jan 7 '17 at 0:39







  • 11




    Problem is that you often have dependencies on libraries which themself use slf4j, so it's easier to just stick with that.
    – Davio
    Jan 8 '17 at 18:22






  • 12




    so, I should use an interface for an interface for an implementation? Yea, no thanks... Slf4j beat log4j to the punch by providing a good interface to implementation for logging... log4j2 should just implement slf4j api - if there's a missing feature, contribute it back, if slf4j won't take the new feature, then MAYBE there's a case for log4j2 api interfaces....
    – RockMeetHardplace
    Jan 9 '17 at 2:36






  • 3




    @RemkoPopma - you're still advocating against using the log4j interface. Yes, I get it - I can chain log4j2's interface -> slf4j's interface -> whatever implementation, but I'd just rather not abstract the abstraction - thanks but no thanks.
    – RockMeetHardplace
    Jan 9 '17 at 13:50












up vote
82
down vote



accepted







up vote
82
down vote



accepted






Go ahead: program to the log4j2 API instead of slf4j



It's safe: the Log4j2 API offers the exact same guarantees as slf4j - and more.



Now that Log4j2 itself is separated into an API and an implementation module, there is no longer any value in using SLF4J.



Yes, it is good engineering practice to keep your options open. You may want to change to another logging implementation later.



For the last 10 years or so, building such flexibility in your application meant using a wrapper API like SLF4J. This flexibility doesn't come for free though: the disadvantage of this approach is that your application cannot use the richer feature set of the underlying logging library.



Log4j2 offers a solution that doesn't require that your application is restricted to the lowest common denominator.



The escape valve: log4j-to-slf4j



Log4j2 includes a log4j-to-slf4j bridge module. Any application coded against the Log4j2 API can choose to switch the backing implementation to any slf4j-compliant implementation at any time.



log4j-to-slf4j



As mentioned in the question, using the Log4j2 API directly offers more functionality and has some non-functional advantages versus using a wrapper API like slf4j:



  • Message API

  • Lambdas for lazy logging

  • Log any Object instead of just Strings

  • Garbage-free: avoid creating varargs or creating Strings where possible

  • CloseableThreadContext automatically removes items from the MDC when you're finished with them

(See 10 Log4j2 API features not available in SLF4J for more details.)



Applications can safely use these rich features of the Log4j2 API without being locked in to the native Log4j2 core implementation.



SLF4J is still your safety valve, it just doesn't mean your application should code against the SLF4J API anymore.




Disclosure: I contribute to Log4j2.




Update: There seems to be some confusion that programming to the Log4j2 API somehow introduces a "facade for a facade". There is no difference in this respect between the Log4j2 API and SLF4J.



Both APIs require 2 dependencies when using a native implementation, and 4 dependencies for a non-native implementation. SLF4J and the Log4j2 API are identical in this respect. For example:



Required dependencies are similar for SLF4J and the Log4j 2 API






share|improve this answer














Go ahead: program to the log4j2 API instead of slf4j



It's safe: the Log4j2 API offers the exact same guarantees as slf4j - and more.



Now that Log4j2 itself is separated into an API and an implementation module, there is no longer any value in using SLF4J.



Yes, it is good engineering practice to keep your options open. You may want to change to another logging implementation later.



For the last 10 years or so, building such flexibility in your application meant using a wrapper API like SLF4J. This flexibility doesn't come for free though: the disadvantage of this approach is that your application cannot use the richer feature set of the underlying logging library.



Log4j2 offers a solution that doesn't require that your application is restricted to the lowest common denominator.



The escape valve: log4j-to-slf4j



Log4j2 includes a log4j-to-slf4j bridge module. Any application coded against the Log4j2 API can choose to switch the backing implementation to any slf4j-compliant implementation at any time.



log4j-to-slf4j



As mentioned in the question, using the Log4j2 API directly offers more functionality and has some non-functional advantages versus using a wrapper API like slf4j:



  • Message API

  • Lambdas for lazy logging

  • Log any Object instead of just Strings

  • Garbage-free: avoid creating varargs or creating Strings where possible

  • CloseableThreadContext automatically removes items from the MDC when you're finished with them

(See 10 Log4j2 API features not available in SLF4J for more details.)



Applications can safely use these rich features of the Log4j2 API without being locked in to the native Log4j2 core implementation.



SLF4J is still your safety valve, it just doesn't mean your application should code against the SLF4J API anymore.




Disclosure: I contribute to Log4j2.




Update: There seems to be some confusion that programming to the Log4j2 API somehow introduces a "facade for a facade". There is no difference in this respect between the Log4j2 API and SLF4J.



Both APIs require 2 dependencies when using a native implementation, and 4 dependencies for a non-native implementation. SLF4J and the Log4j2 API are identical in this respect. For example:



Required dependencies are similar for SLF4J and the Log4j 2 API







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 10 at 11:16









Community

11




11










answered Jan 6 '17 at 6:42









Remko Popma

19.4k64971




19.4k64971







  • 4




    I understand. Let me rephrase my question. Are there any independent implementations of log4j2 API other than log4j2?
    – Ceki
    Jan 6 '17 at 17:06






  • 4




    The Log4j2 API and impl are not "tightly coupled". All these SLF4J implementations are all available: An application coded against the Log4j2 API can select the log4j-to-slf4j dependency instead of log4j-core and choose any of these SLF4J implementations you mentioned. The number of native implementations of the Log4j2 API is irrelevant.
    – Remko Popma
    Jan 7 '17 at 0:39







  • 11




    Problem is that you often have dependencies on libraries which themself use slf4j, so it's easier to just stick with that.
    – Davio
    Jan 8 '17 at 18:22






  • 12




    so, I should use an interface for an interface for an implementation? Yea, no thanks... Slf4j beat log4j to the punch by providing a good interface to implementation for logging... log4j2 should just implement slf4j api - if there's a missing feature, contribute it back, if slf4j won't take the new feature, then MAYBE there's a case for log4j2 api interfaces....
    – RockMeetHardplace
    Jan 9 '17 at 2:36






  • 3




    @RemkoPopma - you're still advocating against using the log4j interface. Yes, I get it - I can chain log4j2's interface -> slf4j's interface -> whatever implementation, but I'd just rather not abstract the abstraction - thanks but no thanks.
    – RockMeetHardplace
    Jan 9 '17 at 13:50












  • 4




    I understand. Let me rephrase my question. Are there any independent implementations of log4j2 API other than log4j2?
    – Ceki
    Jan 6 '17 at 17:06






  • 4




    The Log4j2 API and impl are not "tightly coupled". All these SLF4J implementations are all available: An application coded against the Log4j2 API can select the log4j-to-slf4j dependency instead of log4j-core and choose any of these SLF4J implementations you mentioned. The number of native implementations of the Log4j2 API is irrelevant.
    – Remko Popma
    Jan 7 '17 at 0:39







  • 11




    Problem is that you often have dependencies on libraries which themself use slf4j, so it's easier to just stick with that.
    – Davio
    Jan 8 '17 at 18:22






  • 12




    so, I should use an interface for an interface for an implementation? Yea, no thanks... Slf4j beat log4j to the punch by providing a good interface to implementation for logging... log4j2 should just implement slf4j api - if there's a missing feature, contribute it back, if slf4j won't take the new feature, then MAYBE there's a case for log4j2 api interfaces....
    – RockMeetHardplace
    Jan 9 '17 at 2:36






  • 3




    @RemkoPopma - you're still advocating against using the log4j interface. Yes, I get it - I can chain log4j2's interface -> slf4j's interface -> whatever implementation, but I'd just rather not abstract the abstraction - thanks but no thanks.
    – RockMeetHardplace
    Jan 9 '17 at 13:50







4




4




I understand. Let me rephrase my question. Are there any independent implementations of log4j2 API other than log4j2?
– Ceki
Jan 6 '17 at 17:06




I understand. Let me rephrase my question. Are there any independent implementations of log4j2 API other than log4j2?
– Ceki
Jan 6 '17 at 17:06




4




4




The Log4j2 API and impl are not "tightly coupled". All these SLF4J implementations are all available: An application coded against the Log4j2 API can select the log4j-to-slf4j dependency instead of log4j-core and choose any of these SLF4J implementations you mentioned. The number of native implementations of the Log4j2 API is irrelevant.
– Remko Popma
Jan 7 '17 at 0:39





The Log4j2 API and impl are not "tightly coupled". All these SLF4J implementations are all available: An application coded against the Log4j2 API can select the log4j-to-slf4j dependency instead of log4j-core and choose any of these SLF4J implementations you mentioned. The number of native implementations of the Log4j2 API is irrelevant.
– Remko Popma
Jan 7 '17 at 0:39





11




11




Problem is that you often have dependencies on libraries which themself use slf4j, so it's easier to just stick with that.
– Davio
Jan 8 '17 at 18:22




Problem is that you often have dependencies on libraries which themself use slf4j, so it's easier to just stick with that.
– Davio
Jan 8 '17 at 18:22




12




12




so, I should use an interface for an interface for an implementation? Yea, no thanks... Slf4j beat log4j to the punch by providing a good interface to implementation for logging... log4j2 should just implement slf4j api - if there's a missing feature, contribute it back, if slf4j won't take the new feature, then MAYBE there's a case for log4j2 api interfaces....
– RockMeetHardplace
Jan 9 '17 at 2:36




so, I should use an interface for an interface for an implementation? Yea, no thanks... Slf4j beat log4j to the punch by providing a good interface to implementation for logging... log4j2 should just implement slf4j api - if there's a missing feature, contribute it back, if slf4j won't take the new feature, then MAYBE there's a case for log4j2 api interfaces....
– RockMeetHardplace
Jan 9 '17 at 2:36




3




3




@RemkoPopma - you're still advocating against using the log4j interface. Yes, I get it - I can chain log4j2's interface -> slf4j's interface -> whatever implementation, but I'd just rather not abstract the abstraction - thanks but no thanks.
– RockMeetHardplace
Jan 9 '17 at 13:50




@RemkoPopma - you're still advocating against using the log4j interface. Yes, I get it - I can chain log4j2's interface -> slf4j's interface -> whatever implementation, but I'd just rather not abstract the abstraction - thanks but no thanks.
– RockMeetHardplace
Jan 9 '17 at 13:50

















 

draft saved


draft discarded















































 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f41498021%2fis-it-worth-to-use-slf4j-with-log4j2%23new-answer', 'question_page');

);

Post as a guest














































































這個網誌中的熱門文章

How to read a connectionString WITH PROVIDER in .NET Core?

In R, how to develop a multiplot heatmap.2 figure showing key labels successfully

Museum of Modern and Contemporary Art of Trento and Rovereto