ANY23-419 Add J2EE dependencies such that service runs under JDK11

[lewismc]

This issue addresses https://issues.apache.org/jira/browse/ANY23-419

[HansBrende]

@lewismc FYI, I believe that some of these dependencies are already pulled in by Tika.

Running mvn dependency:tree on the service module, I see:

• javax.xml.bind:jaxb-api:jar:2.3.0 is pulled in by tika-parsers
• org.glassfish.jaxb:jaxb-core:jar:2.3.0.1 is pulled in by tika-parsers
• javax.activation:activation:jar:1.1.1 is pulled in by tika-parsers

leaving (I believe) the only library not already pulled in by Tika to be the jaxws-api.

Out of curiosity though, where are these libraries actually used by the service? Are they required by jetty?

[lewismc]

The issue I was having was when running it in Tomcat. From what I could tell Tomcat does not ship with these libraries either so they need to be added manually. Please try it out yourself and see where you get. I am by no means a Tomcat, Servlet Container or J2EE expert to I am not 100% sure this fix is optimum.

[HansBrende]

@lewismc I have zero experience with Tomcat, so I'm just as in-the-dark as you in this regard. Did you get an error message or stacktrace you could post here?

I'd recommend removing all the newly added dependencies except for javax.xml.ws:jaxws-api, since that's the only one (I think) that Tika doesn't already pull in, and see how far that gets us. (Because otherwise we might need to add additional exclusions to our tika-parsers dependency to avoid conflicting class names if anyone's using the maven-shade-plugin or similar).

[HansBrende]

@lewismc Also, now that they've granted me access, how do I actually access the VM? https://issues.apache.org/jira/browse/INFRA-17224

[lewismc]

ssh HansBrende@any23-vm2.apache.org

We need to document where everything is, in short however it resides here
Any23 Source
/usr/loca/any23

Tomcat9 deployment
/opt/tomcat9/

That will get you going. You need sudo for absolutely everything. If you need assistance with that then let me know.

[HansBrende]

@lewismc when I try to use sudo to, for example, read a text file using

sudo cat /opt/tomcat9/BUILDING.txt

It gives me a

sudo: PAM authentication error: User not known to the underlying authentication module

Any ideas?

[lewismc]

First thing is 1) you don't need to access BUILDING.txt however 2) see https://apache.org/dev/freebsd-jails#opie

[ansell]

@HansBrende The J2EE APIs (and implementations in some cases) were provided in the past by the JDK itself, not Tomcat or other J2EE containers, and they are not necessarily new dependencies. The new design (since Java-9) is to pull them in as maven artifacts rather than relying on them existing in the JDK.

[HansBrende]

@ansell Right. And I know that Tika (as of 1.19.0) already pulls in all but one of these dependencies (I think). The only difference being, Tika uses the jaxb-core module from glassfish rather than com.sun.xml.bind. So, should we exclude the Tika dependencies and use these? Or just use Tika's, with the addition of jaxws-api? (Basically, I'm just trying to avoid overlapping class names).

[ansell]

I am not sure what the tika situation is, there is a reference in this commit to "removing jaxb" from tika in 1.17, but that may just have been tika-core, not tika-parsers apache/tika@ac25932

[HansBrende]

@ansell Well, this is what I see when I run mvn dependency:tree on the current state of the Any23 master branch:

[INFO] |  +- org.apache.tika:tika-core:jar:1.19.1:compile
[INFO] |  +- org.apache.tika:tika-parsers:jar:1.19.1:compile
[INFO] |  |  +- org.glassfish.jaxb:jaxb-core:jar:2.3.0.1:compile
[INFO] |  |  |  +- javax.xml.bind:jaxb-api:jar:2.3.0:compile
[INFO] |  |  |  +- org.glassfish.jaxb:txw2:jar:2.3.0.1:compile
[INFO] |  |  |  \- com.sun.istack:istack-commons-runtime:jar:3.0.5:compile
[INFO] |  |  +- org.glassfish.jaxb:jaxb-runtime:jar:2.3.0.1:compile
[INFO] |  |  |  +- org.jvnet.staxex:stax-ex:jar:1.7.8:compile
[INFO] |  |  |  \- com.sun.xml.fastinfoset:FastInfoset:jar:1.2.13:compile
[INFO] |  |  +- javax.activation:activation:jar:1.1.1:compile

[ansell]

Interesting that they went down the route of adding compile-time dependencies on the implementation, rather than compile on the api and runtime on the implementation.

Based on fixing this in other libraries I have had success using the api artifacts in the maven compile scope with the implementations in runtime scope. Could possibly exclude the tika dependencies and switch to that strategy in Any23 rather than adding them all to compile scope here.

[lewismc]

OK, let me rework things on my end and see what I can come up with.
@ansell my suspicion is that this is just bloat over in Tika... it's something which we will know very well.

[HansBrende]

@lewismc @ansell of interest may be TIKA-2743, entitled, "Replace com.sun.xml.bind:jaxb-impl and jaxb-core by org.glassfish.jaxb:jaxb-runtime and jaxb-core", which states:

com.sun.xml.bind:* is actually the old name and is currently a repackaging of org.glassfish.jaxb:*. probably kept as a retro compatibility

[HansBrende]

Indeed, when I navigate to https://javalibs.com/bom/com.sun.xml.bind/jaxb-impl
I see:

This artifact has been retired! New location is: org.glassfish.jaxb:jaxb-runtime

[HansBrende]

ALSO: it appears that, as of org.glassfish.jaxb:jaxb-runtime version 2.3.1, jaxb-core is no longer required (as it has been merged into jaxb-runtime).

See: https://issues.jboss.org/browse/WFLY-11113

[HansBrende]

ALSO: it appears that javax.activation:activation:1.1.1 has been replaced by com.sun.activation:javax.activation:1.2.0 and javax.activation:javax.activation-api:1.2.0. However, I'm a bit fuzzy on how this works because it appears that the javax.activation-api sources are a subset of the javax.activation sources (i.e., javax.activation:1.2.0 does not depend on javax.activation-api:1.2.0, but rather simply copies the source files... I think.)

In any case, org.glassfish.jaxb:jaxb-runtime:2.3.1 depends on javax.activation:javax.activation-api:1.2.0, but does not depend on com.sun.activation:javax.activation:1.2.0. Leading me to believe that if we include both jaxb-runtime:2.3.1 and javax.activation:1.2.0, we might have to exclude javax.activation-api from jaxb-runtime to avoid duplicate classes?

Cf. https://stackoverflow.com/questions/46493613/what-is-the-replacement-for-javax-activation-package-in-java-9

Cf. https://stackoverflow.com/questions/52921879/migration-to-jdk-11-has-error-occure-java-lang-noclassdeffounderror-javax-acti

Cf. https://stackoverflow.com/questions/48204141/replacements-for-deprecated-jpms-modules-with-java-ee-apis

Cf. https://mvnrepository.com/artifact/org.glassfish.jaxb/jaxb-runtime/2.3.1

[HansBrende]

Created an issue about this in Tika: https://issues.apache.org/jira/projects/TIKA/issues/TIKA-2778

[HansBrende]

See also: https://issues.apache.org/jira/browse/CXF-7899

[lewismc]

OK folks, PR updated. Thank you for the review. I've tested locally and inclusion of only of dependency now enables deploying Any23 master in Tomcat 9 running JDK11.

[ansell]

Only having to add the jaxws to get it working simplifies things. Moving the J2EE APIs out seems very useful, so should be short term pain for long term gain in this case.

[lewismc]

Any objections to merge?

[HansBrende]

No objections from me!
+1.