java.lang.VerifyError

[sbirnie]

I'm getting the following error:

org.springframework.beans.factory.BeanCreationExce ption: Error creating bean with name 'marshaller': Invocation of init method failed; nested exception is java.lang.VerifyError

I'm using this for defining the marshaller:
<oxm:jaxb2-marshaller id="marshaller" contextPath="com.xxxx.webService.schema" />

I'm running on Websphere 6.1 with Java 1.5. Anyone seen this before or know what the problem might be?

[miluch]

I have spent a few hours to run SWS on websphere 6.1.0.13.
During these long hours i have seen VerifyError, ClassCastException, NoClassDefFound and other strange errors.
But finally have found a solution and now i am using SWS with PayloadRootAnnotationMethodEndpointMapping and JAXB 2.

The basic steps you need to follow are in FAQ:classloader tricks.

If you still have problems send more details about your application:
is it WAR or EAR, version of Websphere, version of SWS.

[sbirnie]

It's an ear file. I'm currently using SimpleMethodEndpointMapping.

Websphere classloader FAQ?

I appreciate any info you have. I've been messing around with this for about a week now. The application works like a champ on Glassfish, which is what we used to test on our local machines. Websphere is our production environment - I just love Websphere.

[sbirnie]

One few more things. I'm building the war and ear with Maven. I've gone through and excluded all references to xerces and xalan so that it will pick up Websphere's version.

I'm also building the schema directory using a maven plugin that reads the XSD. I don't know which one is the most popular out there, but right now I'm using:

groupId=com.sun.tools.xjc.maven2
artifactId=maven-jaxb-plugin

If that's old or there's a better one out there I'd love to know.

[miluch]

One few more things. I'm building the war and ear with Maven. I've gone through and excluded all references to xerces and xalan so that it will pick up Websphere's version.

I'm also building the schema directory using a maven plugin that reads the XSD. I don't know which one is the most popular out there, but right now I'm using:

groupId=com.sun.tools.xjc.maven2
artifactId=maven-jaxb-plugin

If that's old or there's a better one out there I'd love to know.

I do not use maven and i can not provide you any maven dependencies.

To generate java from XSD i use ant jaxb task.

But straight to the point:

My application is a single ear that conatins EJB jar and 2 wars. Only one of the wars utilizes SWS.
Spring Framework jars (not SWS) are located directly under ear and are referenced from wars by Class-Path entries in Manifest.mf files.

If you do pack your application differently the steps i provide below should work but i have not tested them in a different configuration

Inside WEB-INF/lib of SWS war i have:

activation-1.1.1.jar jaxb-api-2.1.jar jaxb-impl-2.1.5.jar spring-oxm-1.5.2.jar spring-oxm-tiger-1.5.2.jar spring-webmvc.jar spring-ws-core-1.5.2.jar spring-ws-core-tiger-1.5.2.jar spring-ws-support-1.5.2.jar spring-xml-1.5.2.jar stax-api-1.0.1.jar XmlSchema-1.3.2.jar

I am not sure if all these jars are necessary in 100 %. But asfaik i copied them from lib folder of SWS 1.5.2.

Next step is to override some websphere jars.
You can do it in a multiple ways:
Setting ParentLast classloading policy on War,
Setting ParentLast classloading policy on EAR,
Create custom classloader.

I have decided to use the latter solution, cause i do not have a good experience with Parent - last policy.
You can read on a forum that some of the folks were successful with Parent-last policy, so it is up to you.

Steps to define custom classloader you can find in a Webphere reference - it is about defining shared library, creating new classloader and point it to the library.

The most important are:
1)set this classloader to parent last(application first)
2)define correct jars in this library

I have defined the following jars:

wsdl4j-1.6.1.jar
xalan-2.7.0.jar 
xercesImpl-2.8.1.jar

All these jars are again copied from SWS 1.5.2 lib folder.

In the beginning i also had xml-apis-1.3.04.jar but encountered some problems:application worked correctly but during first invocation of webservice ClassCastExceptions was logged and SWS failed to discover SAAJ 1.2 runtime and failed to SAAJ 1.1

After i removed xml-apis from my custom classloader shared library everything started working as a charm.

I have also spent some time trying to create SAAJ 1.3 runtime (websphere implements only SAAJ 1.2) but reference implementation i downloaded from java.net uses classes from com.sun.org.apache.xerces or sth like that are bundled in JRE but SUN JRE not IBM JRE.

Since i do not need SAAJ 1.3 up to now, i haven't tried to drill the issue further.

I hope it helps.

[adeveloper]

I am also getting ClassCastException error if I include xml-apis-1.3.04.jar in the lib dir of the war file in Parent Last classloader setting. I am using Websphere 6.0. Can anybody confirm whether it is alright to remove xml-apis-1.3.04.jar from the lib directory. I do not get any error if xml-apis-1.3.04.jar is removed from the lib directory. Or is it better to put xml-apis-1.3.04.jar in the endorsed directory?

Error:

[15/07/08 14:58:38:009 EST] 00000013 XMLUtils      E   TRAS0014I: The following exception was logged java.lang.ClassCastException: org/apache/xerces/jaxp/DocumentBuilderFactoryImpl incompatible with javax/xml/parsers/DocumentBuilderFactory

[ekozynin]

Spring Framework jars (not SWS) are located directly under ear and are referenced from wars by Class-Path entries in Manifest.mf files.

Just wanted to stress this important bit - don't forget Class-Path entries in manifest.mf!

[miluch]

Spring Framework jars (not SWS) are located directly under ear and are referenced from wars by Class-Path entries in Manifest.mf files.

Just wanted to stress this important bit - don't forget Class-Path entries in manifest.mf!

I thought it is quite obvious.
On websphere to access jars placed under ear directory from web modules, ejb modules or utility modules you need to add names of these jars in their Manifest.MF files.
In my configuration i have 2 web modules and single ejb module, all of them use Spring so placing spring jars under ear and reference them from Manifest.MF file in each of the module is the most common.
This kind of deployment structure is quite natural and SWS agnostic: put jar in a place where any other module that needs it can reference it.

I just wanted to stress that if you have ear containing only web module you could place all jars : spring jars and SWS jars under WEB-INF/lib
and it should also work.