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

[ Post a follow-up to this message ]

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=20
nlog4j.jar. However, the inverse is not true. Code compiled with NLOG4J=20
will only run with NLOG4J. This means that your code, when compiled with=20
NLOG4J, will depend on NLOG4J, which in my humble opinion is a rather=20
reasonable requirement, especially if you consider that NLOG4J has SLF4J=20
support which log4j does not have.

Considering the direction of compatibility, perhaps you are trying to=20
access methods only available in nlog4j when only log4j.jar is available in=
=20
the class path?

Being somewhat familiar with IDEA, I'd be happy to try reproduce the=20
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:
>Hey Alex (and others),
>
>I was originally sending this to Alex, as a follow up to an interrupted IM=
=20
>chat, but thought it relevant to send to the dev list. It relates to=20
>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=20
>in IDEA but havent had time to test with ApacheDS in any other embedded=20
>capacity. It's a blocker.
>
>Whenever I hit an nlog4j log statement in IDEA, when I have several=20
>modules open, and when my own source code uses log4j but one of the=20
>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/
>--

--=20
Ceki G=FClc=FC

The complete log4j manual: http://www.qos.ch/log4j/

[ Post a follow-up to this message ]

Hi Ceki,

This is a hard one to replicate - the environment is complex. My current
environment has four IDEA project modules, each with log4j dependencies.
One of these modules lists ApacheDS as a dependency. The jar for
ApacheDS is holding an unpacked slf4j and log4j distro, (see attached
screenshot).

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:

java.lang.NoSuchMethodError:
org.apache.log4j.Logger.info(Ljava/lang/String;)V

The stacktrace is simply related to the chain of execution in the
current thread (here a TCP Connection, because Im making a HTTP
Request). It doesn't look helpful in this regard but I can send it to
you if you would like to see it. It simply seems that the JVM is trying
to execute a method which doesn't exist.

If I run IDEA with module4 alone, with the log4j dependency and an
ApacheDS dependency (which includes nlog4j, the same screenshot
applies), logging works.

Your basic provision that code compiled against log4j will work with
nlog4j should satisfy our needs, and I agree that it doesn't need to be
bi-directional.

Let me know if you need further information. Good luck!

Cheers,
Nick


Ceki Gülcü wrote:
>
> 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:
> 
>
>


--
ATLASSIAN - http://www.atlassian.com/

Confluence - the enterprise wiki - tried it yet?
http://www.atlassian.com/confluence/
--

[ Post a follow-up to this message ]

Hi Nick,

Thanks for the detailed description.

At 10:56 AM 9/13/2005, Nick Faiz wrote:
>Hi Ceki,
>
>This is a hard one to replicate - the environment is complex. My current=20
>environment has four IDEA project modules, each with log4j dependencies.=20
>One of these modules lists ApacheDS as a dependency. The jar for ApacheDS=
=20
>is holding an unpacked slf4j and log4j distro, (see attached screenshot).

What's in the slf4j distro? Is nlog4j.jar included?

