directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <>
Subject Re: upgrading to nlog4j.1.2.17
Date Mon, 10 Oct 2005 14:59:07 GMT
Hi Nick,

At 03:37 PM 10/10/2005, Nick Faiz wrote:
>Hi Ceki,
>Well, this is a troubling response.


>My main issue is that, up until now, the classpath conflict between
>nlog4j and log4j has not been stated. We have discussed the fact that
>nlog4j code requires nlog4j on the classpath but not the classpath

Yes, in my message dated "Tue, 13 Sep 2005 09:48:55 +0200", I wrote:

   As of NLOG4J 1.2.16, code compiled against log4j.jar will run fine
   with nlog4j.jar. However, the inverse is not true. Code compiled with
   NLOG4J will only run with NLOG4J. This means that your code, when
   compiled with NLOG4J, will depend on NLOG4J, which in my humble
   opinion is a rather reasonable requirement, especially if you consider
   that NLOG4J has SLF4J support which log4j does not have.

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?

>It is, however, only an API incompatibility, and I think
>that we can quite easily perform a refactor to roll back to log4j, if
>we need to.
>Given the constraint that it is now an either/or scenario between
>log4j and nlog4j, if ApacheDS were to be embedded in an existing
>log4j application, the log4j jar would have to be removed. I see this
>as an insurmountable problem, for many applications. I can understand
>why it is present, now that you have explained it, but I wish it
>would have been stated earlier.

To summarize: one cannot leave log4j.jar and nlog4j.jar simultaneously
on the class path.

I apologize if this has not been stated this explicitly before.

>On 10/10/2005, at 6:59 PM, Ceki Gülcü wrote:
>>The test suite also reproduces a well known compatibility problem.
>>Code compiled against nlog4j.jar will not run with log4j.jar on the
>>class path.
>This has never been stated before, I cannot see how it has been well
>known. Indeed, our latest emails have attempted to overcome this
>problem. See your reply on the 13th of September, (in attachment). If
>we had this information before, we would have had an immediate answer
>to our questions.

It was always clear to me that one could not have both jar
on the class path at the same time. In my mind, the previous set
of emails was about preventing log4j.jar from being "exported"
by modules.

>I cannot help but think you have only just now discovered that there
>is a classpath conflict. I am glad, all the same, that you have made
>the point. We can, at least, now make an informed decision (again)
>about which logging framework to use.


>Well, most of this makes sense now. In light of the classpath
>conflict mentioned above, we could not possibly expect ApacheDS to be
>embedded with existing log4j applications without causing errors.

You could mention in the document that log4j.jar would need to
be replaced with nlog4j.jar.

>I, for one, am in favour of rolling back to log4j. I know that I
>won't have the option of removing log4j from certain applications
>which I would like to experiment with, using ApacheDS.

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.

>I'll discuss this further with the ApacheDS guys.

Sure, that's the right thing to do.


Ceki Gülcü

   The complete log4j manual:

View raw message