[prev in list] [next in list] [prev in thread] [next in thread] 

List:       slf4j-dev
Subject:    [slf4j-dev] org.slf4j.LoggerFactory in [n]log4j.jar
From:       robertburrelldonkin () blueyonder ! co ! uk (robert burrell donkin)
Date:       2005-06-02 23:49:50
Message-ID: 1117749558.5150.45.camel () knossos ! elmet
[Download RAW message or body]

On Tue, 2005-05-17 at 18:47 +0200, Ceki G?lc? wrote:
> At 17:51 5/17/2005, Curt Arnold wrote:
> 
> >I was not suggesting that they be used in combination, but that both
> >log4j.jar from the current CVS HEAD and nlog4j.jar (fork from the
> >log4j 1.2 branch) result in the same behavior since they both contain
> >implementations of org.slf4j.LoggerFactory.
> 
> So, the user would always opt for log4j.jar instead of nlog4j.jar. I'm OK 
> with that.
> 
> 
> >Case 2 is exactly what I was trying to describe.  It seems like a
> >valid concern to me and suggests to me that it would be better to
> >have a separate slf4j-log4j.jar than to embed org.slf4j.LoggerFactory
> >in log4j.jar.
> 
> Having slf4j-log4j.jar is a possibility opening the door for further 
> complexity. In my opinion, it's a bad idea.

IMHO there are a number of not unreasonable use cases (such as this one)
which can be solved only by additional complexity. one of the lessons
i've learnt about supporting JCL is that it's very important to
distinguish between recommendations about how to use logging bridges
simply and effectively, and providing support for more complex use cases
tackled by experts. 

in many ways, the key is documentation both written and self
documentation of releases. provided that the documentation clearly
indicated the limited use cases where the use of separate jars would be
useful and that they were tucked away in an optional directory, these
jars would allow a reasonable use case to be supported without too much
collateral damage.

- robert

[prev in list] [next in list] [prev in thread] [next in thread]