Regarding WebLogic and XML processing

[p3consulting]

Context:
we have a tool (webapp providing REST services) replacing MERGEFIELD by different kind of values, among them HTML ones.
So internally, the tool creates ALTCHUNK for HTML type keywords.

Problem:
It works fine in JUNIT testing but when deployed under WebLogic 12c/Java 7/Linux 64bits OS, even if the chunckXX.html end-up in the generated document, the references inside of XML structure are lost and thus the HTML text is not displayed where it should.
Furthermore, in log level DEBUG both JUNIT and WebLogic test cases show up exactly the same sequence of operations, no failure, no stack trace, ...

After fighting several days with the problem, we end-up with the following solution after finding inspiration here: http://docs.oracle.com/cd/E24329_01/web.1211/e24964/data_types.htm#WSGET347. However this page contains some copy/paste errors, so here is the solution:

In your weblogic(-application).xml, be sure you are using the following container descriptor structure:

Code: Select all

    <wls:container-descriptor>

            <wls:prefer-web-inf-classes>false</wls:prefer-web-inf-classes>

            <wls:prefer-application-packages>

    ...

            </wls:prefer-application-packages>

            <wls:prefer-application-resources>

     ...

            </wls:prefer-application-resources>

    ...


In the prefer-application-resources section add:

Code: Select all

              <wls:resource-name>META-INF/services/com.sun.xml.ws.spi.db.BindingContextFactory</wls:resource-name>
              <wls:resource-name>META-INF/services/javax.xml.bind.JAXBContext</wls:resource-name>


In your web application resources add the 2 files in META-INF/services:

Code: Select all

com.sun.xml.ws.spi.db.BindingContextFactory

with content:

Code: Select all

com.sun.xml.ws.db.glassfish.JAXBRIContextFactory

Code: Select all

javax.xml.bind.JAXBContext

with content:

Code: Select all

com.sun.xml.bind.v2.ContextFactory

And that's it: now WebLogic will not use anymore its version of JAXB (Eclipse one) and use the one provided by the JRE (Glassfish).

Of course, this situation raises a more general problem: what about if you specifically need the MOXy version of JAXB to fix another problem with DOCX4J...
Hope that the above description will help to getof real fix : we suspect a low level namespace resolution problem during evaluation of some XML or XSLT.