Is it worth to use slf4j with log4j2
up vote
60
down vote
favorite
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
edited Nov 7 '17 at 9:28
Remko Popma
19.4k64971
asked Jan 6 '17 at 2:31
Andy897
2,50332864
add a comment |
up vote
60
down vote
favorite
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
edited Nov 7 '17 at 9:28
Remko Popma
19.4k64971
asked Jan 6 '17 at 2:31
Andy897
2,50332864
1
Maybe. What if my application server includesslf4jand 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 usejava.util.loggingin 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
add a comment |
up vote
60
down vote
favorite
up vote
60
down vote
favorite
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
edited Nov 7 '17 at 9:28
Remko Popma
19.4k64971
asked Jan 6 '17 at 2:31
Andy897
2,50332864
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
java logging log4j slf4j log4j2
edited Nov 7 '17 at 9:28
Remko Popma
19.4k64971
asked Jan 6 '17 at 2:31
Andy897
2,50332864
edited Nov 7 '17 at 9:28
Remko Popma
19.4k64971
asked Jan 6 '17 at 2:31
Andy897
2,50332864
edited Nov 7 '17 at 9:28
Remko Popma
19.4k64971
edited Nov 7 '17 at 9:28
Remko Popma
19.4k64971
edited Nov 7 '17 at 9:28
Remko Popma
19.4k64971
19.4k64971
asked Jan 6 '17 at 2:31
Andy897
2,50332864
asked Jan 6 '17 at 2:31
Andy897
2,50332864
asked Jan 6 '17 at 2:31
Andy897
2,50332864
2,50332864
1
Maybe. What if my application server includesslf4jand 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 usejava.util.loggingin 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
add a comment |
1
Maybe. What if my application server includesslf4jand 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 usejava.util.loggingin 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
add a comment |
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.
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:
edited Nov 10 at 11:16
Community♦
11
answered Jan 6 '17 at 6:42
Remko Popma
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 thelog4j-to-slf4jdependency instead oflog4j-coreand 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
|
show 17 more comments
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.
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:
edited Nov 10 at 11:16
Community♦
11
answered Jan 6 '17 at 6:42
Remko Popma
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 thelog4j-to-slf4jdependency instead oflog4j-coreand 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
|
show 17 more comments
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.
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:
edited Nov 10 at 11:16
Community♦
11
answered Jan 6 '17 at 6:42
Remko Popma
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 thelog4j-to-slf4jdependency instead oflog4j-coreand 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
|
show 17 more comments
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.
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:
edited Nov 10 at 11:16
Community♦
11
answered Jan 6 '17 at 6:42
Remko Popma
19.4k64971
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.
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:
edited Nov 10 at 11:16
Community♦
11
answered Jan 6 '17 at 6:42
Remko Popma
19.4k64971
edited Nov 10 at 11:16
Community♦
11
edited Nov 10 at 11:16
Community♦
11
edited Nov 10 at 11:16
Community♦
11
11
answered Jan 6 '17 at 6:42
Remko Popma
19.4k64971
answered Jan 6 '17 at 6:42
Remko Popma
19.4k64971
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 thelog4j-to-slf4jdependency instead oflog4j-coreand 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
|
show 17 more comments
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 thelog4j-to-slf4jdependency instead oflog4j-coreand 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
|
show 17 more comments
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
1
Maybe. What if my application server includes
slf4jand 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 usejava.util.loggingin 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