[jboss-dev] My logging ultimatum

[Tim Fox]

I think what we really need here is to write another "meta" logging 
framework for our projects to use, and that can just delegate to slf4j, 
log4j, java.util logging etc ;)

Seriously though, I echo many of David concerns.

We are in a similar position as David (and Bela) with MINA - I don't 
really want to pull in a slf4j dependency. Although I understand Trustin 
has some difficulty in removing this due to the way Apache democracies 
work :(


David M. Lloyd wrote:
> 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.
>>>
>>>       
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
>