Hi Nick,
At 03:37 PM 10/10/2005, Nick Faiz wrote:
Hi Ceki,
Well, this is a troubling response.
Acknowledged.
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
conflict.
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.
Absolutely.
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.
Cheers,
Nick
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
