Re: upgrading to nlog4j.1.2.17

[Nick Faiz]

Hi Ceki,

Thanks for the response. Were you able to replicate the error yourself?
I'll have to test on IDEA 5.0. Unfortunately, I am currently pushed for 
time and will have to follow your suggestions later on. I wanted to 
reply to let you know that I had seen your response, though.

I'm a little concerned over another log4j/slf4j conflict which a user 
reported when trying to embed ApacheDS into a log4j dependent 
application (see attachment). I'm going to put together a test project 
of some kind which uses log4j and embeds ApacheDS to verify the 
existence of the problem. I'll keep you updated about what I found out 
on this front.

What kind of testing strategies have you followed to ensure that 
existing applications, using log4j, continue to work when they use a 
library which uses slf4j?

Cheers,
Nick

Ceki Gülcü wrote:


Hello Nick,

Are you aware of IDEA's (version 5.0) ability to export jar files from
a module (IDEA->Settings->Modules->Order/Export)? For example, if
module X depends on jar file a.jar, it can export a.jar so that module
Y which depends on X can also access a.jar.

Thus, my first suggestion would be to remove the expanded (or
exploded) versions of nlog4j and slf4j from ApacheDS module. When
that's done, try exporting/not exporting nlog4j from the ApacheDS
module.

At 05:39 AM 9/14/2005, Nick Faiz wrote:

> When I run a main method in module1 (which doesn't use ApacheDS) all
> log statements in modules 1, 2 and 3 work quite well. When it finally
> reaches a logging statement in module4, which *does* use ApacheDS, I
> see a NoSuchMethodError:

I could not find documentation about what IDEA does when multiple
modules declare the same dependency.  However, given the above, and
given that module4 which depends on ApacheDS, assuming if ApacheDS
exported nlog4j, module4 would no longer need to declare log4j as a
dependency. One could then speculate that the NoSuchMethodError would
no longer occur.

Does that make sense? Even better, does it work?



--- Begin Message ---








Hi Nick,

 

Sorry – I apologize for not getting
feedback to you – I got a bit lost in the weeds with the problems we were
having with schema parsing.

 

 Unfortunately,  we still have the same
issue of  an incompatability between log4J and slf4j.

We rolled our release back to ApacheDS 0.9
for now, such that we were able to progress further but obviously, we’ll need
to solve this problem to continue using the newer versions of ApacheDS.

 

-Thom

 

 









From: Nick Faiz
[mailto:[EMAIL PROTECTED] 
Sent: Thursday, September 29, 2005
9:43 PM
To: Apache
 Directory Developers List
Subject: Re: Problem embedding
0.92 ApacheDS...



 

Thom,

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



On 9/30/05, Nick
Faiz <[EMAIL PROTECTED]>
wrote:

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,





Nick







 





On 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/











 







 






--- End Message ---