java.lang.VerifyError: class loading constraint violated on org/w3c/dom/UserDataHandler

[easternwahoo <ja...@siemens.com>]

I deployed a CXF client within a WAR, to Websphere 6.1,  with parent-last
classloading at the WAR level, and the shared library technique described
here: 
http://cxf.apache.org/docs/application-server-specific-configuration-guide.html#ApplicationServerSpecificConfigurationGuide-Addyourownclassloader
http://cxf.apache.org/docs/application-server-specific-configuration-guide.html#ApplicationServerSpecificConfigurationGuide-Addyourownclassloader  

Several CXF dependencies include org/w3c/dom/UserDataHandler in their jar
files, which causes a java.lang.VerifyError: class loading constraint
violoated.  This class is included in jaxen, xalan, and in the
XMLBeans-2.4.0.jar  distributed with CXF.  XMLBeans' downloaded jar does not
contain these classes, and I'm puzzled as to why CXF's version of xmlbeans
does include this jar.

Options to circumvent the problem include 1) running with parent-first
classloading (the websphere default), or 2) removing the offending classes
from the jar files, or 3) removing the jar files altogether.  I did a
combination of these: I removed xmlbeans and xalan, and used parent-first
classloading.   

I'm inclined to remove all "unnecessary" jars from our war build, but the
process feels like hacking: remove a jar, see what happens, rinse and
repeat. As our application evolves and we use other features of CXF, we'll
be back in hacker-mode trying to figure out which jars we need to include.
It would help if we knew which CXF functions depend on which jars. 
-- 
View this message in context: http://old.nabble.com/java.lang.VerifyError%3A-class-loading-constraint-violated-on-org-w3c-dom-UserDataHandler-tp29034694p29034694.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: java.lang.VerifyError: class loading constraint violated on org/w3c/dom/UserDataHandler

[Daniel Kulp <dk...@apache.org>]

On Wednesday 30 June 2010 9:39:09 am easternwahoo wrote:
> I deployed a CXF client within a WAR, to Websphere 6.1,  with parent-last
> classloading at the WAR level, and the shared library technique described
> here:
> http://cxf.apache.org/docs/application-server-specific-configuration-guide.
> html#ApplicationServerSpecificConfigurationGuide-Addyourownclassloader
> http://cxf.apache.org/docs/application-server-specific-configuration-guide
> .html#ApplicationServerSpecificConfigurationGuide-Addyourownclassloader
> 
> Several CXF dependencies include org/w3c/dom/UserDataHandler in their jar
> files, which causes a java.lang.VerifyError: class loading constraint
> violoated.  This class is included in jaxen, xalan, and in the
> XMLBeans-2.4.0.jar  distributed with CXF.  XMLBeans' downloaded jar does
> not contain these classes, and I'm puzzled as to why CXF's version of
> xmlbeans does include this jar.

It's the version the XMLBeans team released and deployed to maven central 
repo.  Thus, whatever they put in it is what we would get:
http://repo1.maven.org/maven2/org/apache/xmlbeans/xmlbeans/2.4.0/

> 
> Options to circumvent the problem include 1) running with parent-first
> classloading (the websphere default), or 2) removing the offending classes
> from the jar files, or 3) removing the jar files altogether.  I did a
> combination of these: I removed xmlbeans and xalan, and used parent-first
> classloading.
> 
> I'm inclined to remove all "unnecessary" jars from our war build, but the
> process feels like hacking: remove a jar, see what happens, rinse and
> repeat. As our application evolves and we use other features of CXF, we'll
> be back in hacker-mode trying to figure out which jars we need to include.
> It would help if we knew which CXF functions depend on which jars.

See:

http://svn.apache.org/repos/asf/cxf/trunk//distribution/src/main/release/lib/WHICH_JARS



-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog