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
