directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Faiz <>
Subject Re: upgrading to nlog4j.1.2.17
Date Wed, 12 Oct 2005 22:40:51 GMT

Yes, in standalone mode it isn't an issue.

For embedded, you could switch your underlying implementation if  
needed. It would, however, be against the very purpose of the SLF4J  
facade to adopt a secondary logging frameworking by switching to a  
slf4j alternative logger because your logging library of choice was  

Also, it introduces some policing to ensure that nlog4j and log4j are  
not on the same classpath. It's another factor which could be gotten  

As Emmanuel said in reply to your email, Ceki is thinking on this  
right now.


On 13/10/2005, at 5:34 AM, Jérôme Baumgarten wrote:

> Hi guys,
> On 10/12/05, Nick Faiz <> wrote:
>  <snip />
> Okay. I understand that it might seem like a noisy chat about SLF4J,
> not ApacheDS.
> My motive is simple. I am only concerned about logging for ApacheDS.
> It has become an ApacheDS issue.
> >  - third, I think that Ceki did a lot of good job, he also really
> > helped
> > us, and I don't want him to think that we think that log4j is a
> > pile of
> > bok...
> >
> Agreed.
> Cheers,
> Nick
> If you go for SLF4J, wouldn't that resolve your problem. For  
> running in a standalone more, you then can choose whatever SLF4J  
> version you want, the one using Simple-Log or nlog4j. Using  
> ApacheDS embedded in another application, you can also choose the  
> most appropriate SLF4J version. If you may get into troubles  
> because of log4j then you go for the Simple-Log based SLF4J. This  
> could easily be resolved by externalizing the logging jar.
> Jérôme

View raw message