>When I run a main method in module1 (which doesn't use ApacheDS) all log=20
>statements in modules 1, 2 and 3 work quite well. When it finally reaches=
=20
>a logging statement in module4, which *does* use ApacheDS, I see a=20
>NoSuchMethodError:
>
>java.lang.NoSuchMethodError:=
org.apache.log4j.Logger.info(Ljava/lang/String;)V

Is ApacheDS compiled against nlog4j? If so, could you try replacing log4j=20
with nlog4j and give it a whirl?

>The stacktrace is simply related to the chain of execution in the current=
=20
>thread (here a TCP Connection, because Im making a HTTP Request). It=20
>doesn't look helpful in this regard but I can send it to you if you would=
=20
>like to see it. It simply seems that the JVM is trying to execute a method=
=20
>which doesn't exist.

Roger that.

>If I run IDEA with module4 alone, with the log4j dependency and an=20
>ApacheDS dependency (which includes nlog4j, the same screenshot applies),=
=20
>logging works.

My guess (needs to be verified) is that when module 4 and ApacheDS are=20
used, classes in nlog4j.jar are used, however with modules 1, 2 and 3,=20
classes in log4j.jar are seen first (since they are "local" or in the=20
closest scope). I'd have to verify this hypothesis. Will report back later.

>Nick

--=20
Ceki G=FClc=FC

The complete log4j manual: http://www.qos.ch/log4j/

[ Post a follow-up to this message ]

Hey Ceki,

Ceki Gülcü wrote: 
>
> What's in the slf4j distro? Is nlog4j.jar included?
>

It's nlog4j.1.2.14

>
> Is ApacheDS compiled against nlog4j? If so, could you try replacing
> log4j with nlog4j and give it a whirl?
>

Yes, I have compiled ApacheDS against nlog4 (version above). The log4j
dependencies are not present in ApacheDS. There doesn't seem like much
point in replacing log4j with nlog4j in the other modules, as the other
modules *must* stay with log4j. I know that you probably we're
suggesting this sort of replacement ...

>
> My guess (needs to be verified) is that when module 4 and ApacheDS are
> used, classes in nlog4j.jar are used, however with modules 1, 2 and 3,
> classes in log4j.jar are seen first (since they are "local" or in the
> closest scope). I'd have to verify this hypothesis. Will report back later
.
>

Yes, I have thought something along those lines also. If it's simply an
IDE related bug it might not be so serious but it still is a major
obstacle - it effectively means that each logging statement in module4
has to be commented out when working in an IDEA.

Thanks for your fast response to this.

Cheers,
Nick

--
ATLASSIAN - http://www.atlassian.com/

Confluence - the enterprise wiki - tried it yet?
http://www.atlassian.com/confluence/
--

[ Post a follow-up to this message ]

Nick Faiz wrote:

> modules *must* stay with log4j. I know that you probably we're
> suggesting this sort of replacement ...

err ... s/we're/weren't 

Nick

--
ATLASSIAN - http://www.atlassian.com/

Confluence - the enterprise wiki - tried it yet?
http://www.atlassian.com/confluence/
--

[ Post a follow-up to this message ]

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?


--=20
Ceki G=FClc=FC

The complete log4j manual: http://www.qos.ch/log4j/

[ Post a follow-up to this message ]

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:
> 
>
> 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?
>
>

[ Post a follow-up to this message ]

At 06:25 AM 10/6/2005, Nick Faiz wrote:
>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=20
>time and will have to follow your suggestions later on. I wanted to reply=
=20
>to let you know that I had seen your response, though.
>
>I'm a little concerned over another log4j/slf4j conflict which a user=20
>reported when trying to embed ApacheDS into a log4j dependent application=
=20
>(see attachment). I'm going to put together a test project of some kind=20
>which uses log4j and embeds ApacheDS to verify the existence of the=20
>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=
=20
>applications, using log4j, continue to work when they use a library which=
=20
>uses slf4j?

Hello Nick,

We have a test case, called Compatibility, (please refer to [1]) which
verifies that code compiled with log4j runs when NLOG4J is on the
class path. Methods known to suffer from compatibility re exercised by
this test. In case there was any doubt, code compiled against
log4j.jar runs fine when log4j.jar is replaces with nlog4j.jar on the
class path.

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.

NLOG4J should be considered as a new version of log4j. Code compiled
with the "old" version, e.g. log4j, will run fine with both the old
and the new version. However, code compiled with the new version,
i.e. NLOG4J, requires the new version and will not run with log4j, the
"old" version.

To summarize, nlog4j.jar can replace log4j.jar but the inverse does
not hold true.

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.

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.

Nick, would you concur with the above assessment?

[1] 
>Cheers,
>Nick

--=20
Ceki G=FClc=FC

The complete log4j manual: [url]http://www.qos.ch/log4j/" target="_blank">http://svn.slf4j.org/viewcvs/nlog4j...w.qos.ch/log4j/

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]