Ceki -
This may help to outline the issue that developers may experience with
the recent log4j changes if libraries are built using different versions
of lo4j libraries.
Tom's suggestion of building axis.jar and the Axis client with the same
log4j file solves the runtime exception. Thanks for the tip Tom.
The exception appears when Axis client code is build using a lo4j.jar
file that is different than the one used to build the Axis.jar file. It
doesn't matter if only a single lo4j jarfile is available at runtime.
Is the exception (when different log4 versions are defined at build
time) due to the static declaration of the Category property? Does the
JDK1.3 java compiler optimize the declaration so that there is a
run-time library dependency? It is my understanding that the dependency
of Category changes between the versions even though the outward
getInstance() signature used in the Axis codebase remains constant.
The interop issue is when libraries (for example, Axis.jar and
MyWebServiceClient.jar) are layered (MyWebService code calls Axis code),
both use log4j, and have been built using different versions of log4j.
In this use case, there is no backward compatibility.
=====
The gory details:
The exception arises when axis.jar is built against log4j-core.jar (the
distribution version) and then used in conjunction with an Axis client
built against log4j-1.2alpha7.jar. For some reason, when the client
calls the Axis layer, there is an initialization exception if the
distribution jar for log4j is log4j-1.2alpha7.jar and not log4j-core.
Here's the exception thrown:
Exception in thread "main" java.lang.NoSuchMethodError
at org.apache.axis.handlers.BasicHandler.<clinit>(Unknown
Source)
at org.apache.axis.client.Service.getAxisClient(Unknown Source)
at org.apache.axis.client.Service.<init>(Unknown Source)
To recap, if one compiles the main branch of xml-axis (using log4j-core)
to obtain axis.jar, builds an Axis client (using log4j-1.2alpha7.jar)
and runs the client with a classpath of axis.jar:log4j-1.2alpha7.jar, a
runtime exception will be thrown when BasicHandler is instantiated.
The offending line might be:
static Category category =
Category.getInstance(BasicHandler.class.getName());
This exception does not occur if the identical log4j jarfile is used for
both the Axis and client build.
Thanks for your help,
/Chris
-----Original Message-----
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 08, 2002 1:01 PM
To: Log4J Developers List; '[EMAIL PROTECTED]'
Cc: '[EMAIL PROTECTED]'
Subject: RE: Interop with Log4j
Hi Tom,
Nothing that would affect backward compatibility was added or removed in
the
recent past. So I can't think of anything. Could you provide more detail
about the problem
please? Thank you, Ceki
At 11:36 08.02.2002 -0500, Tom Jordahl wrote:
>Tom Jordahl wrote:
> > The latest log4j from CVS has made a incompatible change from the
previous
> > release version.
>
>Sam Ruby wrote:
> > Have you communicated this to the log4j development team? Such
changes
> > would eventually impact Axis users... I can tell you that the log4j
team
> > takes backwards compatibility very seriously and agressively address
any
> > issues brought to their attention.
>
>I have not in fact communicated with the log4j team. Hi guys!
>
>Here is what I know: If you try to use the nightly build axis.jar with
>the log4j.jar checked in to our CVS tree, it will fail due to a missing
>log4j class. I apologize for not having the class name handy.
>
>--
>Tom Jordahl
>Macromedia
>
>--
>To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
Ceki Gülcü
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
