Fix docx4j on Websphere Liberty

[jluyten]

No longer rely on com.sun.xml.internal classes and use Glassfish JAXB Reference Implementation ContextFactory to create JAXBContext. This ensures that Websphere Liberty's internal JAXB imlpementation is not used, but the provided Glassfish JAXB RI is used.

[jluyten]

This fixes #409

[plutext]

Before your changes, what logging was produced at https://github.com/plutext/docx4j/blob/master/docx4j-core/src/main/java/org/docx4j/jaxb/Context.java#L168 and following?

You have changed both docx4j-JAXB-Internal and docx4j-JAXB-ReferenceImpl, but you should only be using ONE of the docx4j-JAXB-* jars.

Do you have a preferenced between Liberty's internal JAXB imlpementation and the Glassfish JAXB RI?

If the former, if necessary we can create a new docx4j-JAXB-IBM-XLXP2 (or FastPath)

If the latter, instead of introducing a dep on com.sun.xml.bind.v2.ContextFactory in docx4j-core (which we can't do), did you try setting system property javax.xml.bind.JAXBContextFactory=com.sun.xml.bind.v2.ContextFactory ? I suspect that wouldn't be enough; see https://stackoverflow.com/questions/48700004/does-webspheres-jaxb-marshallerproxy-use-the-reference-implementation

OpenLiberty/open-liberty#5056 (comment) is interesting, the behaviour may depend on whether the jaxws+Jaxb feature is activated

[jluyten]

The JAXBContext when using an IBM JDK7 and Liberty (was during a debugging session where I tried to mimic what Websphere had, as much as possible):

Primary JAXBContext:
bundleresource://115.fwk1457742952/com/ibm/xml/xlxp2/jaxb/JAXBContextImpl.class,
Version: 1.5.5-jaxb,
Timestamp: Fri, 7 Mar 2014 15:55:00 EST,
Classes known to this context:
  [NONE] (Fallback JAXBContext will be used to process any requests.)
Fallback JAXBContext:
bundleresource://114.fwk1457742952/com/sun/xml/bind/v2/runtime/JAXBContextImpl.class Build-Id: null
Classes known to this context:
  [B
  boolean
  byte
  char
  com.sun.xml.bind.api.CompositeStructure
  double
  float
  int
  java.awt.Image
  java.io.File
  java.lang.Boolean
  java.lang.Byte
  java.lang.Character
  java.lang.Class
  java.lang.Double
  java.lang.Float
  java.lang.Integer
  java.lang.Long
  java.lang.Object
  java.lang.Short
  java.lang.String
  java.lang.Void
  java.math.BigDecimal
  java.math.BigInteger
  java.net.URI
  java.net.URL
  java.util.Calendar
  java.util.Date
  java.util.GregorianCalendar
  java.util.UUID
  javax.activation.DataHandler
  javax.xml.bind.JAXBElement
  javax.xml.datatype.Duration
  javax.xml.datatype.XMLGregorianCalendar
  javax.xml.namespace.QName
  javax.xml.transform.Source
  long
  org.docx4j.relationships.Relationship
  org.docx4j.relationships.Relationships
  short
  void

I realise the proposed change is not ideal, but was necessary to get it working at my end. I tried all the combinations (and also solely JAXB-internal or JAXB-ReferenceImpl). In any case, I believe the xml.internal dependency should be removed.

I did not try setting the system property javax.xml.bind.JAXBContextFactory=com.sun.xml.bind.v2.ContextFactory.

The comment made in your last link seems to reflect the behavior we had: "Because these Jaxb libs are not the same as the Jaxb libs from the Java 8 that our application uses, we get an exception.".

The problem we had was that with Liberty, once the JAXB feature is enabled (which we had no easy choice in, since we needed JAXWS) we could not control the JAXB implementation, the IBM XLXP2 implementation was used. Then we got exceptions thrown from the MarshallerImpl which expected a certain NamespacePrefixMapper (of a certain internal IBM XLXP2 type), but it got a docx4j type. Even though it had the same classname/path, it was still not the same, and so we had exception (can't off the top of my head recall which one it was).

So indeed, if we can provide a docx4j-JAXB-IBM-XLXP2 implementation, which passes an xlxp2 namespacePrefixMapper to the marshaller, then there would not be a clash.

[jluyten]

Any update @plutext ?

[plutext]

We can't merge this pull request because it would break docx4j. As I mentioned elsewhere, to work on this we'd need to setup a Websphere Liberty environment which we could only do right now on a commercial basis.

[jluyten]

@plutext alright no problem. This was not clear for me. I won't be looking into this any further (we forked and created a "fixed" docx4j for us). Just wanted to give back to the community :-) Cheers!