如何阻止 maven-shade-plugin 阻止 opensaml-impl 类型的 java.util.ServiceLoader 初始化答案

【问题标题】：How to stop maven-shade-plugin from blocking java.util.ServiceLoader initialization of opensaml-impl types如何阻止 maven-shade-plugin 阻止 opensaml-impl 类型的 java.util.ServiceLoader 初始化
【发布时间】：2017-07-21 07:08:01
【问题描述】：

使用 OpenSAML 3 时，您必须首先使用以下代码行从 opensaml-saml-impl 工件加载组件：

InitializationService.initialize();

这个uses java.util.ServiceLoader to load any type which implements Initializer。

当我编写一个测试并使用mvn integration-test 运行它时，它工作正常，我可以看到所有内容都已加载：

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

但是，我的项目使用maven-shade-plugin。如果我将代码打包到 uber-jar 中，则上述条件为 not：

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

在这种情况下，我观察到只有 9 个解组器已加载（opensaml-core 中的那些，而不是 opensaml-saml-impl 中的那些。但是，当我查看 mvn package 的输出时，我可以看到类型被包含在阴影罐中：

[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.

我可以使用以下愚蠢的代码解决这个问题：

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();
}

这完全违背了插件系统的意义，但它确实允许我的程序运行。

供参考，这里是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>

【问题讨论】：

不要将AppendingTransformer 用于META-INF/services，您可以只使用ServicesResourceTransformer。这可能是问题所在。你检查过胖 JAR 里面META-INF/services 下的内容吗？
只需将AppendingTransformer 更改为ServicesResourceTransformer 就会出现错误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。（也尝试更新到阴影 3.0）我误解你了吗？我对 Shade 很天真，抱歉！
您只是在Services（不是Service）中错过了s。而且你也不需要它下面的<resource> 元素。
看起来它可能成功了！我将进行端到端测试以确保它没有破坏其他任何东西，但我确实看到解组器正在加载
@Tunaki 请将此添加为答案，这样如果端到端测试通过，我可以奖励您。

标签： java maven maven-shade-plugin opensaml

【解决方案1】：

当您使用 Maven Shade 插件和使用 ServiceLoader API 的依赖项时，您应该使用专用于将文件合并在一起的 ServicesResourceTransformer。如果插件是relocating classes，它也会正确重定位每个服务文件中的类名，不像AppendingTransformer。

所以你可以用

替换你当前的AppendingTransformer

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

它将确保您的依赖项META-INF/services 下的每个服务文件都被合并，而无需全部声明。

【讨论】：