JasonPlutext
JasonPlutext

Reputation: 15878

Does WebSphere's JAXB MarshallerProxy use the reference implementation?

At https://stackoverflow.com/a/35443723/1031689

setting the system property com.ibm.xml.xlxp.jaxb.opti.level=0 in WebSphere. Using this setting will cause the JAXB reference implemenation to be used for unmarshalling and marshalling instead of the WebSphere JAXB implementation.

I set this at Application servers > server1 > Process definition > Java Virtual Machine > Custom properties in WebSphere 9.0.0.4,then stopped and restarted the server, and in my webapp:

System.getProperty("com.ibm.xml.xlxp.jaxb.opti.level")

now returns 0, as expected.

However,

context.getClass().getName().startsWith("com.ibm.xml.xlxp2.jaxb")

still returns true.

and

Marshaller m=org.docx4j.jaxb.Context.jc.createMarshaller();
System.out.println(m.getClass().getName());

returns:

com.ibm.xml.xlxp2.jaxb.marshal.MarshallerProxy

(actually, that returns MarshallerProxy irrespective of whether com.ibm.xml.xlxp.jaxb.opti.level is set or not)

When level=0, does MarshallerProxy invoke the reference implementation? Is that how it works?

Upvotes: 2

Views: 1571

Answers (1)

JasonPlutext
JasonPlutext

Reputation: 15878

Answer: only if it can't load com.ibm.jtc.jax.xml.bind.v2.runtime.JAXBContextImpl (which is in com.ibm.jaxb.tools.jar)

To see this, invoking toString() on your context object is useful:

Primary JAXBContext:
bundleresource://138.fwk797973828/com/ibm/xml/xlxp2/jaxb/JAXBContextImpl.class,
Version: 1.6.2-jaxb,
Timestamp: Tue, 18 Oct 2016 17:08:48 EDT,
Classes known to this context:
  [NONE] (Fallback JAXBContext will be used to process any requests.)

Fallback JAXBContext:
bundleresource://11.fwk797973828/com/ibm/jtc/jax/xml/bind/v2/runtime/JAXBContextImpl.class Build-Id: null

So XLXP uses com.ibm.jtc.jax.xml.bind.v2.runtime.JAXBContextImpl.

Now, with com.ibm.xml.xlxp.jaxb.opti.level=0 set:

Primary JAXBContext:
bundleresource://138.fwk-1179731101/com/ibm/xml/xlxp2/jaxb/JAXBContextImpl.class,
Version: 1.6.2-jaxb,
Timestamp: Tue, 18 Oct 2016 17:08:48 EDT,
Classes known to this context:
  [NONE] (Fallback JAXBContext will be used to process any requests.)

Fallback JAXBContext:
bundleresource://11.fwk-1179731101/com/ibm/jtc/jax/xml/bind/v2/runtime/JAXBContextImpl.class Build-Id: null

That is, no change! IBM JAXB is still being used.

Two ways to try to change that:

  1. com.ibm.ws.prereq.xlxp.jar/META-INF/services/com.ibm.xml.xlxp.jaxb.fallback.context contains com.ibm.jtc.jax.xml.bind.v2.ContextFactory; we could put something else in there
  2. remove com.ibm.jaxb.tools.jar

I tried removing com.ibm.jaxb.tools.jar. After restarting WAS:

Primary JAXBContext:
bundleresource://138.fwk-218185936/com/ibm/xml/xlxp2/jaxb/JAXBContextImpl.class,
Version: 1.6.2-jaxb,
Timestamp: Tue, 18 Oct 2016 17:08:48 EDT,
Classes known to this context:
  [NONE] (Fallback JAXBContext will be used to process any requests.)

Fallback JAXBContext:
jar:file:/home/jharrop/IBM/WebSphere/AppServer/java/8.0/jre/lib/rt.jar!/com/sun/xml/internal/bind/v2/runtime/JAXBContextImpl.class Build-Id: 1.8.0

So interestingly, if you remove com.ibm.jaxb.tools.jar, com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl is there (at least in my installation) and used! So I guess you could instead specify it in com.ibm.ws.prereq.xlxp.jar/META-INF/services/com.ibm.xml.xlxp.jaxb.fallback.context

If you do play around with removing com.ibm.jaxb.tools.jar, when you add it back in, remember to clear the class cache so WAS finds it again (stop the server, run bin/clearClassCache): http://www-01.ibm.com/support/docview.wss?uid=swg21607887

WebSphere 8.5.5.13 (using IBM Java 1.8.0_151 - what a pain to install!) seems similar.

Upvotes: 1

Related Questions