Re: [Resteasy-developers] Logging Configuration Details

[Ryan J. M. <ry...@da...>]

On Jul 8, 2008, at 8:59 AM, Martin Algesten wrote:

>
> (posting from another thread)
>
> On 8 Jul 2008, at 14:31, Ryan J. McDonough wrote:
>
>>> Btw I also made sl4j-log4j dependency optional since I hate log4j  
>>> with
>>> a passion, and depending on resteasy currently pulled that crud into
>>> my project.
>>
>> But do you share the same hatred of slf4j? I agree we should not  
>> impose the log4j on any one, but I'm still partial to including  
>> slf4j so that a log4j or other provider is optional but RESTEasy  
>> logging details are written to the log of their choice. If folks  
>> just simply don't like the idea of slf4j, we can yank it, but then  
>> again I hate JDK logging and System.out with a passion ;) Thoughts?
>
> I agree we want logging and no System.out. My criteria for good  
> logging is:
>
> 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.

>
>
> 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.

> 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.


> Bottom line is that I think all logging framework suck. In previous  
> projects I've always preferred just making a small wrapper class  
> local to the project. It defaults to using java.util.logging to  
> satisfy the out-of-the-box criteria. Generally only bigger projects  
> really require all their logging to conform, which means they can  
> spend the effort tweaking my wrapper to do what it needs to.
>

They do all suck, but some suck less can do the job better than others.

> M
>
>
>