xerces 2.0.1

[Ashok Patil]

Hi All,
Our Developemnt has upgarded the xml parser to xcerces2.0.1 . The
basic change is the xcerces.jar is relpaced by two jar files.
xercesImpl.jar and xmlParserAPIs.jar , We have properly updated teh
classpath to reflect this.
When I try to start the ApplicationServer. I get the following error
thrown in WebSphere's Application Servers Error log file

java.lang.reflect.InvocationTargetException: java.lang.VerifyError:
(class: com/ibm/etools/emf/plugin/LoadPlugin, method: parse signature:
(Ljava/lang/String;)Lorg/w3c/dom/Document;) Incompatible object argument
for method call
at java.lang.Class.forName1(Native Method)
at java.lang.Class.forName(Class.java:134)
at com.ibm.etools.emf.init.impl.InitImpl.defaultInit(InitImpl.java:64)
at com.ibm.etools.emf.init.impl.InitImpl.init(InitImpl.java:85)
at com.ibm.etools.emf.init.Init.init(Init.java:22)
at
com.ibm.ejs.models.base.resources.init.ResourcesInit.init(ResourcesInit.java:30)

at
com.ibm.ejs.models.base.config.init.ConfigInit.init(ConfigInit.java:47)
at com.ibm.ws.runtime.Server.initializeWCCM(Server.java:206)
at
com.ibm.ejs.sm.server.ManagedServer.initializeWCCM(ManagedServer.java:561)

at com.ibm.ws.runtime.Server.<init>(Server.java:171)
at com.ibm.ejs.sm.server.ManagedServer.<init>(ManagedServer.java:280)
at com.ibm.ejs.sm.server.ManagedServer.main(ManagedServer.java:163)
at java.lang.reflect.Method.invoke(Native Method)
at com.ibm.ws.bootstrap.WSLauncher.main(WSLauncher.java:158)

If we look at the above trace, it looks like mismatch between method
signatures of XMLParser.

Observation: In <WASHOME>/lib . I found xerces.jar .

Question: Do we have separate upgrade procedure for WebSphere to use
xcerces2.0.1 or do we have any fix for this.

Thanks in advance
Ashok

[Ashok Patil]

Hi All,
Forgot to mention about App Server. I am using 4.0.1 with Fixpack 2 and eFix
56068, 57910

Thanks
Ashok

[David Artus]

Which class path have you updated?

What do you mean by properly?
"We have properly updated the classpath to reflect this."

You must not update the admin server classpath to use
different xerxes jars. Instead put the new version in
$WASROOT/lib/app this will make it visible to your
application but not to the admin server.

[Ashok Patil]

we use perl to execute wscp class and start the admin server using wscp and then use
perl to start the application server, using wscp class. I use AdditionalCmdLine Args
parameter to set my classpath , system properties for the ApplicationServer JVM. It is
this ApplicationServer's JVM classpath I am talking about.
Yes I don;t update admin server classpath. The adminserver comes up fine. the
xercesImpl.jar and xmlParserAPIs.jar are place in folder( /acs/lib/apache ) which is
included as classpath, for the applicationserver JVM.

Experiment 1 ) I placed the xerces.jar from <WASHOME>/lib folder in my custom folder
/acs/lib/apache , the applicationserver came up fine. Looks like WebSphere is trying to
use these 2 jar files when it's trying to parse plugin config file. But I can't use
xerces.jar, because then my application will fail since it's upgraded to use xerces2.0.1

Thanks
Ashok

[David Artus]

Put the xerxers jar you want to use in $WASROOT/lib/app,
I believe that other folks have found that this gives the effect
you need.

[Ashok Patil]

here is what we did.

our classpath of Application Server JVM is updated to use xerces2.0.1 . Then I copied
xerces.jar ( from <WASHOME>/lib to <WASHOME>/java/jre/lib/ext ) , this jre/lib/ext acts as
automatic classpath for WebSphere's AppServer JVM.
The Application Server came up fine. Now the Question is during runtime, Will JVM pickup
the XML Parser class from /acs/lib/apache ( this is my folder which has xmlParserAPIs.jar and
xercesImpl.jar ) or will it pick from <WASHOME>/java/jre/lib/ext folder.?

[David Artus]

As soon as you adjust jars in the WebSphere installation
directories you are leaving know territory. I don't
know the classloader precedences well enough to be
able to answer your questions.

I strongly suggest:

1). Put everything back as it was.
2). Do not adjust the JVM classpath
3). Place you required version of xerxes in lib/app it
will be used by your applicationwithout explicit specification
on any classpath.

Nothing more should be needed.

[Ashok Patil]

OK here is what i tried

removed xerces.jar from <WASHOME>/java/jre/lib/ext.

moved my xerces2.0.1 jar files from my custom folder (/acs/lib/apache) ( xercesImpl.jar and
xmlParserAPIs.jar ) to <WASHOME>/lib/app folder .
modified the AppServer classpath so that they don't refer to /acs/lib/apache/xercesImpl.jar and
/acs/lib/apache/xmlParserAPIs.jar entries.

The ApplicationServer comes up fine, but my application fails , reporting NoClassDefnFound
Exception for class
org/apache/xerces/fraemwork/XMLParser

Cheers,
Ashok

[David Artus]

Hmm, that is surprising. [And pretty annoying for you too,
I imagine.]

Your entire application is in an EAR (or WAR or whatever?)
The class wanting to use the

