How to stop maven-shade-plugin from blocking java.util.ServiceLoader initialization of opensaml-impl types

Question

When using OpenSAML 3, you must first load components from the opensaml-saml-impl artifact with the following line of code:

InitializationService.initialize();

This uses java.util.ServiceLoader to load any type which implements Initializer.

When I write a test and run it with mvn integration-test, this works fine, and I can see that everything has loaded:

Assert.assertTrue(
    XMLObjectProviderRegistrySupport
        .getUnmarshallerFactory()
        .getUnmarshallers()
        .size() > 400);

However, my project uses maven-shade-plugin. The condition above is not true if I package the code into an uber-jar:

mvn package
java -jar /path/to/my.jar

In this case I observe that only 9 unmarshallers have loaded (those in opensaml-core, as opposed to those in opensaml-saml-impl. However, when I watch the output of mvn package, I can see that the types are included in the shaded jar:

[INFO] Including org.opensaml:opensaml-saml-impl:jar:3.2.0 in the shaded jar.
[INFO] Including org.opensaml:opensaml-profile-api:jar:3.2.0 in the shaded jar.
[INFO] Including org.opensaml:opensaml-messaging-api:jar:3.2.0 in the shaded jar.
[INFO] Including org.opensaml:opensaml-saml-api:jar:3.2.0 in the shaded jar.
[INFO] Including org.opensaml:opensaml-xmlsec-api:jar:3.2.0 in the shaded jar.
[INFO] Including org.opensaml:opensaml-soap-api:jar:3.2.0 in the shaded jar.
[INFO] Including org.opensaml:opensaml-storage-api:jar:3.2.0 in the shaded jar.
[INFO] Including org.opensaml:opensaml-security-impl:jar:3.2.0 in the shaded jar.
[INFO] Including org.opensaml:opensaml-security-api:jar:3.2.0 in the shaded jar.

I can work around this issue with the following dumb code:

private static void initManuallyInsteadOfWithInitializationServiceSoThatMavenShadePluginDoesNotRemoveThem() throws InitializationException {
    new ApacheXMLSecurityInitializer().init();
    new ClientTLSValidationConfiguratonInitializer().init();
    new GlobalAlgorithmRegistryInitializer().init();
    new GlobalParserPoolInitializer().init();
    new GlobalSecurityConfigurationInitializer().init();
    new JavaCryptoValidationInitializer().init();
    new SAMLConfigurationInitializer().init();
    new org.opensaml.core.xml.config.XMLObjectProviderInitializer().init();
    new org.opensaml.xmlsec.config.XMLObjectProviderInitializer().init();
    new XMLObjectProviderInitializer().init();
}

This utterly defeats the point of the plugin system, but it does allow my program to function.

For reference, here's the relevant bits of pom.xml:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-shade-plugin</artifactId>
    <version>2.3</version>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>shade</goal>
            </goals>
            <configuration>
                <transformers>
                    <transformer
                            implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                        <manifestEntries>
                            <Main-Class>com.example.Server</Main-Class>
                        </manifestEntries>
                    </transformer>
                    <transformer
                            implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
                        <resource>META-INF/services/io.vertx.core.spi.VerticleFactory</resource>
                    </transformer>
                </transformers>
                <artifactSet>
                </artifactSet>
                <outputFile>${project.build.directory}/${project.artifactId}-${project.version}-fat.jar
                </outputFile>
                <filters>
                    <filter>
                        <!-- Fix java.lang.SecurityException: Invalid signature file digest for Manifest main attributes
                             when server starts inside Docker container due to inclusion of OpenSAML and use of
                             uber-jar / maven-shade-plugin. See http://stackoverflow.com/a/6743609 -->
                        <artifact>*:*</artifact>
                        <excludes>
                            <exclude>META-INF/*.SF</exclude>
                            <exclude>META-INF/*.DSA</exclude>
                            <exclude>META-INF/*.RSA</exclude>
                        </excludes>
                    </filter>
                    <filter>
                        <!-- This was one of my attempts to fix the problem.
                             Unfortunately, it doesn't work. -->
                        <artifact>org.opensaml:opensaml-saml-impl</artifact>
                        <includes>
                            <include>**</include>
                        </includes>
                    </filter>
                </filters>
            </configuration>
        </execution>
    </executions>
</plugin>

Don't use `AppendingTransformer` for the `META-INF/services`, you can just use [`ServicesResourceTransformer`](https://maven.apache.org/plugins/maven-shade-plugin/examples/resource-transformers.html#ServicesResourceTransformer). This may be the issue. Did you check inside the fat JAR what was present under `META-INF/services`? — Tunaki, Mar 01 '17 at 19:41
Just changing `AppendingTransformer` to `ServicesResourceTransformer` gives me the error `Unable to parse configuration of mojo org.apache.maven.plugins:maven-shade-plugin:3.0.0:shade for parameter transformers: Cannot load implementation hint 'org.apache.maven.plugins.shade.resource.ServiceResourceTransformer`. (Also tried updating to shade 3.0) Am I misunderstanding you? I'm pretty naïve about Shade, sorry! — Craig Stuntz, Mar 01 '17 at 19:55
You just missed an `s` in `Services` (not `Service`). And you wouldn't need the `` element under it either. — Tunaki, Mar 01 '17 at 19:56
That looks like it might have done the trick! I'm going to do an end to end test to make sure it didn't break anything else, but I do see the unmarshallers loading — Craig Stuntz, Mar 01 '17 at 20:02
@Tunaki please add this as an answer so I can award you credit if the end to end test passes. — Craig Stuntz, Mar 01 '17 at 20:04

score 10 · Accepted Answer · answered Mar 01 '17 at 20:15

When you're using the Maven Shade Plugin with dependencies using the ServiceLoader API, you should use the ServicesResourceTransformer, which is dedicated to merge together the files. If the plugin is relocating classes, it will also relocate properly the class names in each service file, unlike the AppendingTransformer.

So you can just replace your current AppendingTransformer with

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

It will make sure that every service file under META-INF/services of your dependencies are merged, without the need to declare them all.

How to stop maven-shade-plugin from blocking java.util.ServiceLoader initialization of opensaml-impl types

1 Answers1

Linked