I have used SLF4J for some time now in a number of projects and did
not have any (serious) problem yet.
The biggest problem was that some classes where not serializable. So
when used in web apps that store objects with loggers in session or
client this was an issue of course. But this was fixed in the latest
stable release.
What I like about SLF4J is the clear separation of the API for
compiletime/runtime and the log implementation specific stub libraries
for runtime only. When using with Maven you can have clean
dependencies:
1. define a *compile* dep to slf4j-api for all your modules
2. define a *test* dep to slf4j-log4j12 to log unit testing output with Log4J
3. define a *runtime* dep to slf4j-log4j12 for the webapp module to
log with Log4J
4. define a *runtime* dep to jcl-over-slf4j to reroute third-party
lib's JCL logging over SLF4J
So, if (for some reason) you want to switch over from Log4J to
JDK-Logging all you need to do is replace the runtime dep to
slf4j-log4j12 (number 3) by a dependency to slf4j-jdk14.
Another nice feature of SLF4J is the chance to get rid of those ugly
"if(logger.isDebugEnabled()) {" lines by using parameterized messages
(see http://www.slf4j.org/faq.html#logging_performance)
--Manfred
On 7/14/08, Werner Punz <[EMAIL PROTECTED]> wrote:
> Ok I just saw that the slf4j people provide a thin api layer
> which replaces the commons logging if needed.
>
> Then probably replacing commons logging is a non issue.
> I just was raising this issue again, due to the problems i read
> about log4j especially in combination with was and other big irons
> which drop their own classloaders, and due to the fact that I feel
> it is generally a bad idea for a low level library to have too many
> dependencies into other libs.
>
> Werner
>
>
>
> [EMAIL PROTECTED] schrieb:
>> Werner Punz schrieb:
>>> Hello everyone, we have been using commons-logging the past years.
>>> I am not sure if it is a good idea,
>>> first of all java has a decent logging api, which would allow us to
>>> eliminate the logging dependency.
>> Using a logging API built into the JDK does feel tempting.
>>
>> However before doing this, have a look at the number of alternative
>> implementations of the API.
>> * The one built into the JDK sucks. badly.
>> * There is one that is built into Tomcat (JULI) but that is not
>> available as a standalone lib.
>> * The SLF4J project provides "jcl-over-slf4j". I haven't used this
>> myself, but presume that it needs to be in the system classpath to work
>> (one of the major issues with the java.util.logging design). So I'm not
>> sure how that would interact with Tomcat's JULI logging. See:
>> http://slf4j.org/api/org/slf4j/bridge/SLF4JBridgeHandler.html
>>
>> I'm not aware of any other implementations.
>>
>> And I'm not at all sure whether it is possible for different webapps
>> running in the same container to have different logging configuration.
>> It would be ugly to force a solution on users where all logging from all
>> their webapps ends up mixed together in the same output file. So I would
>> suggest analysing things carefully before moving to java.util.logging.
>>
>> I have the feeling that java.util.logging was designed by Sun JDK
>> implementers to help debugging JDK (java.*) code. For that purpose it
>> works fine. Using it from application code seems far less useful..
>>
>>> Secondly,I have not looked into the code yet, but there are a load
>>> of references that commons logging has problems due to messing around
>>> with the classloader.
>> That's an ancient issue. There have been zero issues related to this
>> reported since the 1.1 commons release.
>>
>>> Projects like Tapestry already have moved away towards SLF4J which
>>> apparently is better.
>> "apparently" doesn't sound like a terribly convincing reason to me to
>> move from one log wrapper to another.
>>>
>>> Whats your opinion should we keep the commons logging
>>> references?
>> Despite being a commons-logging developer, I don't care what
>> implementation is used. But AFAIK we do have a working solution now; I'd
>> like to be sure that whatever we move towards
>> (a) actually does work (java.util.logging), and
>> (b) brings benefits that are worth the effort of converting over (slf4j)
>>
>>
>> Regards,
>> Simon
>>
>>
>
>
--
http://www.irian.at
Your JSF powerhouse - JSF Consulting,
Development and Courses in English and
German
Professional Support for Apache MyFaces
