Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Message-Id: <6.0.3.0.0.20051011123854.0332ee70@torino>
Date: Tue, 11 Oct 2005 13:38:59 +0200
To: "Apache Directory Developers List" <dev@directory.apache.org>
From: Ceki =?iso-8859-1?Q?G=FClc=FC?= <listid@qos.ch>
Subject: Re: upgrading to nlog4j.1.2.17
In-Reply-To: <733AB419-0247-4FBD-B9F1-4D63F27D98C7@gmail.com>
References: <43262BF5.3010704@atlassian.com>
 <6.0.3.0.0.20050913094005.0327ebd0@torino>
 <43269428.1070800@atlassian.com>
 <6.0.3.0.0.20050913141127.0394a7f8@torino>
 <43279B80.6050102@atlassian.com>
 <6.0.3.0.0.20051005154438.03b41308@torino>
 <4344A731.6030200@atlassian.com>
 <6.0.3.0.0.20051010100332.03b8ce70@torino>
 <6B4C9AA3-738C-4FB6-A7C9-58EC970C92B5@atlassian.com>
 <6.0.3.0.0.20051010163659.033ac728@torino>
 <733AB419-0247-4FBD-B9F1-4D63F27D98C7@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi Nick,

At 12:31 AM 10/11/2005, Nick Faiz wrote:
>Hi Ceki,
>
>Are you sure that this conflict is unavoidable? It would be great if
>all of the methods present in the original log4j Logger could be
>represented in the nlog4j implementation (down to identical method
>arguments). It was my understanding that we were seeing this issue
>because some of the arguments had changed in nlog4j.

First, I think asking whether the conflict is unavoidable is exactly
the right questions to ask. So thank you for raising the question.
Unfortunately, I am unable to give a definitive answer. My kneejerk
reaction would be to say, it is unavoidable because I tend to believe
that in case multiple copies of xlog4j.jar lie on the class path the
conflicts are bound to arise independent of the changes between log4j
method signatures and nlog4j method signatures.

Let me give you an example. Assume log4j.jar and nlog4j.jar are both
on the class path. Further assume that somehow classes found in
log4j.jar are seen before those found in nlog4j.jar. For instance,
assume that the copy org.apache.log4j.Logger class found in log4j.jar
is found before the copy of o.a.l.Logger class found in nlog4j.jar.

In the current implementation of SLF4J which ships with nlog4j.jar,
the org.slf4j.LoggerFactory class is set to use the
org.apache.log4j.Logger class at compile time. However, the actual
loading of the org.apache.log4j.Loggger is made at runtime by the
JVM. If the copy of the o.a.l.Logger class found in log4j.jar has
precedence, then the Logger instances returned by
org.slf4j.LoggerFactory would be of the wrong type (without SLF4J
support) independently of the signature changes in nlog4j.

Returning to the problem reported by Thom, what does the stack trace
say?

  Date: Thu, 29 Sep 2005 12:13:44 -0700
  Subject:: Problem embedding 0.92 ApacheDS...
  From: "Thom Park" <Thom.Park@borland.com>

Exception in thread "main" java.lang.IncompatibleClassChangeError
at=20
org.apache.ldap.server.jndi.ServerContextFactory.startLdapProtocol(ServerCon=
textFactory.java:222)
at=20
org.apache.ldap.server.jndi.ServerContextFactory.afterStartup(ServerContextF=
actory.java:108)
at=20
org.apache.ldap.server.jndi.DefaultContextFactoryService.startup(DefaultCont=
extFactoryService.java:204)
at=20
org.apache.ldap.server.jndi.AbstractContextFactory.getInitialContext(Abstrac=
tContextFactory.java:99)


The failure occurs on line 222 of the
o.a.l.s.jndi.ServerContextFactory class class [1].  I would have
thought that problem would arise much sooner, for example when the
Logger instance was retrieved on line 62. Why doesn't line 62 throw a
ClassCastException since org.apache.log4j.Logger in log4j 1.2 does
not implement the org.slf4j.Logger interface?

Perhaps Thom is using log4j 1.3 as found in log4j CVS which indeed
implements the org.slf4j.Logger interface.

Another more plausible explanation, is that ApacheDS2 was compiled
against one version of nlog4j.jar and somehow Thom has another version
of nlog4j.jar on the classpath. Otherwise, it is not possible to
fail on line 222 but not on 62. Does anyone has a better explanation?

Thus, it seems to me that in Thom's case, the problem is not a
log4j/nlog4j incompatibility but an nlog4j/nlog4j
incompatibility. :-) However, without further information from Thom, it's
all conjecturing on my part..

[1-tiny] http://tinyurl.com/9pmlh
[1-original]=20
http://svn.apache.org/viewcvs.cgi/*checkout*/directory/apacheds/tags/release=
-0.9.2/main/src/main/java/org/apache/ldap/server/jndi/ServerContextFactory.j=
ava?rev=3D264732&content-type=3Dtext%2Fplain

>I think slf4j loses quite a bit of 'adoptability' by not being able
>to function alongside log4j.

I suggest that the problem be identified clearly before reaching a
definitive conclusion. Otherwise, I agree with the rest of your
comments.

>Cheers,
>Nick

--=20
Ceki G=FClc=FC

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