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
conflict. 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.
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.
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.
Regarding the message "Problem embedding 0.92 ApacheDS" posted by Thom
Park, unless I am missing something obvious, it looks like that Thom
is using log4j.jar instead of nlog4j.jar. We have already established
that that won't work, for the simple reason that log4j does not offer
SLF4J support.
Well, it won't work because of what is mentioned above.
As a side note, Thom mentioned that he had followed the "instructions
in the doc for embedding ApacheDS". Which doc is that? I could not
find it, but admittedly I did not search for long.
I will have to follow up on this document.
Nick, would you concur with the above assessment?
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.
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'll discuss this further with the ApacheDS guys.
Cheers,
Nick
{\rtf1\mac\ansicpg10000\cocoartf824\cocoasubrtf100
{\fonttbl\f0\fswiss\fcharset77 Helvetica-Bold;\f1\fswiss\fcharset77 Helvetica;}
{\colortbl;\red255\green255\blue255;\red0\green0\blue0;\red0\green0\blue0;\red0\green0\blue221;
}
\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\ql\qnatural\pardirnatural
\f0\b\fs24 \cf2 From:
\f1\b0 \cf3 Ceki G\'9flc\'9f <[EMAIL PROTECTED]>\
\f0\b \cf2 Date:
\f1\b0 \cf3 13 September 2005 5:48:55 PM\
\f0\b \cf2 To:
\f1\b0 \cf3 "Apache Directory Developers List" <[email protected]>\
\f0\b \cf2 Subject: \cf3 Re: upgrading to nlog4j.1.2.17\
\cf2 Reply-To:
\f1\b0 \cf3 "Apache Directory Developers List" <[email protected]>\
\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\ql\qnatural\pardirnatural
\cf3 \
\
Hello Nick,\
\
Could you send me the a stack trace of the NoSuchMethodError?\
\
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.\
\
Considering the direction of compatibility, perhaps you are trying to access methods only available in nlog4j when only log4j.jar is available in the class path?\
\
Being somewhat familiar with IDEA, I'd be happy to try reproduce the problem. Do you have a tiny project/test case to make it easy for me?\
\
Cheers,\
\
At 03:31 AM 9/13/2005, Nick Faiz wrote:\
\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\li200\ql\qnatural\pardirnatural
\cf4 Hey Alex (and others),\
\
I was originally sending this to Alex, as a follow up to an interrupted IM chat, but thought it relevant to send to the dev list. It relates to upgrading nlog4j.\
\
Check out maven.org/ibiblio under org.slf4j - you will find nlog4j.1.2.17 .\
\
http://www.ibiblio.org/maven/org.slf4j/jars/\
\
We need to find a solution for this NoSuchMethodError - I keep seeing it in IDEA but havent had time to test with ApacheDS in any other embedded capacity. It's a blocker.\
\
Whenever I hit an nlog4j log statement in IDEA, when I have several modules open, and when my own source code uses log4j but one of the modules references ApacheDS, I see a NoSuchMethodError.\
\
Nick\
\
--\
ATLASSIAN - http://www.atlassian.com/\
\
Confluence - the enterprise wiki - tried it yet?\
http://www.atlassian.com/confluence/\
--\
\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\ql\qnatural\pardirnatural
\cf3 \
-- \
Ceki G\'9flc\'9f\
\
The complete log4j manual: http://www.qos.ch/log4j/\
\
\
}
[1] http://svn.slf4j.org/viewcvs/nlog4j/trunk/tests/build.xml?
view=markup
Cheers,
Nick
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
