[jboss-dev] My logging ultimatum

[David M. Lloyd]

This is my point - on the one hand you reject the only solution, and on
the other, you refuse to use an otherwise good library because of the
problem. :-)

But my point is exactly this.  JDK logging is two things.  First, it's
a logging API - like commons-logging, but *built in*!  Second, it's a
(pretty crappy) appender framework.

OK, sure, the handlers aren't that great.  But guess what?  The user
already has stuff using JDK logging just by virtue of using the JDK!
And just about every container supports JDK logging (well, except for
ours anyway).

Trust me, the user would rather deal with (just) JDK logging than
having 4 different logging JARs in their classpath.

Has anyone ever explored the possibility of getting the log4j people to
supply a JDK LogManager that maps JDK logging to log4j?  That would
solve the non-container case.  I may take a day this week to just write
one, or rather adapt the one I've already written.

- DML

On Tue, 11 Dec 2007 18:16:39 +0100
Bela Ban <bela at jboss.com> wrote:

> I'd love to switch over to the JDK logging (I could drop the 
> commons-logging and log4j JARs), but I'm told it seriously sucks, not in 
> terms of the API (which can be wrapped), but in terms of configuration 
> from a users point of view. And I'm not talking about the appserver 
> which comes with logging enabled, I'm talking about libs like JGroups 
> which make the dev who integrates JGroups have the pain.
> 
> BTW, JGroups won't use MINA until it drops the dependency on slf4j.
> 
> David M. Lloyd wrote:
> > Developing Remoting 3 I discovered that, thanks to depending on MINA
> > and JBoss Serialization, I now have an indirect dependency on both
> > log4j and slf4j. This sucks. I'm tired of dealing with issues with
> > logging when this problem should have been solved years ago.
> >
> > I've asked Clebert to change JBoss Serialization to use JDK logging.
> > His (valid) concern is that JBAS 4.2.x doesn't support JDK logging
> > (except for the wedge that Stan Silvert wrote for JSF).
> >
> > My feelings are as follows:
> >
> > * The JBossAS logging system must be changed such that BY DEFAULT log
> > messages are all handled properly (in terms of category and level),
> > regardless of the logging framework used (java.util.logging or log4j).
> > No, relying on the System.out/System.err capture mechanism is NOT
> > sufficient for this task. This means that, as far as I can tell, we
> > should always be installing a JUL LogManger on appserver startup.
> > Frankly it really baffles and disappoints me that 4.0.x and 4.2.x didn't
> > do this out of the box.
> >
> > * ALL framework devlopers should switch to java.util.logging. This is
> > the ONLY way you can have logging without introducing a JAR
> > dependency. Yeah the API kind of sucks, but it's easily worked around
> > (here's one way: http://tinyurl.com/3848rr - notice the lack of
> > external JAR dependencies). It's far better for the framework
> > developer to embrace suckage, so that the end-user doesn't have to.
> >
> > * The end application developer should be able to use whatever
> > logging API they like the best without surprises.
> >
> > A while back Scott indicated that there would be the option of a JDK
> > logger in AS 5, and maybe it would even be the default one. The
> > discussion thread is at:
> >
> > http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3904365
> >
> > though unfortunately, the whole theme of the discussion is "which
> > logging framework to use, log4j or jdk" and the issue was confused by
> > the faulty assumption that by using one, we would no longer be able to
> > support the other. So I'm actually sort of confused as to the outcome
> > of that.
> >
> > In any case, Remoting 3 will use JDK logging, at least until someone
> > stops me. And I will continue my efforts to get JBSER and MINA changed
> > over to JDK logging as well.
> >
>