Docx4j and WebLogic not seeing eye-to-eye

[sri]

Using Docx4j version 2.5.0

Having resolved my unexpected element problem (http://dev.plutext.org/forums/viewtopic.php?f=6&t=490&sid=2a9c482911c6001678cb4679a4a2e863) I thought I was home free.

However WebLogic has other ideas. My unit test of creating a docx with custom XML works just fine. However when I invoke this function within my web application running under WebLogic 10 it fails with the the following exception

Code: Select all

java.lang.IllegalArgumentException: obj parameter must not be null
        at javax.xml.bind.helpers.AbstractMarshallerImpl.checkNotNull(AbstractMarshallerImpl.java:398)
        at javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshallerImpl.java:90)
        at org.docx4j.XmlUtils.marshaltoW3CDomDocument(XmlUtils.java:492)
        at org.docx4j.XmlUtils.marshaltoW3CDomDocument(XmlUtils.java:474)
        at org.docx4j.openpackaging.parts.CustomXmlDataStoragePart.applyBindings(CustomXmlDataStoragePart.java:480)


Logs report a bunch of

Code: Select all

2010-11-22 16:00:18,035   WARN JaxbValidationEventHandler - [ERROR] : unexpected element (uri:"http://schemas.openxmlformats.org/wordprocessingml/2006
/main", local:"compatSetting"). Expected

messages as well.

I am able to reproduce this error in my out-of-container unit test if I force weblogic.jar into the head of the classpath.

Does this error suggest something to you? Any suggestions on how to get around it?

[jason]

There is http://forums.oracle.com/forums/thread. ... ID=1111743

Regarding JAXB implementation discovery, http://javadoc.glassfish.org/v3/apidoc/ ... ntext.html says:

Code: Select all


Discovery of JAXB implementation

When one of the newInstance methods is called, a JAXB implementation is discovered by the following steps.

   1. For each package/class explicitly passed in to the newInstance(java.lang.String) method, in the order they are specified, jaxb.properties file is looked up in its package, by using the associated classloader — this is the owner class loader for a Class argument, and for a package the speified ClassLoader.

      If such a file is discovered, it is loaded as a property file, and the value of the JAXB_CONTEXT_FACTORY key will be assumed to be the provider factory class. This class is then loaded by the associated classloader discussed above.

      This phase of the look up allows some packages to force the use of a certain JAXB implementation. (For example, perhaps the schema compiler has generated some vendor extension in the code.)
   2. If the system property JAXB_CONTEXT_FACTORY exists, then its value is assumed to be the provider factory class. This phase of the look up enables per-JVM override of the JAXB implementation.
   3. Look for /META-INF/services/javax.xml.bind.JAXBContext file in the associated classloader. This file follows the standard service descriptor convention, and if such a file exists, its content is assumed to be the provider factory class. This phase of the look up is for automatic discovery. It allows users to just put a JAXB implementation in a classpath and use it without any furhter configuration.
   4. Finally, if all the steps above fail, then the rest of the look up is unspecified. That said, the recommended behavior is to simply look for some hard-coded platform default JAXB implementation. This phase of the look up is so that JavaSE can have its own JAXB implementation as the last resort.

Once the provider factory class is discovered, its public static JAXBContext createContext(String,ClassLoader,Map) method (see newInstance(String, ClassLoader, Map) for the parameter semantics.) or public static JAXBContext createContet(Class[],Map) method (see newInstance(Class[], Map) for the parameter semantics) are invoked to create a JAXBContext.



You could try putting the JAXB reference implementation in Weblogic's endorsed dir.