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.

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.

very slow...

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 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...

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...

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.

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.

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.

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.

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.

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

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.

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

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

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.

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.

Anyone using commons-logging ever notice how you can't cleanly hot deploy in Tomcat but you can in JBoss?

Yahoo!

"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!

"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?

"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

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!

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

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.

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.

Late versions of Tomcat call Introspector.flushCaches() for you.

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.

At first:
To have an overview of features and a comparison to JUL have a look at:
http://www.x4juli.org/features.html

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.

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 configured

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.

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

You just wait 'til you see my "FactoryFactoryFactoryFactory"-framework..

Did you mean your "SuperWrapperAbstractFactoryFactoryFacade" ?

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.

Many of you seem to be quite happy with yet-another-MVC/Web/Persistence-framework releases here...why not logging?

You wascals!

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

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

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

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

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!

Agreed. What is the slf4j team adding or fixing here?

Simple as that. He needs to get a life.

That was mean, probably just doing it to try to learn something new

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.)

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,&nbsp;&nbsp;&nbsp;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 :)

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

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

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.

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.

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

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.

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?

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

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.

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.

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.

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

Here's a simple solution for all of the confusion. Just change the name to ALF4J: Another Logging Facade for Java.