org/apache/xerces/framework/XMLParser

is in the application, not loaded from somewhere else?

There's no doubt that the XML parser class is in one
of those jars you put in lib/app? You did put them
directly into the $WASROOT/lib/app directory?

This really is not what I'm used to seeing. I believed
that the use of lib/app "just worked" for folks trying
to do what you're doing.

Do you have any jvm classpath entries left? could
any of those contain your application code?

[Ashok Patil]

OK the summary is

my <WASHOME>/java/jre/lib/ext is empty, which is by default.
my <WASHOME>/lib/app is empty , which is by default.

Brief idea about how I start the application and admin server.

Based on perl scripts we have here, the scripts always starts adminserver first and then Application
Server. To restart Application Server I execute script to stop my application which shutsdown
applicationServer and also adminserver.Then I execute the script to start my application which starts
adminserver and then applicationserver.
When I start applicationserver, the load on startup servlet starts acs application

Now if I place xerces2.0.1( xercesImpl.jar and xmlParserAPIs.jar ) in classpath of ApplicationServer,
The WebSphere Application Server fails to start, so my application never comes up.
Now I place old xerces.jar in classpath of ApplicationServer, The WebSphere Application Server starts,
also my application comes up.

MY requirement is I need to use xerces2.0.1 inside my application . WebSphere classes when it's
starting Application Server, should use xerces.jar from <WASHOME>/lib and not xerces2.0.1 which is
present as part of my classpath I speficy for the Application Server. How do we go about this.

If I want to make use of <WASHOME>/lib/app then I removed the entries of xercesImpl.jar and
xmlParserAPIs.jar from my ApplicationServer classpath and place these jar files in <WASHOME>/lib/app ,
The Application Server starts up but not my application, the servlet fails to Initialize throwing
org/apache/xerces/framework/XMLParser ClassDefnNotFound Exception, this class is part of
xercesImpl.jar file.

How should we go about this problem.

If you need prototype.

you need to have application which will use xerces2.0.1 and try to start that application using load on
startup servlet. If the application Server starts and also the application executes the parsing of XMl
file using xerces2.0.1 API's then we are done.

Note: F.Y.I The script is perl , which executes WSLaucnher and passes required System properties ,
class to load ( eg AdminServer , wscpshell ) , parameters ( eg if wscpshell then we setup classpath,
system properties, etc as part of AdditionalCmdLineArgs variable )

[David Artus]

I understand what you want to do, and what you
want to do is reasonable.

My question is:

Where is that startup servlet class being loaded from?
Is in in an EAR file deployed in the conventional way?

lib/app is (to the best of my knowlegde) visible to all
application code loaded from an EAR. The WAS
classloader hierarchy would prevent classes loaded
on the JVM classpath from seeing classes in lib/app,
so we need to know by which class loader the classes
trying to use Xerxes are being loaded.

[Ashok Patil]

YES,the servlet class is patr of .war, which is packed into .ear and then installed. upon installation. I
see the servlet class in <washome>/installedApps/<entapp>.ear/<webapp>.war/WEB-INF/classes folder. Also this
class is present as packaged jar file entry in classpath . This should not be problem. Even if I delete the
class from web-inf/classes folder, the Application still comes up picking the class from jar file.

The only problem is of xerces version upgraded to 2.0.1 in my application.

Does Visibility have any effect, what if I keep it at Module level?.

Ashok

[David Artus]

What do you mean by this?

"Also this class is present as packaged jar file entry in classpath .
This should not be problem. Even if I delete the class from
web-inf/classes folder, the Application still comes up picking the class
from jar file."

Perhaps I misunderstand what you are saying. If I *do* understand
then you are doing precisely what I am warning you will *not*
work.

Where is the jar file? Is is on the JVM class path?

If it is then you are using the JVM class loader to load your servlet.
Your servlet cannot then use lib/app. All your application classes
should be loaded from the installed verision of the EAR *only*.
Do not put any of your classes on the JVM classpath (at
least until we sort out this xerxes issue.)

Your servlet should load from the web-inf/classes folder
without any other classpath entry. If your servlet uses Xerxes
directly then that should be it. If your serlvet uses some intermediate
class that in turn uses Xerxes then that intermediate class
should also be in your EAR.

[Ashok Patil]

YES all the jars that are used by the servlet and it;s utility classes are in JVM classpath . I think now I got
what you said earlier.
Now will just placing these jars in web-inf/lib and removing them from JVM classpath entry will work?. OR
should I repack the .war and .ear ?.

I may not reply for further mails, since I will be back on May 6th .

[David Artus]

OK now we know why lib/app wasn't working for you.

It is usally possible to structure the application so that everything
is served up from the EAR. This is key to the use of lib/app. As
a first cut that is the way to get things going.

If you have only servlets and no EJBs then putting the jars
into web-inf/lib should work for you. I would always
recommend working from a properly package WAR and
EAR, and not tweaking installedApps

[Ashok Patil]

just to close the loop,
summary, now my application uses xerces2.0.1 and websphere uses original xerces from WASROOT/lib folder , when we
start Application server.

we packed all dependent jars while creating war file. Then created .ear file. removed -classpath from the cmd line
used to start ApplicationServer.

There was dependency between log4j jar file also, so moved this one also to <WASROOT>/lib/app, along with xerces2.0.1
jar files.

Thanks David for providing all the timely help.