[jboss-dev] My logging ultimatum

[Jason T. Greene]

Good question :) If you want to get rid of a JAR, use the JDK logging 
API (writing your own wrapper) for your projects (no dependencies). 
Where jboss-common-logging gets interesting is that it provides a log4j 
appender framework for JDK logging on JBoss. This, IMO should be the 
default, but it's a major change for the AS.

Bela Ban wrote:
> So now we replace commons-logging.jar with commons-logging-jboss.jar ? 
> Where does removing a JAR come into play ? :-)
> 
> Jason T. Greene wrote:
>> 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.
>>>
>>
>> The jboss-common-logging project has a JDK appender with essentially 
>> the same feature set as log4j. I myself added support for MDC and NDC 
>> awhile back. So any jboss project which uses jboss-common-logging, 
>> supports both JDK and log4j logging.
>>
> 


-- 
Jason T. Greene
JBoss, a division of Red Hat