如何阻止 maven-shade-plugin 阻止 java.util.ServiceLoader opensaml-impl 类型的初始化
How to stop maven-shade-plugin from blocking java.util.ServiceLoader initialization of opensaml-impl types
使用 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
的输出时,我可以看到类型 是 包含在阴影 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.
我可以使用以下愚蠢的代码解决这个问题:
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 -->
<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>
当您使用 Maven Shade 插件并使用 ServiceLoader
API 依赖项时,您应该使用 ServicesResourceTransformer
, which is dedicated to merge together the files. If the plugin is relocating classes,它也会正确地重新定位 class每个服务文件中的名称,与 AppendingTransformer
.
不同
因此,您只需将当前的 AppendingTransformer
替换为
<transformer implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"/>
它将确保合并 META-INF/services
依赖项下的每个服务文件,而无需全部声明它们。
使用 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
的输出时,我可以看到类型 是 包含在阴影 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.
我可以使用以下愚蠢的代码解决这个问题:
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 -->
<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>
当您使用 Maven Shade 插件并使用 ServiceLoader
API 依赖项时,您应该使用 ServicesResourceTransformer
, which is dedicated to merge together the files. If the plugin is relocating classes,它也会正确地重新定位 class每个服务文件中的名称,与 AppendingTransformer
.
因此,您只需将当前的 AppendingTransformer
替换为
<transformer implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"/>
它将确保合并 META-INF/services
依赖项下的每个服务文件,而无需全部声明它们。