The manifest.mf doesn't seem to be important. My application finds and uses
the jars contained in the WEB-INF/lib directory, no matter if I put the
classpath information into the manifest.mf or not, but this doesn't solve
the problem.
Any other idea?
Markus
"Tom Marsh"
<marsht1@nitesco. To: "Log4J Users List"
<[EMAIL PROTECTED]>,
com> [EMAIL PROTECTED]
cc:
04.09.2002 10:55 Subject: Re: Problems with
Xalan/Xerces using Log4J 1.2.3 with WebSphere 4.01
Please respond to
"Log4J Users
List"
Marcus:
We're also doing something very similar. We have log4j.jar in our .ear
file, along with xalan.jar and xerces.jar. The manifest.mf file
contains a classpath entry for the jars.
Tom
> Hi,
>
> I've developed a servlet-based application that is running on
WebSphere
> 4.01 (on AIX) and is doing some XSL-transformations on XML-files using
> Xalan and Xerces. Since I switched logging to Log4J we experience some
> strange problems concerning the XSL-scripts, i.e. scripts that were
working
> fine before (except for some warnings because of variables being used
> without prior declaration) now produce fatal errors.
>
> Of course it's easy to just fix the scripts (i.e. declare the
variables)
> and we'll certainly do this, but what really concerns me is, that
there
> seems to be a dependency between Log4J and Xalan/Xerces. However I
don't
> have any clue why, because all relevant classes seem to be in
different
> packages and therefor shouldn't interfere.
>
> The problem appears with different versions of Xalan and Xerces,
though
> primarily we use Xalan 2.0.0 and Xerces 1.2.1 (the versions that are
> contained in WebSphere 4.01). I put the log4j.jar (version 1.2.3) in
the
> WebSphere's "lib/app" directory and tried with and without putting
Xalan
> and Xerces into the "WEB-INF/lib" directory of my application
(because I
> thought it might be depending on the order in which the classes are
loaded
> and classes in "WEB-INF/lib" should be loaded before those
in "lib/app" and
> these again before those in "lib", where the Xalan and Xerces
WebSphere is
> using reside), but it doesn't make any difference.
>
> Does anybody have any idea what might be the reason for this problem
and
> how I can solve this without switching back to my own logging classes
(as I
> already mentioned above, just fixing the scripts is not enought,
because we
> cannot tolerate a dependency between Log4J and Xalan/Xerces)?
>
> I suppose that somehow the Xalan/Xerces classes get access to some of
the
> Log4J XML/XSL-related classes. These classes are newer than the
classes
> contained in the Xalan/Xerces versions that we're using and therefor
more
> strict, which is why they not only warn when a variable in the XSL is
used
> without prior declaration but throw an exception and stop further
> processing. But I don't have any idea why this happens and how I can
avoid
> this.
>
> Any help is greatly appreciated.
>
> Regards,
> Markus.
>
>
>
> --
> To unsubscribe, e-mail: <mailto:log4j-user-
[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:log4j-user-
[EMAIL PROTECTED]>
>
>
--
NeoMail - Webmail that doesn't suck... as much.
http://neomail.sourceforge.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]
>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
