Can you let me know if recompiling fixed the logger incompatibility? If it did we can document it somewhere. If it didn't we'll have to find another fix.
Cheers,
Nick
Thom,We're sorry that you're seeing this problem.Are you able to recompile 0.9.2 from source and include that result in your app.? If so, could you open apacheds/trunk/project.xml and replace the current nlog4j dependency with this:<dependency><groupId>org.slf4j</groupId><artifactId>nlog4j</artifactId><version>1.2.17</version><url>http://slf4j.org/nlog4j</url></dependency>Running `maven -Dmaven.test.skip=true multiproject:install ` at the same location will compile the jars for you.I can't guarantee that this will fix the problem but I think the 0.9.2 version uses nlog4j 1.2.14, which was having issues along these lines.Cheers,NickOn 30/09/2005, at 5:13 AM, Thom Park wrote:Hmm…
After following the steps in ServerMain, I'm now getting loads of errors from log4J:
If I have the ApacheDS down the classpath from my application, I find I get this error:
SLF4J built for org.slf4j.impl.Log4jLoggerFA
Exception in thread "main" java.lang.IncompatibleClassChangeError
at org.apache.ldap.server.jndi.ServerContextFactory.startLdapProtocol( ServerContextFactory.java:222 )
at org.apache.ldap.server.jndi.ServerContextFactory.afterStartup( ServerContextFactory.java :108 )
at org.apache.ldap.server.jndi.DefaultContextFactoryService.startup( DefaultContextFactoryService.java:204 )
at org.apache.ldap.server.jndi.AbstractContextFactory.getInitialContext( AbstractContextFactory.java :99 )
at javax.naming.spi.NamingManager.getInitialContext( NamingManager.java:667 )
at javax.naming.InitialContext.getDefaultInitCtx( InitialContext.java:247 )
at javax.naming.InitialContext.init ( InitialContext.java:223 )
at javax.naming.InitialContext.<init>( InitialContext.java:197 )
at javax.naming.directory.InitialDirContext.<init>( InitialDirContext.java:82 )
at com.borland.sdop.registry.server.RegistryServer.initialDirContext ( RegistryServer.java:158 )
at com.borland.sdop.registry.server.RegistryServer.setupRegistryEngine( RegistryServer.java:169 )
at com.borland.sdop.registry.server.RegistryServer.run( RegistryServer.java:51 )
at com.borland.sdop.registry.server.RegistryProcess.main ( RegistryProcess.java:50 )
This is being emitted from the ApacehDS classes, prior to loading them all log4J messages were emitted correctly to the log.
Now, I understand you're picking up our log4J in the classpath – but – if I then move the ApacheDS jars ahead of mine in the classpath I get:
Exception in thread "main" java.lang.NoSuchMethodError: org.apache.log4j.Logger.debug(Ljava/lang/Object;)V
at blah.blah.RegistryProcess.installShutdownHandler( RegistryProcess.java:146 )
at blah.blah.RegistryProcess.main( RegistryProcess.java:39 )
it appears to me that the method "debug" that handles an array of objects is missing from the logger implementation bundled with ApacheDS.
Is there anywhere in the ApacheDS documentation that describes how to configure ApacheDS to co-exist with 'normal' log4J – to change our application over to a non-standard log4J would be a non-trivial undertaking at this point.
-Thom
From: Trustin Lee [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 28, 2005 5:32 PM
To: Apache Directory Developers List
Subject: Re: Problem embedding 0.92 ApacheDS...
Hi Thom,
2005/9/29, Thom Park < [EMAIL PROTECTED]>:
I've followed the instructions in the doc for embedding ApacheDS in my java application but, what worked fine with 0.9 no longer works with 0.92!
Can someone tell me what's changed with the procedure to embed ApacheDS 0.92 within a java app and put me right please?
The way to configure ApacheDS has been change significantly from 0.9.2. There's no documentation about it, but please take a look at apacheds-main to find out how to configure ApacheDS. It is using Spring framework, but you can configure it plain Java code, too.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
