In JDK 9, JAXB is deprecated. In JDK 11, JAXB is fully removed. There are three routes to solve this problem:
Of these, (3) seems like the most work and worth little effort. This document describes the first two options in more detail, specifically as they apply to JSS with the note that PKI also uses JAXB and thus should follow the same route.
JDK seems to have included JAXB in JDK6. However, JAXB is a separate upstream which has been transferred to the Eclipse foundation. It used to be/is currently shipped by Fedora as part of the Oracle GlassFish JavaEE distribution. Note that JDK has decided in JDK9 to stop shipping JavaEE components as part of the JDK. In JDK11, they have been fully removed.
However, Fedora and Debian package the JAXB module separately from the JDK.
glassfish-jaxb-api
libjaxb-api-java
Thus, we can keep using the JAXB interface if we include another Jar.
Since there is no apparent conflict when testing using the glassfish-jaxb-api-provided jar on JDK8, it is possible to add a hard dependency in the next JSS version on this package.
This'd look like:
BuildRequires: glassfish-jaxb-api Requires: glassfish-jaxb-api
and all of JSS's dependents which want to build with JDK9+ can then add /usr/share/java/jaxb-api.jar to the classpath.
/usr/share/java/jaxb-api.jar
This is the simplest option, with the cost of a hard dependency on jaxb (another package that people have to pull in when using JSS that is only necessary for JDK9+).
We can detect the JDK version in the spec somehow (todo: research how) and make a conditional Requires. If we're then building with a JDK version 9 or greater, we will add the above specfile change (in a conditional).
The downside of this is that we could build on JDK8 but be expected to run on JDK9 and glassfish-jaxb-api is not installed and so not provided in the classpath, causing problems for the user.
/cc @mharmsen @dmoluguw @edewata @jmagne @cfu @emaldonado
I think option 1 is better as long as there is no class loading issue since we may have JAXB from JDK and glassfish in the classpath.
Metadata Update from @edewata: - Custom field component adjusted to None - Custom field feature adjusted to None - Custom field origin adjusted to None - Custom field proposedmilestone adjusted to None - Custom field proposedpriority adjusted to None - Custom field reviewer adjusted to None - Custom field type adjusted to None - Custom field version adjusted to None
@edewata I can confirm.
For lack of an easier test, using the first sample code from a Google result...:
$ javac -classpath /usr/share/java/jaxb-api.jar com/mkyong/core/*.java ; echo $? 0 $ java -classpath .:/usr/share/java/jaxb-api.jar com.mkyong.core.JAXBExample ; echo $? <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <customer id="100"> <age>29</age> <name>mkyong</name> </customer> 0 $ java -version openjdk version "1.8.0_181" OpenJDK Runtime Environment (build 1.8.0_181-b15) OpenJDK 64-Bit Server VM (build 25.181-b15, mixed mode) $ file /usr/share/java/jaxb-api.jar /usr/share/java/jaxb-api.jar: Java archive data (JAR)
So yes, this works on Java 8 without any (obvious) problems.
Tomcat uses multiple class loaders: https://tomcat.apache.org/tomcat-8.5-doc/class-loader-howto.html
If JAXB is not loaded consistently in all class loaders there could be a problem. I don't expect there would be any problem in our case, but it's just something to look out for.
So unless somebody else objects we probably can proceed with option 1.
The https://github.com/emaldona/jss/tree/jaxb_for_opensuse branch has a possible improvement to what we have. The suggested changes are https://github.com/emaldona/jss/commit/f616ae98ded88fa73c78ce0d28283eb988ba986c
As far as my testing goes it works for openSUSE and doesn't break debian nor fedora whether with jdk 11 or jdk 8. Not ready yet to do a pull request until i learn more and get some feedback. For one, adding to tools/Dockerfiles upensuse_jdk and opensuse_jdk11 files is not an easy task.
Not Docker ready yet but allow me to share a few things I have learned. Followed the latest build instructions on the wiki and use them to build in openSUSE the easy way.
Notes on that for the time when we do support opensusue upstream jss builds:
Dependencies Same list as on the wiki plus an extra entry for JAXME required for openSUSE builds * JAXME with the link to apache Maven Repository Something like this
Then below after the Fedora and Debian we could add this one.
To install these dependencies on openSUSE, execute the following: sudo zypper install apache-commons-codec apache-commons-lang gcc-c++ \ java-devel jpackage-utils slf4j zlib-devel \ ws-jaxme mozilla-nss-tools mozilla-nss-devel
The section that says: Alternatively, to build a RPM distribution of JSS: That will not work in openSUSE, like it doesn't for Debian, because the jss.spec file's depedencies which are Fedora based. openSUSE package maintainers patch their downstream copy jss.spec file as they feel is needed.
I have a slight variant of the lib/Common.pm which @cipherboy has in the opensuse-container branch of this fork. Here is patch with suggested changes.
<img alt="opensuse-latest.patch" src="/jss/issue/raw/files/254ad45bebfd2453fc51d7c95de0cc6b83b53fefc07b4bd305e01eceb3b028b7-opensuse-latest.patch" />
These changes have been merged in JSS and Dogtag PKI. A new JSS release has not yet been made but the dependency is added: - https://github.com/dogtagpki/jss/pull/54 - https://github.com/dogtagpki/pki/pull/84
Metadata Update from @cipherboy: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.