[jboss-dev] My logging ultimatum

[Scott M Stark]

The main problem I have had with JUL integration in the past is that it
requires hooking into the core configuration at the extension classpath
level. I had to replace the JUL manager to allow for configurations that
loaded loggers from application/thread context class loaders. Not that
this is hard, its just something that has to be part of the server
bootstrap process rather than something that can be done via late binding.

Its been a while since I looked at integration though. With the other
mega-thread about i18n/JUL integration, we need some tasks to
investigate what we can/want to do in terms of allowing seamless
integration from framework JUL usage to be mapped to server loggers, and
what the jboss logging spi is.

Bela Ban wrote:
> 
> 
> Tim Fox wrote:
>> +100 to David on this.
>>
>> The point here is about reducing number of dependencies. Another
>> meta-framework (like jboss common logging) is not a good solution
>> IMHO. This is particular important for OEMs who may want to use our
>> project embedded in their own applications (this is what we intend to
>> do for JBM2)
>>
>> If JDK logging can allow you to delegate to you log tool of choice by
>> deploy time configuration, and the bugs in JDK logging are only bugs
>> in the JDK logging implementation which you can bypass anyway, then we
>> should all be using JDK logging surely.
>>
>> I'm certainly going to look at refactoring JBM to use JDK logging.
> 
> Me too. If Adrian and/or Scott can tell me that this will not cause
> issues in the appserver because they can wrap/redirect my calls to JUL
> to log4j (or their own logging impl), then that would be fine. Otherwise
> I'd probably wait for JDK 7
>