Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: neutral (asf.osuosl.org: 64.39.31.158 is neither permitted nor
 denied by domain of nickfaiz@gmail.com)
Mime-Version: 1.0 (Apple Message framework v733)
In-Reply-To: <6.0.3.0.0.20051010163659.033ac728@torino>
References: <43262BF5.3010704@atlassian.com>
 <6.0.3.0.0.20050913094005.0327ebd0@torino> <43269428.1070800@atlassian.com>
 <6.0.3.0.0.20050913141127.0394a7f8@torino> <43279B80.6050102@atlassian.com>
 <6.0.3.0.0.20051005154438.03b41308@torino> <4344A731.6030200@atlassian.com>
 <6.0.3.0.0.20051010100332.03b8ce70@torino>
 <6B4C9AA3-738C-4FB6-A7C9-58EC970C92B5@atlassian.com>
 <6.0.3.0.0.20051010163659.033ac728@torino>
Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
Message-Id: <733AB419-0247-4FBD-B9F1-4D63F27D98C7@gmail.com>
Content-Transfer-Encoding: quoted-printable
From: Nick Faiz <nickfaiz@gmail.com>
Subject: Re: upgrading to nlog4j.1.2.17
Date: Tue, 11 Oct 2005 08:31:37 +1000
To: "Apache Directory Developers List" <dev@directory.apache.org>

Hi Ceki,

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

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

On 11/10/2005, at 12:59 AM, Ceki G=FClc=FC 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 =20
duplication of classes on the classpath, it has never been a problem =20
to have two distinct versions of log4j on the classpath. At least, =20
I've never found it to be a problem. Now we have introduced mandatory =20=

housekeeping. :) I know that quite a few administrators will just ask =20=

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 =20
something like that.

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

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

Cheers,
Nick