After 11 months of gestation, SLF4J version 1.0 (final) is finally out the door. For those who have not heard of it, SLF4J (Simple Logging Facade for Java) acts as a facade for various logging APIs allowing to the end-user to plug in the desired implementation at deployment time. A gradual migration path away from Jakarta Commons Logging (JCL) is also supported.
SLF4J does not rely on any special class loader machinery. In fact, the binding between SLF4J and a given logging API implementation is performed statically at compile time. Each binding is hardwired to use one and only specific logging API implementation. Thus, SLF4J suffers from none of the class loader problems or memory leaks observed with other approaches.
SLF4J also includes support for Marker objects, a feature which hopefully will be widely used as newer logging systems become available.
-
SLF4J 1.0 (final) has been released (54 messages)
- Posted by: ceki Gulcu
- Posted on: March 09 2006 14:00 EST
Threaded Messages (54)
- SLF4J 1.0 (final) has been released by D S on March 10 2006 04:09 EST
- slow news week by Michael Neale on March 10 2006 04:23 EST
- SLF4J 1.0 (final) has been released by Lars Stitz on March 10 2006 04:23 EST
- SLF4J 1.0 (final) has been released by Werner Punz on March 10 2006 05:30 EST
- SLF4J 1.0 (final) has been released by Tamas Cserveny on March 10 2006 05:50 EST
- libraries and applications by jilles van gurp on March 11 2006 04:05 EST
- deploy time or compile time by Hack Kampbj??rn on March 10 2006 08:38 EST
- SLF4J 1.0 (final) has been released by ceki Gulcu on March 13 2006 10:15 EST
- Re: please explain by Sean Reith on March 15 2006 02:51 EST
- SLF4J 1.0 (final) has been released by Hani Suleiman on March 10 2006 06:06 EST
- SLF4J 1.0 (final) has been released by Freddy Daoud on March 10 2006 07:48 EST
- SLF4J 1.0 (final) has been released by Alexandre Poitras on March 10 2006 08:16 EST
- SLF4J 1.0 (final) has been released by Tim Fennell on March 10 2006 08:16 EST
-
Think again before adopting the commons-logging API by javier castanon on March 10 2006 11:22 EST
- Problem, problems... by Alastair Rodgers on March 10 2006 11:40 EST
-
It can work WITH the Commons Logging API by Matt Jensen on March 10 2006 11:48 EST
- Commons-logging Hot Deploy - JBoss vs. Tomcat by Elmira Fudd on March 10 2006 12:04 EST
- RE: It can work WITH the Commons Logging API by Elmira Fudd on March 10 2006 01:09 EST
-
It can work WITH the Commons Logging API by Marc Stock on March 10 2006 04:12 EST
-
It can work WITH the Commons Logging API by Konstantin Ignatyev on March 10 2006 05:52 EST
- Your survey is excellent and rational by Elmira Fudd on March 10 2006 07:39 EST
-
It can work WITH the Commons Logging API by Konstantin Ignatyev on March 10 2006 05:52 EST
-
Looks like a logger implementation issue to me by Elmira Fudd on March 10 2006 11:50 EST
-
Looks like a logger implementation issue to me by Guido Anzuoni on March 10 2006 12:14 EST
- Commons Logging lifecycle method by Elmira Fudd on March 10 2006 01:45 EST
- Looks like a logger implementation issue to me by Matt Jensen on March 10 2006 03:33 EST
-
Looks like a logger implementation issue to me by Guido Anzuoni on March 10 2006 12:14 EST
- Think again before adopting the commons-logging API by Larry Singer on March 13 2006 02:52 EST
- Comparison of slf4j implementations - x4juli by Boris Unckel on March 10 2006 15:45 EST
- SLF4J 1.0 (final) has been released by Wille Faler on March 11 2006 12:19 EST
-
SLF4J 1.0 (final) has been released by Eugene Lucash on March 11 2006 05:25 EST
- SLF4J 1.0 (final) has been released by Wille Faler on March 12 2006 11:22 EST
-
SLF4J 1.0 (final) has been released by Eugene Lucash on March 11 2006 05:25 EST
- SLF4J 1.0 (final) has been released by Freddy Daoud on March 10 2006 07:48 EST
- Why all the SLF4J bashing? by Elmira Fudd on March 10 2006 08:47 EST
- Why all the SLF4J bashing? by Freddy Daoud on March 10 2006 09:41 EST
- please explain by Adam Spencer on March 10 2006 09:17 EST
- please explain by Freddy Daoud on March 10 2006 09:35 EST
-
please explain by Adam Spencer on March 10 2006 09:45 EST
-
Why an interface, really? by Elmira Fudd on March 10 2006 09:53 EST
-
Why an interface, really? by ticklish turtletoe on March 10 2006 10:26 EST
-
Too much time on his hands by Elmira Fudd on March 10 2006 10:28 EST
- Too mean by Elmira Fudd on March 10 2006 10:31 EST
-
Too much time on his hands by Elmira Fudd on March 10 2006 10:28 EST
- java.util.logging capabilities clarification by Joseph Ottinger on March 11 2006 05:17 EST
-
Why an interface, really? by ticklish turtletoe on March 10 2006 10:26 EST
- please explain by Alexandre Poitras on March 10 2006 09:57 EST
-
please explain by Freddy Daoud on March 10 2006 10:01 EST
-
please explain by Ric Wang on March 10 2006 10:33 EST
-
Hard wire by Elmira Fudd on March 10 2006 10:47 EST
- Never mind by Elmira Fudd on March 10 2006 10:57 EST
-
Hard wire by Ric Wang on March 10 2006 10:57 EST
-
Logging is logging by Elmira Fudd on March 10 2006 11:17 EST
- Logging is logging by Ric Wang on March 10 2006 11:51 EST
-
Logging is logging by Elmira Fudd on March 10 2006 11:17 EST
-
Hard wire by Elmira Fudd on March 10 2006 10:47 EST
-
please explain by Ric Wang on March 10 2006 10:33 EST
-
Why an interface, really? by Elmira Fudd on March 10 2006 09:53 EST
-
please explain by Adam Spencer on March 10 2006 09:45 EST
- Because java.util.logging sucks big time! by Daniel Serodio on March 15 2006 17:37 EST
- please explain by Freddy Daoud on March 10 2006 09:35 EST
- MessageFormat by Mark Andersen on March 10 2006 10:51 EST
- MessageFormat by Tim Fennell on March 10 2006 13:25 EST
- MessageFormat by Mark Andersen on March 10 2006 02:14 EST
- MessageFormat by Tim Fennell on March 10 2006 13:25 EST
- Who would avoid using a library because of java.util.logging? by Brian Smith on March 10 2006 17:11 EST
- A Solution for the Confusion by Elmira Fudd on March 14 2006 15:53 EST
-
SLF4J 1.0 (final) has been released[ Go to top ]
- Posted by: D S
- Posted on: March 10 2006 04:09 EST
- in response to ceki Gulcu
Maybe I'm misunderstanding something here but I can't reconcile these two statements in the paragraph above:SLF4J acts as a facade for various logging APIs allowing to the end-user to plug in the desired implementation at deployment time.
In fact, the binding between SLF4J and a given logging API implementation is performed statically at compile time.
If it's hard-wired at compile time, how can I plug something in at deployment time?
And do we really need another logging facade? How often do people really switch logging implementations anyway in the real world? I've been writing Java applications for 8 years and I've never come across anyone who's decided to switch from one logging framework to another in a live app after it's gone into production. -
slow news week[ Go to top ]
- Posted by: Michael Neale
- Posted on: March 10 2006 04:23 EST
- in response to D S
very slow... -
SLF4J 1.0 (final) has been released[ Go to top ]
- Posted by: Lars Stitz
- Posted on: March 10 2006 04:23 EST
- in response to D S
And do we really need another logging facade?
Yeah, right! What we really need now is some interface to hide the different logging facade implementations behind. I think Ceki Gülcü has his further work cut out for him...
SCNR, Lars ;-) -
SLF4J 1.0 (final) has been released[ Go to top ]
- Posted by: Werner Punz
- Posted on: March 10 2006 05:30 EST
- in response to Lars Stitz
And do we really need another logging facade?
Yeah, right! What we really need now is some interface to hide the different logging facade implementations behind. I think Ceki Gülcü has his further work cut out for him...SCNR, Lars ;-)
And after that we need a simple LoggingFacadeFacade to hide all the differences of the Logging Facades...
No seriously the whole logging issue is a mess... -
SLF4J 1.0 (final) has been released[ Go to top ]
- Posted by: Tamas Cserveny
- Posted on: March 10 2006 05:50 EST
- in response to D S
How often do people really switch logging implementations anyway in the real world? I've been writing Java applications for 8 years and I've never come across anyone who's decided to switch from one logging framework to another in a live app after it's gone into production.
It is useful for libraries, so they don't have to push their logging-framework choice on you, not mentioning having two 3rd-party lib with seperate log framework.
As for applications, you're right. Stick with one, and you can use all your framework specific goodies.
JCL has really nasty side-effects in a container though... -
libraries and applications[ Go to top ]
- Posted by: jilles van gurp
- Posted on: March 11 2006 04:05 EST
- in response to Tamas Cserveny
It is useful for libraries, so they don't have to push their logging-framework choice on you, not mentioning having two 3rd-party lib with seperate log framework. As for applications, you're right. Stick with one, and you can use all your framework specific goodies.JCL has really nasty side-effects in a container though...
Actually, web applications have to share the console with the output from the application server, other webapplications and libraries. Probably the application server provides some configuration for logging as well. The best thing to do is to leave it to the server. People do switch application servers.
Probably a good rule of thumb is that only if your software contains the main method are you in control of logging. Even then it may be good practice to use a facade rather than something specific.
Commons.logging suits me fine BTW. Realistically, the only stuff you facade for is log4j and the java standard logging api. The point of all the other alternatives is lost on me, I've never seen them used in practice. They all seem to do pretty much the same anyway. -
deploy time or compile time[ Go to top ]
- Posted by: Hack Kampbj??rn
- Posted on: March 10 2006 08:38 EST
- in response to D S
Maybe I'm misunderstanding something here but I can't reconcile these two statements in the paragraph above:
SLF4J acts as a facade for various logging APIs allowing to the end-user to plug in the desired implementation at deployment time.
In fact, the binding between SLF4J and a given logging API implementation is performed statically at compile time.
If it's hard-wired at compile time, how can I plug something in at deployment time?And do we really need another logging facade? How often do people really switch logging implementations anyway in the real world? I've been writing Java applications for 8 years and I've never come across anyone who's decided to switch from one logging framework to another in a live app after it's gone into production.
Yes, that part is poorly written. What they mean is that the components writer only need to write to the SLF4J API and you can choose which logging framework to use at deploy by deploying the component with the appropiate jar file. -
SLF4J 1.0 (final) has been released[ Go to top ]
- Posted by: ceki Gulcu
- Posted on: March 13 2006 10:15 EST
- in response to D S
The initial wording of my post may have been unclear. While the binding to a given logging system is done at compile time, there is one binding for each logging system. Each binding is delivered in a separate jar file (one jar file per binding). You can switch to a different binding at deployment time simply by replacing one jar file with another.
Many participants in this forum question the necessity of a logging façade. A logging façade, e.g. SLF4J, meets the needs of libraries and other embedded components because libraries cannot afford to impose their choice of logging system on the end-user. On the other hand, SLF4J does not necessarily make sense in the context of stand-alone applications. Stand-alone applications should consider invoking the logging system of their choice directly.
Other participants have expressed concerns about having to deal with yet another logging façade in addition to Jakarta commons-logging (JCL). SLF4J's abstraction is very similar to that of JCL. Compared, to JCL, SLF4J offers small API improvements such as "message formatters" and marker objects. But most importantly, SLF4J is simple and robust. It is designed to cause less trouble than JCL.
For a quick summary of the advantages involved in using SLF4J, please read http://www.slf4j.org/manual.html#summary
In case of problems you can always ask for help on the SLF4J mailing lists. Your constructive criticism is also most welcome. -
Re: please explain[ Go to top ]
- Posted by: Sean Reith
- Posted on: March 15 2006 02:51 EST
- in response to ceki Gulcu
Thank you for continuing your useful contributions to logging in the Java community Ceki, they are much appreciated by at least some of the community!
In addition to relief from the ClassLoader issues, the MessageFormat approach is great mechanism if nothing else to avoid most of the isDebugEnabled() proliferation.
It is a shame most of the detractors haven't bothered to at least briefly read the references (particularly http://www.qos.ch/logging/thinkAgain.jsp as Javier referenced, as well as http://www.slf4j.org/manual.html#summary). These couldn't be much clearer, no helping some people :)
Did you consider using NDC as a vehicle for exposing Markers under the Log4J implementation/adapter? I imagine they will struggle to gain much traction until they are realised in at least one of the 'major' logging implementations.
On the downside, I would have preferred that you didn't dispense with the "fatal" error level (personally I also favour a "trace" level below "debug"), and it would have been nice to see support for custom levels (though granted this would prove ugly when mapping to implementations without such capability).
The facility to drop in the jcl104-over-slf4j.jar as a drop in replacement for JCL is excellent, and probably the one I will get most benefit from in the short term.
Library developers _please_ don't drop support for pre-JDK 1.4 environments simply to leverage JUL (a very poor reason to break further backward compatibility). Needless to say, providing access to logging information _is_ very helpful to me as a consumer of your libraries, and many clients simply do not yet have a JDK 1.4 environment.While the binding to a given logging system is done at compile time, there is one binding for each logging system. Each binding is delivered in a separate jar file (one jar file per binding). You can switch to a different binding at deployment time simply by replacing one jar file with another.
I suspect this is still not entirely clear. Perhaps:
"As a user* of SLF4J, you would typically** code against the SLF4J API. SLF4J provides several implementations of this API (each which is independently compiled and delivered as a separate jar), which provide bindings to specific logging systems (eg: Log4J, java.util.logging, etc). At deployment time the deployer needs to select one such SLF4J jar, which will determine the logging system which will be used at runtime.
* - Logging facades are primarily valuable for developing against by library developers (to allow users of their libraries to bind to their preferred logging mechanism, reducing dependancies and improving integration); though there is no reason that applications could not also leverage SLF4J if they are willing to forego the greater expressiveness of coding to a specific logging system, eg: Log4J.
** - The jcl104-over-slf4j allows you to code against JCL, but use the SLF4J binding mechanism to avoid the classloading vulnerability inherently present in the JCL late binding mechanism (see http://www.qos.ch/logging/thinkAgain.jsp); however this is primarily intended as a migration aid."
Fare thee well,
Sean. -
SLF4J 1.0 (final) has been released[ Go to top ]
- Posted by: Hani Suleiman
- Posted on: March 10 2006 06:06 EST
- in response to ceki Gulcu
I actually (foolishly) tried out slf4j. Here are some fun facts:
Most implementations are forks of log4j and are written by Ceki, none of which are usable.
nlog4j is the one with most features, that I can see. It is, of course, a fork of log4j. Except that many apps that depend on log4j blow up with nlog4j, due to slightly different method signatures than what they expect. So you can't use nlog4j if you use any of the apps that use log4j.
jdk14: Why bother with a wrapper instead of using this directly, or if you really miss things like log.debug(), just write a trivial one class wrapper to do that, along with a formatter that gives you log4j style one-liner output?
NOPLogger: Ummm, yeah, right. Does what it says on the tin. Highly useful.
Simple: Just spits out a hardcoded format to System.err. Not sure how this beats System.err.println().
SimpleLog: The only implementation not produced by Ceki, which actually looks sane.
LogBack: Seems to promise much, complex and big, but development seems to have stalled. Written by....yep, you guessed it.
x4juli: A port of log4j to jdk14 API. Why anyone would use slf4j api backed by x4juli which is backed by jdk14 logging instead of jdk14 logging is a mystery that I suspect no one will ever solve.
It's also often unclear with what needs to be deployed. In some cases you need two jars (the slf4j api and the impl), in some cases the impl contains the api.
In short, do yourself a favour and avoid this stuff. Stick to log4j and you will avert much sadness. -
SLF4J 1.0 (final) has been released[ Go to top ]
- Posted by: Freddy Daoud
- Posted on: March 10 2006 07:48 EST
- in response to Hani Suleiman
Thanks Hani for taking the time to try it out and to let us know what you experienced.
If I understand correctly, this is a logging facade, not a(nother) logging facility. Now I have to ask, and I really want to make it clear that this is not a criticism, it's just a simple question: what's wrong with commons-logging? In other words, Ceki, are there issues you are trying to address that commons-logging does not?
Again, just asking. I mean, it's like if I went out and tried to write another Ant. I'd have to have some serious issues that were not addressed despite first asking the project developers for these 'missing features' for me to undertake such a project.
Just curious..
Frederic -
SLF4J 1.0 (final) has been released[ Go to top ]
- Posted by: Alexandre Poitras
- Posted on: March 10 2006 08:16 EST
- in response to Freddy Daoud
I find it a little bit crazy to abstract a lot of libraries, you are still dependent upon its abstractions.
So let's add another wrapper over the wrapper?
If you need to use a library everywhere but you don't want to be totally dependant on it, you should rather use AOP in my opinion. -
SLF4J 1.0 (final) has been released[ Go to top ]
- Posted by: Tim Fennell
- Posted on: March 10 2006 08:16 EST
- in response to Freddy Daoud
what's wrong with commons-logging? In other words, Ceki, are there issues you are trying to address that commons-logging does not?Again, just asking.
I tend to agree with this sentiment. Commons logging may not be the best logging wrapper ever, but it is the defacto choice for library and framework developers because you want to use _something_ that lets the consumer of the library plug your logging output into their logging framework of choice.
So it seems to me that with the goal of a logging wrapper being to reduce the number of logging frameworks to configure (and also reduce the number of log files stuff gets logged to), and the fact that commons-logging is pretty pervasive in the library/framework community that a second logging wrapper kind of defeats the purpose. Do we really want end users having to configure commons-logging and SLF4J? I don't think so.
Whatever the problems with commons-logging I'd have to say that they best approach at this point has to be fixing them in place, not creating a new project.
-Tim Fennell
Stripes: Because web development should just be easier -
Think again before adopting the commons-logging API[ Go to top ]
- Posted by: javier castanon
- Posted on: March 10 2006 11:22 EST
- in response to Freddy Daoud
This is Ceki's view on the matter:Commons-logging promises to bridge to different logging APIs such as log4j, Avalon logkit and java.util.logging API. However, it's dynamic discovery mechanism is the source of painful bugs. In practice, JCL can only safely bridge the java.util.logging API.
Think again before adopting the commons-logging API
http://www.qos.ch/logging/thinkAgain.jsp -
Problem, problems...[ Go to top ]
- Posted by: Alastair Rodgers
- Posted on: March 10 2006 11:40 EST
- in response to javier castanon
Ceki provided a good breakdown of the problems here.
<br />
SLF4J also includes a JAR which implements the commons-logging interface but delegates through to slf4j, so you should be able to replace the commons-logging.jar with this one and automagically fix all the problems Ceki mentions, even for 3rd party libraries that depend on JCL. We're just in the process of trying this out.
Al. -
It can work WITH the Commons Logging API[ Go to top ]
- Posted by: Matt Jensen
- Posted on: March 10 2006 11:48 EST
- in response to javier castanon
Boy, the "do we really need another ____?" barrage has really become predictable on this site. Maybe TSS should adopt it as a slogan.
Venting and bickering aside, I had to throw in my two cents in support of SLF4J. I expect that most of the "detractors" here do not understand what it does and/or why Commons Logging should be avoided. In a nutshell, if you don't want your web applications to wedge into your servlet container and refuse to hot-unload, you shouldn't be using Commons Logging. The problems have been described many times, by many people who are much smarter than me. If you're curious, Google will supply all the information you need.
One of the benefits that SLF4J offers is a reimplementation of the various Commons Logging APIs which will not leak memory. You can continue to program to those APIs. Just deploy your application with jcl-over-slf4j.jar and you'll have the best of both worlds: the ubiquitous JCL API and a non-leaking implementation thereof. This is not a BAD thing.
This is only one use of SLF4J, but it is an important one. I was able to fix an un-unloadable application by replacing ("augmenting") Tomcat's JCL usage with SLF4J.
I am in no way affiliated with the SLF4J project. Ceki is trying to address a very common problem. He should get some encouragement for that. -
Commons-logging Hot Deploy - JBoss vs. Tomcat[ Go to top ]
- Posted by: Elmira Fudd
- Posted on: March 10 2006 12:04 EST
- in response to Matt Jensen
Anyone using commons-logging ever notice how you can't cleanly hot deploy in Tomcat but you can in JBoss?
Yahoo! -
RE: It can work WITH the Commons Logging API[ Go to top ]
- Posted by: Elmira Fudd
- Posted on: March 10 2006 13:09 EST
- in response to Matt Jensen
"Boy, the 'do we really need another ____?' barrage has really become predictable on this site. Maybe TSS should adopt it as a slogan."
The real question is "Do we we really need to complain about someone else's complaint about 'do we really need another____?' on this site?" Maybe that should be part of the slogan too?
You wascal you! -
It can work WITH the Commons Logging API[ Go to top ]
- Posted by: Marc Stock
- Posted on: March 10 2006 16:12 EST
- in response to Matt Jensen
"do we really need another ____?"
It's a fair question and should be considered everytime a new libary comes out. Some people just suffer from NIH syndrome and have to make their own version of something when it doesn't offer any real improvement over existing libaries. I'm sure not gonna just assume "people who are much smarter than me" are always right because they aren't.
As for using SLF4J to get around a Commons Logging memory leak...I'm not familiar with the leak you mentioned but wouldn't it be better to simply fix the leak? -
It can work WITH the Commons Logging API[ Go to top ]
- Posted by: Konstantin Ignatyev
- Posted on: March 10 2006 17:52 EST
- in response to Marc Stock
"do we really need another ____?" It's a fair question and should be considered everytime a new libary comes out. Some people just suffer from NIH syndrome and have to make their own version of something when it doesn't offer any real improvement over existing libaries.
Yes, therefore I long advocate that every project on the very first page has introduction that follows the template:
1. I(we) had a need to do: <Two phrases to describe>
2. I(we) have tried the following frameworks: <insert names> before starting to develop my own
3. They are supposed to address my needs but I was not happy with them because: <reasons why those frameworks are not satisfactory>
4. I(we) decided not to contribute to any of the existing open source frameworks because: <describe why>
http://kgionline.com/annoying/openSrc.jsp -
Your survey is excellent and rational[ Go to top ]
- Posted by: Elmira Fudd
- Posted on: March 10 2006 19:39 EST
- in response to Konstantin Ignatyev
It's a bit tiring to see how offended the 'new framework' authors get when this 'why another one?' question is raised. It's as I said in other threads, in Java/J2EE, folks get caught up in one-upmanship with frameworks; in PHP, people just get to work building usable software (Wikis, image galleries, catalog sites, forums, etc...). What the hell is our problem in Java land? Why do we need continous framework revolutions? It's sorta self defeating...
It doesn't matter if you make a sound technical choice today; next week, there will be yet another framework and its proponents will be sure to tell you just how you wrong you are for using your current technical choice.
Oh well... At least we have a few other sites like http://www.onjava.com/.
You wascals! -
Looks like a logger implementation issue to me[ Go to top ]
- Posted by: Elmira Fudd
- Posted on: March 10 2006 11:50 EST
- in response to javier castanon
I have read through this before and the main example cited in Tomcat is a logging implementation issue, not Commons Logging. The exception in the implementation is being handled incorrectly.
Encapsulation is valid, consistent logging that can be configured in an environment specific manner is also correct.
I fail to see an issue that would keep me from using it. Server side programming is complex, not meant for amateurs (at least setting up the environment shouldn't be left to them). Get the environment set up correctly and programmers can just use the logging APIs without worrying about implementation details -
Looks like a logger implementation issue to me[ Go to top ]
- Posted by: Guido Anzuoni
- Posted on: March 10 2006 12:14 EST
- in response to Elmira Fudd
Just my experience with unloading webapps with log4j and Tomcat.
Log4j uses Introspector to make some reflection magic during
configuration phase (I could be wrong, I fixed some months ago).
The problem is that, even if WeakHashMap are used, classes, that are keys in the maps, do not get gc in acceptable time (at least for me).
Putting
<code>
Introspector.flushCaches();
</code>
in my servlet fixed the issue.
Guido. -
Commons Logging lifecycle method[ Go to top ]
- Posted by: Elmira Fudd
- Posted on: March 10 2006 13:45 EST
- in response to Guido Anzuoni
The issue with commons logging has to do with logging objects classloaders going out of scope on a redeploy. If you have commons logging's graph of objects in the container's scope you have to clean up after yourself on a redeploy.
Here is an example in a context listener:
public void contextDestroyed(ServletContextEvent arg0) {
super.contextDestroyed(arg0);
ClassLoader contextClassLoader Thread.currentThread() .getContextClassLoader();
LogFactory.release(contextClassLoader);
Basically it blows away any references to the Commons logger objects that are about to go out of scope. If this isn't done you end up with orphaned objects that no longer have their classloader in the scope of the JVM. -
Looks like a logger implementation issue to me[ Go to top ]
- Posted by: Matt Jensen
- Posted on: March 10 2006 15:33 EST
- in response to Guido Anzuoni
Late versions of Tomcat call Introspector.flushCaches() for you. -
Think again before adopting the commons-logging API[ Go to top ]
- Posted by: Larry Singer
- Posted on: March 13 2006 02:52 EST
- in response to javier castanon
Is it just me or do other people start seriously doubting an article when the example code doesn't even compile.
The example java.util.logger code is a copy from the log4j code. This actually shows why there has not been widespread adoption of java.util.logger. The interfaces are quite imcompatible.
I have been successfully using commons-logging/log4j in Tomcat and other environments for many years now. -
Comparison of slf4j implementations - x4juli[ Go to top ]
- Posted by: Boris Unckel
- Posted on: March 10 2006 15:45 EST
- in response to Hani Suleiman
At first:
To have an overview of features and a comparison to JUL have a look at:
http://www.x4juli.org/features.htmlx4juli: A port of log4j to jdk14 API. Why anyone would use slf4j api backed by x4juli which is backed by jdk14 logging instead of jdk14 logging is a mystery that I suspect no one will ever solve.
Your are wrong. Simply wrong:
x4juli is in the backend of java.util.logging(JUL).
It offers a _native_ implementation of slf4j AND commons-logging at the same time. So what is the difference:
The original slf4j for JUL is a wrapper, so each logger has two objects at runtime: The original one from JUL and the wrapper object from slf4j. It is the same for commons-logging.
http://www.x4juli.org offers three frontends: java.util.logging.Logger, org.slf4j.Logger, org.apache.commons.logging.Log
There is no single wrapper, each method call to one of these class/interface methods has the *same cost* in obtaining the logger, producing the LogRecord, handle it.
Have a look at
http://svn.berlios.de/viewcvs/x4juli/trunk/src/java/org/x4juli/X4JuliLogger.java?view=markup
for details.
To repeat the correct chain:
slf4j ->(native)->x4juli -> do what is configured
JCL ->(native)->x4juli -> do what is configured
JUL ->(native)->x4juli -> do what is configuredIt's also often unclear with what needs to be deployed. In some cases you need two jars (the slf4j api and the impl), in some cases the impl contains the api.In short, do yourself a favour and avoid this stuff. Stick to log4j and you will avert much sadness.
In the case of x4juli 0.6 you have to use _one_ JAR (x4juli.jar) for using slf4j and JUL at the same time.
If you want to use JCL, slf4j, JUL at the same time you have put in additionally the commons-logging.jar.
While slf4j is configured by placing JARs, you do not have to configure to use slf4j->x4juli.
While JCL is configured by automation or properties you do have to configure it if you want JCL->x4juli.
Regards
Boris -
SLF4J 1.0 (final) has been released[ Go to top ]
- Posted by: Wille Faler
- Posted on: March 11 2006 12:19 EST
- in response to Hani Suleiman
You just wait 'til you see my "FactoryFactoryFactoryFactory"-framework.. -
SLF4J 1.0 (final) has been released[ Go to top ]
- Posted by: Eugene Lucash
- Posted on: March 11 2006 17:25 EST
- in response to Wille Faler
Did you mean your "SuperWrapperAbstractFactoryFactoryFacade" ? -
SLF4J 1.0 (final) has been released[ Go to top ]
- Posted by: Wille Faler
- Posted on: March 12 2006 11:22 EST
- in response to Eugene Lucash
Did you mean your "SuperWrapperAbstractFactoryFactoryFacade" ?
Possibly. The name isn't final yet.
However the purpose is to act as an abstract factory factory facade wrapper to Spring, Pico, custom Factories and last but not least, hideous mother-in-laws. -
Why all the SLF4J bashing?[ Go to top ]
- Posted by: Elmira Fudd
- Posted on: March 10 2006 08:47 EST
- in response to ceki Gulcu
Many of you seem to be quite happy with yet-another-MVC/Web/Persistence-framework releases here...why not logging?
You wascals! -
Why all the SLF4J bashing?[ Go to top ]
- Posted by: Freddy Daoud
- Posted on: March 10 2006 09:41 EST
- in response to Elmira Fudd
Many of you seem to be quite happy with yet-another-MVC/Web/Persistence-framework releases here...why not logging?
But this isn't another logging facility, it's another logging facade.. there's a big difference. Again I refer you to Tim's post above.
Frederic -
please explain[ Go to top ]
- Posted by: Adam Spencer
- Posted on: March 10 2006 09:17 EST
- in response to ceki Gulcu
Ok, I'm sure I'm missing the boat here and I'm sure that I'm going to get the crap kicked out of me for asking a question here on TSS ... but, why not just use the java.util.logging classes? That seems like the most logical thing for me to do considering that for the last ten years I have used all of the other classes that have been provided by the java.x packages. Obviously you can't use them in some of the earlier version of Java but for the versions where they are supported why not use them?
thanks,
Adam -
please explain[ Go to top ]
- Posted by: Freddy Daoud
- Posted on: March 10 2006 09:35 EST
- in response to Adam Spencer
Hi Adam,I'm going to get the crap kicked out of me for asking a question here on TSS ...
There are 'crap kickers' but there are also those who just want to help. Don't pay attention to the former, appreciate the latter and become one of them when someone else asks a question that you can answer. :-)Why not just use the java.util.logging classes?
You can certainly do that when you are writing a program. As a developer of an 'end application' (not sure what term to use here), the logging facility choice is yours.
However, when you are developing a framework or library, something that will be 'in the middle', to be used by 'end developers', you want to have some logging in your framework but you want to leave it up to the end developer to choose the logging facility. So as an end developer, you can continue to be happy with java.util.logging. But as a framework developer, you want to leave the choice open.
So that's where commons-logging comes in. In the framework, you log to that, and as the end developer, you configure which logging package you want to use.
Hopefully this clears things up.. also have a look (if you haven't already) at Tim's post above, he also gives a good explanation of some of the issues involved.
Frederic -
please explain[ Go to top ]
- Posted by: Adam Spencer
- Posted on: March 10 2006 09:45 EST
- in response to Freddy Daoud
Thanks for the reply Frederic! It's nice to get an answer and not a flame!
Let me elaborate a little more, I have written some frameworks in the past for use by other dev teams (though I will admit that they have been dev teams solely inside the same organization) and we used the java.util.logging classes to facilitate logging.
I understand the need to be able to tie into logging systems other than the java.util.logging system. But I guess what I'm asking is going forward, why not standardize on the logging that comes with the JDK in order to make things more interoperable and not use outside logging frameworks? Are the java.util.logging classes really that terrible? What are some of the technical deficiencies of the java.util.logging classes that would merit them not becoming the defacto standard for Java?
Sorry if my question was not clear enough before!
thanks again,
Adam -
Why an interface, really?[ Go to top ]
- Posted by: Elmira Fudd
- Posted on: March 10 2006 09:53 EST
- in response to Adam Spencer
Commons Logging is the logger of choice since it doesn't tie you down to any implementation of logging. If you need to send the logs VIA JMS,put a log scraper in, search for certain entries, display them on some console or whatever all you have to do is implement the interface and plug it in and you are off and running. All those nice packages that have the good sense to use it will do the right thing.
Late binding is a great thing, don't throw it away! -
Why an interface, really?[ Go to top ]
- Posted by: ticklish turtletoe
- Posted on: March 10 2006 10:26 EST
- in response to Elmira Fudd
Agreed. What is the slf4j team adding or fixing here? -
Too much time on his hands[ Go to top ]
- Posted by: Elmira Fudd
- Posted on: March 10 2006 10:28 EST
- in response to ticklish turtletoe
Simple as that. He needs to get a life. -
Too mean[ Go to top ]
- Posted by: Elmira Fudd
- Posted on: March 10 2006 10:31 EST
- in response to Elmira Fudd
That was mean, probably just doing it to try to learn something new -
java.util.logging capabilities clarification[ Go to top ]
- Posted by: Joseph Ottinger
- Posted on: March 11 2006 05:17 EST
- in response to Elmira Fudd
Commons Logging is the logger of choice since it doesn't tie you down to any implementation of logging. If you need to send the logs VIA JMS,put a log scraper in, search for certain entries, display them on some console or whatever all you have to do is implement the interface and plug it in and you are off and running.
It should be noted that java.util.logging can do the same thing, and without the interference of the coder (if that's appropriate) - the deployer can decide to do all of these things. It's fairly easy to do; logn does it, for example, and the JCL part of it was pretty easy to do. (Sorry for the unintended plug; I wrote and use logn, and I'm mentioning it here for example's sake only.) -
please explain[ Go to top ]
- Posted by: Alexandre Poitras
- Posted on: March 10 2006 09:57 EST
- in response to Adam Spencer
Thanks for the reply Frederic! It's nice to get an answer and not a flame!Let me elaborate a little more, I have written some frameworks in the past for use by other dev teams (though I will admit that they have been dev teams solely inside the same organization) and we used the java.util.logging classes to facilitate logging.I understand the need to be able to tie into logging systems other than the java.util.logging system. But I guess what I'm asking is going forward, why not standardize on the logging that comes with the JDK in order to make things more interoperable and not use outside logging frameworks? Are the java.util.logging classes really that terrible? What are some of the technical deficiencies of the java.util.logging classes that would merit them not becoming the defacto standard for Java? Sorry if my question was not clear enough before!thanks again, Adam
I agree with you it would be very logical but the JDK interfaces are quite limited unfortunately. It should have been developped as a standard specification and we wouldn't be in this mess :) -
please explain[ Go to top ]
- Posted by: Freddy Daoud
- Posted on: March 10 2006 10:01 EST
- in response to Adam Spencer
But I guess what I'm asking is going forward, why not standardize on the logging that comes with the JDK in order to make things more interoperable and not use outside logging frameworks? Are the java.util.logging classes really that terrible? What are some of the technical deficiencies of the java.util.logging classes that would merit them not becoming the defacto standard for Java?
Well Adam, that's a whole different question. It is indeed a good question -- why doesn't everyone use java.util.logging? I'd be interested to know what others have to say about this.
Here's my guess. Probably, java.util.logging suits most needs, but not all needs. Some people may have more specialized needs, so they use a more specialized library. If you start putting everyone's request into the core of Java, you'll end up with everything and the kitchen sink. I guess at some point you have to decide what belongs in the core and what is best suited as an 'add-on'.
I'm sure there are many more issues involved. If I'm not mistaken, for example, log4j came out before java.util.logging, to address the need. Then it was decided that there should be some logging facility in core Java, so that was added. Meanwhile, probably there were some developers who were using log4j from before and prefer to stick with it.
On the other hand, your point is certainly valid in that you could decide that java.util.logging is the standard within your company, just like a certain version of a certain browser can be the standard in a company's intranet. It certainly makes life easier for everyone.
Frederic -
please explain[ Go to top ]
- Posted by: Ric Wang
- Posted on: March 10 2006 10:33 EST
- in response to Freddy Daoud
I, too, don't quite understand why it is so desired that a framework need to have the capability of leaving the logging implementation to the apps that use it. I don't see it as a big plus, as a framework user, that I can manage the logging of the framework and my own app the same way.
If the framework "demands" JDK logging, let it be!
The only concern may be for those pre jdk1.4 usages. But other than that....
Not to be distractive and beating on the "dead horse", J2EE containers and APIs (at least the servlet API) "hard wire" their separate logging from apps. There are whiners about it, but not many. Yes, the argument goes that container and apps should be seperately treated. But one could argue the same for frameworks.
-Qingtian -
Hard wire[ Go to top ]
- Posted by: Elmira Fudd
- Posted on: March 10 2006 10:47 EST
- in response to Ric Wang
The servlet spec logging goes mostly unused and should go unused, it is a legacy of the original servlet spec.
The containers are switching to interfaces for their logging. As much as Weblogic screws things up with fundamental design issues I noticed that they use logging interfaces in their Portal server implementation. It may be a pile of crap under the covers (what do you expect when you have a team of VB developers straight from Microsoft develop something in Java) but they got that one thing right.
Again, this bit of abstraction is very powerful, don't throw it away. The servlet callbacks use interfaces as well, the container's classloader cannot see your servlet classes but it can certainly call the interface methods bound to it during deployment.
Interfaces should be thought of as a boundary around a piece of functionality, encapsulation if you will. Get your head wrapped around it and you will eventually see the light. It is a contract that can deal with many implementations, logging is just one example of that. -
Never mind[ Go to top ]
- Posted by: Elmira Fudd
- Posted on: March 10 2006 10:57 EST
- in response to Elmira Fudd
I get a lot of requests for information on how to grill trout right. The first rule I've found is to not think about it that much. Trout is meant to be grilled. The direct heat cooks trout fast, easy and without removing moisture. Grilled trout is flavorful and juicy. The second rule about grilling trout is to make sure it doesn’t stick. Whether you oil the cooking surface or brush the trout with a little oil, make sure that you have a non-stick surface to work with.
Apart from that, trout is easy and fast. You can literally get trout off the grill in a matter of minutes, thus making trout the perfect after work meal. Pick up a couple of filets and lemon or two and light up the grill as soon as you get home. Trout is also great for dinner parties when you never know exactly when people will arrive. Before dinner you can get the trout soaking in a marinade or otherwise seasoned up and light up the grill a few minutes before everyone wants to eat. -
Hard wire[ Go to top ]
- Posted by: Ric Wang
- Posted on: March 10 2006 10:57 EST
- in response to Elmira Fudd
I knew it'd be distractive, but anyways....
If interface is -the- thing to seek after, why can't the framework defines its own logging interface, and let the user implement it?
-Qingtian -
Logging is logging[ Go to top ]
- Posted by: Elmira Fudd
- Posted on: March 10 2006 11:17 EST
- in response to Ric Wang
There is an interface for logging that is generally accepted that most open source projects use, it is Commons Logging. It has nothing to do with any specific framework, it is a logging interface.
No need to reinvent the wheel here, just use it and you will be able to use the same logger for your code, the open source projects, etc.
We log things to a JMS server with certain error statuses, we have have other applications that scrape the messages and route them to the appropriate support people and developers.
The application developer's just have to worry about appropriate error messaging, not what happens to what they log. This is an appropriate use of encapsulation through the use of interfaces. -
Logging is logging[ Go to top ]
- Posted by: Ric Wang
- Posted on: March 10 2006 11:51 EST
- in response to Elmira Fudd
I don't think Commons Logging is the -interface- concept we are talking about here. It has it's own "wrapping" implementation. And it is that implementation that present problems to some. And again, I still don't quite understand why we need whole other "framework" to address the issue. Let's see what it takes for the framework and users to "reinvent the wheel" - Oh my! It's more than 25 lines of code just to define the interface in the framework, and it takes much more than 50 lines for the user to implement it!.... I mean, come on! What makes a "non-encapsulative" logger like jdk14 or log4j so evil? Why is it such a big problem that justify another big time "framework" to address it? -
Because java.util.logging sucks big time![ Go to top ]
- Posted by: Daniel Serodio
- Posted on: March 15 2006 17:37 EST
- in response to Adam Spencer
Ok, I'm sure I'm missing the boat here and I'm sure that I'm going to get the crap kicked out of me for asking a question here on TSS ... but, why not just use the java.util.logging classes?
See Ceki's critique of java.util.logging (back when it was just a JSR, not an implementation):
http://web.archive.org/web/20030416202606/http://jakarta.apache.org/log4j/docs/critique.html -
MessageFormat[ Go to top ]
- Posted by: Mark Andersen
- Posted on: March 10 2006 10:51 EST
- in response to ceki Gulcu
I do like the MessageFormat feature though which gives me the ability to provide a message string (ala printf) and an array of values to insert. This also avoids a lot of unnecessary string concatenation if it is a debug message and the debug level is not active. -
MessageFormat[ Go to top ]
- Posted by: Tim Fennell
- Posted on: March 10 2006 13:25 EST
- in response to Mark Andersen
I do like the MessageFormat feature though which gives me the ability to provide a message string (ala printf) and an array of values to insert. This also avoids a lot of unnecessary string concatenation if it is a debug message and the debug level is not active.
At first I thought that looked kinda cool too, until I realized that the interface appears to limit you to two replacement parameters (I didn't dig deeper, there may be other APIs that allow you to add more).
One of the things that I've been hoping for, for a while now, is a new version of commons-logging which makes better use of varargs. For my own internal use I wrote a tiny utility class which uses varargs, and only if the message will get logged, concatenate all the items together to make the message. Take a look at the implementation, it's a simple but neat little trick.
-Tim Fennell
Stripes: Because web development should just be easier. -
MessageFormat[ Go to top ]
- Posted by: Mark Andersen
- Posted on: March 10 2006 14:14 EST
- in response to Tim Fennell
I do like the MessageFormat feature though which gives me the ability to provide a message string (ala printf) and an array of values to insert. This also avoids a lot of unnecessary string concatenation if it is a debug message and the debug level is not active.
At first I thought that looked kinda cool too, until I realized that the interface appears to limit you to two replacement parameters (I didn't dig deeper, there may be other APIs that allow you to add more).One of the things that I've been hoping for, for a while now, is a new version of commons-logging which makes better use of varargs. For my own internal use I wrote a tiny utility class which uses varargs, and only if the message will get logged, concatenate all the items together to make the message. Take a look at the implementation, it's a simple but neat little trick.-Tim FennellStripes: Because web development should just be easier.
There's a method that takes an object[] as its last parameter (not vararg) so it a little ugly, but still usable. -
Who would avoid using a library because of java.util.logging?[ Go to top ]
- Posted by: Brian Smith
- Posted on: March 10 2006 17:11 EST
- in response to ceki Gulcu
I am also in the "why not just use java.util.logging" camp. Honestly, who in their right mind is going to avoid using a library because it uses java.util.logging instead of Log4J or Commons Logging? Almost nobody. That means, library developers are free to choose java.util.logging without having to worry about losing whatever popularity contest they think they are in.
Now, some people say that Log4J is better and I will just take their word for it and say that it is 10 times better than j.u.logging. But, logging is so trivial that even if Log4J is 100 times better than java.util.logging, it is still barely any improvement at all.
Remember the posting from last week "98 percent of Java developers don't need it?" https://www.theserverside.com/news/thread.tss?thread_id=39236 Well, that DIRECTLY applies to Commons Logging, Log4J, and this library. The 2% of developers that are developing applications so sophisticated that they _need_ more than java.util.logging provides are unlikely to be satisfied with the Commons Logging either.
Library developers: Logging frameworks are not helpful to us. You are wasting time (yours and your users') to solve a problem that doesn't exist, while causing problems that nobody should to deal with. _Please_ just use j.u.logging.
I thought that this got posted on TSS as a joke hot off the heals of "Why I Hate Frameworks":
http://discuss.joelonsoftware.com/default.asp?joel.3.219431 -
A Solution for the Confusion[ Go to top ]
- Posted by: Elmira Fudd
- Posted on: March 14 2006 15:53 EST
- in response to ceki Gulcu
Here's a simple solution for all of the confusion. Just change the name to ALF4J: Another Logging Facade for Java.