Re: [Resteasy-developers] Logging Configuration Details

[Martin A. <sp...@ma...>]

On 8 Jul 2008, at 15:11, Ryan J. McDonough wrote:

>> 1) Needs to work out-of-the-box, no additional configuration, jars  
>> etc etc. log4j fails on the remarkably irritating lack of  
>> reasonable defaults (no logging out of the box). slf4j fails on  
>> requiring the presence of an implementation jar (would be much  
>> better if it defaulted to java.util.logging that could be  
>> overridden by dropping in a jar).
>
> True, but the same can be said of JCL too.

Haven't looked at JCL, but I take your word for it :)

>> 2) Needs to be non-intrusive. I don't want to sprinkle the class  
>> files with crud to get a logger in place. log4j does this nicely,  
>> Logger.getLogger( MyClass.class ) is all I need + the import. slf4j  
>> fails because of the factory pattern  
>> LoggerFactory.getLogger( MyClass.class ) + two imports (same goes  
>> for java.util.logging) - but then slf4j is a bit better than  
>> java.util.logging since the following construct in java is truly  
>> hideous:
>
> I can live with 2 import statements if it's easier to use.

I can live with 2 statements too - it just irritates me.

>> if ( logger.isLoggable( Level.FINE ) ) {
>> logger.fine( "Blah blah" );
>> }
>>
>> instead of
>>
>> if ( logger.isDebugEnabled() ) {
>> logger.debug( "Blah  blah" );
>> }
>
> Even better, slf4j supports parameterized messages such that:
>
> logger.debug("The new entry is {}.", entry);
>
> You don't need to check isDebugEnabled() as that is handled  
> internally. If debug is not enabled, the message will not be parsed.

Yeah, I like that, and in my wrappers I always implemented that myself  
using java.text.MessageFormat. I guess my main concern with slf4j is  
that to get it working out-of-the-box we need to hard link to one  
implementation jar - and whichever we chose it's going to be the wrong  
one for someone.

M