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 Mon, 10 Oct 2005 22:31:37 GMT
Hi Ceki,

Are you sure that this conflict is unavoidable? It would be great if  
all of the methods present in the original log4j Logger could be  
represented in the nlog4j implementation (down to identical method  
arguments). It was my understanding that we were seeing this issue  
because some of the arguments had changed in nlog4j.

I think slf4j loses quite a bit of 'adoptability' by not being able  
to function alongside log4j.

On 11/10/2005, at 12:59 AM, Ceki Gülcü wrote:

> As you say, NLOG4J requiring NLOG4J has been previously stated.  As
> for the class path requirement, it's kind of an obvious and basic
> housekeeping chore. Isn't it *always* unsafe to have distinct versions
> of a library present on the class path?

Well, yes and no. While it is healthy, for many reasons, to prevent  
duplication of classes on the classpath, it has never been a problem  
to have two distinct versions of log4j on the classpath. At least,  
I've never found it to be a problem. Now we have introduced mandatory  
housekeeping. :) I know that quite a few administrators will just ask  
people to use log4j, instead of SLF4J.

> I see why replacing one jar with another might be impossible under
> certain circumstances. It's an additional step that needs to be
> performed which one might consider as unnecessary hassle.

Well, there is now an issue of 'accessibility of adoption', or  
something like that.

The classpath conflict is not so much an unnecessary hassle as a  
prohibition. Some managers won't risk the smooth running of  
enterprise applications just to upgrade a logging framework,  
especially if the existing one is running well.

Without that upgrade, ApacheDS won't see the light of day, in  
embedded use-cases, for such applications.


View raw message