Ceki Gülcü wrote:
At 04:49 PM 2/24/2006, Endi S. Dewata wrote:
Hi Ceki,
> Which version of NLOG4J and ApacheDS are you using? Versions of NLOG4J
> prior to 1.2.16 did indeed have a runtime compatibility issue with
log4j.
> However, NLOG4J version 1.2.16 and later should not suffer from the
> problem you describe. Thus, it is important to know the version of
> ApacheDS and NLOG4j that you are using.
I'm checking out the latest ApacheDS (version 1.0 RC1) from the svn
trunk,
the apacheds/core/pom.xml says that it's using nlog4j version 1.2.19.
I also downloaded JBoss 4.0.3 SP1 source code, and there is a
log4j.jar file
in thirdparty/apache-log4j/lib directory which should be version 1.2.8
according to component-info.xml.
So I tried compiling a small program using Log4j API:
import org.apache.log4j.*;
public class Test {
public static void main(String args[]) {
Logger log = Logger.getLogger(Test.class);
log.debug("Test");
}
}
I compiled it with nlog4j-1.2.19.jar, then I tried to run it with
log4j.jar
from JBoss, then I got this error:
Exception in thread "main" java.lang.NoSuchMethodError:
org.apache.log4j.Logger.debug(Ljava/lang/Str
ing;)V
It looks like the nlog4j has a debug(String) but the log4j doesn't.
I also tried the following program using SLF4J API:
import org.slf4j.*;
public class Test {
public static void main(String args[]) {
Logger log = LoggerFactory.getLogger(Test.class);
log.debug("Test");
}
}
I compiled it with nlog4j-1.2.19.jar, then I tried running it with
log4j.jar
and nlog4j-1.2.19.jar in the class path in this order, then I got this
error:
Exception in thread "main" java.lang.IncompatibleClassChangeError
The error also occurs when executing log.debug(...) statement.
If I reverse the order of the jar files, it will work fine because
nlog4j
will be loaded first. However in JBoss this is not possible because
JBoss
classes will be loaded first before the SAR files. Any suggestions?
Thank
you very much.
Endi,
I think your description of the problem is quite valuable.
Compilation against NLOG4J is sticky, in the sense that you cannot
later revert back to log4j. However, I think that this is not the
problem you are facing. As far as I know ApacheDS does not invoke
log4j directly, it invokes the SLF4J API instead. From what you
describe, the mere presence of log4j in JBoss' class loader path,
messes up SLF4J's NLOG4J binding.
Yeah this is all together another problem. ApacheDS only makes SLF4J
logger calls.
As an immediate fix, you can just replace JBoss' copy of log4j with
NLOG4J. This should fix the problem as far as you are concerned.
Another perhaps better solution, is to replace nlog4j.jar which ships
with ApacheDS with slf4j-log4j12.jar without replacing any jar files
in JBoss. FYI, slf4j-log4j12.jar ships with the SLF4J distribution.
Note that we allow this to happen by making the scope of the slf4j API
provided. Meaning you decide which version to deploy. Take a look Endi
at the poms you will see the scope tag set on these dependencies.
I guess that this should be added to ApacheDS documentation in order
to avoid similar inconveniences to other JBoss+ApacheDS users. Maybe
that is already the case?
No we have not done this but we should. Sorry for the inconvenience to
both you Ceki and you Endi. We now though know how to work around this
problem.
Thanks,
Alex
