0 Replies Latest reply: May 3, 2013 12:44 PM by 678421 RSS

    NoClassDefFoundError: XMLGregorianCalendarImpl when unmarshalling XML

    678421
      Our web application uses CXF to contact a web service. When we receive the XML response, we receive a NoClassDefFoundError while unmarshalling the response. The first few lines of the stack trace look like this:

      java.lang.NoClassDefFoundError: org/apache/xerces/jaxp/datatype/XMLGregorianCalendarImpl
      at org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl.newXMLGregorianCalendar(DatatypeFactoryImpl.java:230)
      at javax.xml.bind.DatatypeConverterImpl._parseDateTime(DatatypeConverterImpl.java:311)
      at javax.xml.bind.DatatypeConverterImpl.parseDateTime(DatatypeConverterImpl.java:306)
      at javax.xml.bind.DatatypeConverter.parseDateTime(DatatypeConverter.java:282)
      at org.apache.cxf.tools.common.DataTypeAdapter.parseDateTime(DataTypeAdapter.java:70)

      The application is hosted in an .EAR file containing a "prefer-application-packages" setting:

           <prefer-application-packages>
                <package-name>javax.jws.*</package-name>
                <package-name>org.apache.*</package-name>
           </prefer-application-packages>

      The EAR file contains the application descriptor and a single WAR file. The WAR file contains xercesImpl-2.11.0.jar, jaxb-api-2.2.7.jar, and about 30 other dependencies. This ClassNotFoundError does not occur in Jetty, and does not occur on the single-server WebLogic instance on my local workstation -- it only occurs on the remote WebLogic instance which uses a clustered setup, with separate admin/managed servers.

      I redeployed the application about a dozen times, experimenting with adding/removing different dependencies, but the error happened on a consistent basis. This error is similar to the one discussed in [Thread #947633|https://forums.oracle.com/forums/thread.jspa?threadID=947633] here, which eventually led me to restart the managed server hosting our web application. After restarting the managed server, the problem went away, and I haven't been able to duplicate the problem since. It appears that the bug is dependent on which JAXP factory gets loaded first.

      So, arguably this problem might be resolved, and the solution is, "If you ever redeploy a new version of our application, restart the managed server so that WebLogic will load our JAXP factory first". But, it begs a few questions:

      1. Is this behavior reliable? I've restarted the managed server five times, and the correct JAXP factory has "won" every time. But, is this reliable behavior, or is there a race condition? Is there a chance that I'll load our web application on a new machine, restart the managed server, and WebLogic's JAXP factory will get loaded before our web application's JAXP factory?
      2. Is there a better way to deconflict our JAXP factories? Perhaps something similar to the [XML application scoping|http://docs.oracle.com/cd/E12839_01/web.1111/e13724/appscope.htm] options in the deployment descriptor, or the "-Djavax.xml.parsers.SAXParserFactory" startup flag?