The SIS MarshallerPool class uses the NamespacePrefixMapper class from the com.sun.xml.internal.bind package. We are obviously not supposed to use this internal class, but research on Internet 3 years ago suggested that they were no way (at least at that time) to specify the root namespace (the namespace that do not need prefix) and to customize the prefixes. Worst, this internal feature was advertised as customizable by the following properties:
- com.sun.xml.internal.bind.NamespacePrefixMapper (bundled JAXB)
- com.sun.xml.bind.NamespacePrefixMapper (endorsed JAXB)
Furthermore the NamespacePrefixMapper javadoc said: "Implemented by the user application to determine URI -> prefix mapping".
As an alternative, research on Internet suggests that the javax.xml.bind.annotation.XmlSchema annotation works as expected in JDK7, but JDK6 users have to use the endorsed JAXB version 2.2.4 or above. Bundled versions are:
- Java 1.6.0_37 is bundled with JAXB 2.1.10, so @XmlSchema doesn't seem to work on that platform.
- Java 1.7.0_15 is bundled with JAXB 2.2.4-2, so @XmlSchema would work on that platform but we still have to check if it really works for us.
Note that the NamespacePrefixMapper approach is still advertised even in the JAXB 2.2.6 documentation.
If the @XmlSchema annotations do not work, or if we want to be compatible with the JAXB version bundled in JDK6, then we may have to keep the NamespacePrefixMapper hack. Problem is that the javac compiler normally blocks attempts to use this com.sun.xml.internal class. A workaround found on Internet (not yet tested) is to use the following compiler option:
If the above does not work, an alternative is to put rt.jar on the classpath as a Maven dependency using <scope>system</scope>. But this work only for Oracle JDK.
An other alternative is to put a com.sun.xml.internal.bind.NamespacePrefixMapper class with only the method signature in the sis-utility module, and exclude that class from the JAR file. The maven-jar-plugin provides an exclusion mechanism for that kind of purpose, but I have been unable to make it work. We may have to use (again) our sis-build-helper module for deleting the com/** files before JAR packaging.