jersey2-guice, Jersey 2.16 and uber-jar

[smaant]

Hi. I've stumbled upon some interesting behaviour. I'm not sure whether it's a bug or not, but I've decided to share it anyway.

The situation is, if you build any application with jersey2-guice + Jersey >= 2.16 and pack it into uber-jar, then most probably it'll crash on start with a huge stack trace like:

WARNING: The following warnings have been detected: WARNING: Unknown HK2 failure detected:
MultiException stack 1 of 3
com.google.inject.ConfigurationException: Guice configuration errors:

1) No implementation for javax.xml.parsers.DocumentBuilderFactory was bound.
  while locating javax.xml.parsers.DocumentBuilderFactory

1 error
    at com.google.inject.internal.InjectorImpl.getBinding(InjectorImpl.java:159)
    at com.google.inject.internal.InjectorImpl.getBinding(InjectorImpl.java:67)
    at com.squarespace.jersey2.guice.GuiceJustInTimeResolver.findBinding(GuiceJustInTimeResolver.java:90)
...

The key here is an uber-jar and the fact that starting from version 2.16 Jersey has moved JAX-B providers into separate module (release notes). At some points Jersey relyes on information in META-INF/services and after JAX-B providers separations they've created a conflict there (because two jars have implementations for the same interface). So the solution is to add

<transformer implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"/>

into maven-shade-plugin configuration. But first of all, this is very-very unobvious (at least it was for me, and it took me hell of a time to figure all this out). Second of all, if I remove jersey2-guice initialization, then HK2 is able to go around this and somehow finds the right implementation. That's why I've decided to bring that up.

While I was digging all this stuff, I've made some very simple example to reproduce this situation: https://github.com/smaant/jersey-guice-issue

[rkapsi]

@smaant thanks for the repro - I'll look into it as soon as I get a chance.

[maxenglander]

I ran into this same issue, and, FWIW, solved it differently.

Thanks to @smaant pointing to the release notes for 2.16. I looked at the "breaking changes" section of the migration guide (from 2.15), and found this:

JAX-B support modularization might cause breaking changes for those users relying on JAX-B and directly referring to the Jersey core-common module:

<dependency>
  <groupId>org.glassfish.jersey.core</groupId>
  <artifactId>jersey-common</artifactId>
  <version>${pre-2.16-version}</version>
</dependency>

The following needs to be included in addition from version 2.16 on:

<dependency>
  <groupId>org.glassfish.jersey.media</groupId>
  <artifactId>jersey-media-jaxb</artifactId>
  <version>2.16</version>
</dependency>

Although I can't say for certain (perhaps someone else can) that I am "relying on JAX-B and directly referring to the Jersey core-common module", I went ahead and tried adding the jersey-media-jaxb dependency to my pom.xml, and that solved the problem for me (didn't need to add the <transformer />.