AWS Lambda using incorrect classfiles from a Multi-Release JAR?(AWS Lambda使用来自多版本JAR的不正确类文件?)
问题描述
我有一个lambda在Java 8下运行了几年,我刚刚把它更新到Java 11。它立即坏了,给我这样的错误:
Caused by: java.lang.ExceptionInInitializerError
at com.mycompany.rest.providers.JsonProvider.writeTo(JsonProvider.java:80)
at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.invokeWriteTo(WriterInterceptorExecutor.java:242)
at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.aroundWriteTo(WriterInterceptorExecutor.java:227)
at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:139)
at org.glassfish.jersey.message.internal.MessageBodyFactory.writeTo(MessageBodyFactory.java:1116)
at org.glassfish.jersey.client.ClientRequest.doWriteEntity(ClientRequest.java:461)
at org.glassfish.jersey.client.ClientRequest.writeEntity(ClientRequest.java:443)
at org.glassfish.jersey.client.internal.HttpUrlConnector._apply(HttpUrlConnector.java:367)
at org.glassfish.jersey.client.internal.HttpUrlConnector.apply(HttpUrlConnector.java:265)
at org.glassfish.jersey.client.ClientRuntime.invoke(ClientRuntime.java:297)
... 15 more
Caused by: java.lang.UnsupportedOperationException: No class provided, and an appropriate one cannot be found.
at org.apache.logging.log4j.LogManager.callerClass(LogManager.java:571)
at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:596)
at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:583)
at com.mycompany.rest.util.NonClosingOutputStream.<clinit>(NonClosingOutputStream.java:11)
... 25 more
这个类并不特别令人兴奋,它有一个简单的静态初始化,这在我的类中很常见:
public class NonClosingOutputStream extends ProxyOutputStream {
private static final Logger log = LogManager.getLogger(); // Line 11
public NonClosingOutputStream(final OutputStream proxy) {
super(proxy);
}
...
我以前遇到过这样的问题,当我将我的(非Lambda)Java服务器从8切换到11时;我需要将JAR的清单标记为Multi-Release: true
,因为我所依赖的ApacheLog4j构件为Java 8和9+中的org.apache.logging.log4j.util.StackLocator
类提供了替代实现。然而,我有点希望JVM只选择类的适当版本。是否有我必须在某个地方设置的配置?是否可能在某处将我的Lambda从Java 8->;Java 11切换为混淆了?
jar/META-INF/versions:
versions/
├── 11
│ └── org
│ └── glassfish
│ └── jersey
│ └── internal
│ └── jsr166
│ ├── JerseyFlowSubscriber$1.class
│ ├── JerseyFlowSubscriber.class
│ ├── SubmissionPublisher$1.class
│ ├── SubmissionPublisher$2.class
│ ├── SubmissionPublisher$3.class
│ ├── SubmissionPublisher$4.class
│ ├── SubmissionPublisher$5.class
│ ├── SubmissionPublisher$6.class
│ ├── SubmissionPublisher.class
│ └── SubmissionPublisherFactory.class
└── 9
├── module-info.class
└── org
└── apache
└── logging
└── log4j
├── core
│ └── util
│ └── SystemClock.class
└── util
├── Base64Util.class
├── ProcessIdUtil.class
├── StackLocator.class
└── internal
└── DefaultObjectInputFilter.class
编辑:我发现some references表明,当AWS Lambda提取JAR时,他们不会提取META-INF目录,该目录包含MANIFEST.MF文件,该文件告诉JVM该JAR是多版本JAR。Lambda是否支持多版本JAR?
推荐答案
不完全是您问题的答案,但我希望这可能会有帮助。
您的分析是正确的-AWS lambda提取整个JAR文件。然后,运行lambda函数的JVM不再将代码识别为JAR文件,并且实际上会忽略整个META-INF目录。在我的例子中,我使用maven-shade-plugin
创建了一个包含lambda函数的所有依赖项的&uber";-jar。official AWS documentation中推荐使用这种方法。
现在--这一点很重要--maven-shade-plugin
提取所有JAR文件依赖项,并将它们重新打包到单个平面JAR文件中。如果您的一个依赖项是多版本JAR(就像log4j2一样),那么您可以配置maven-shade-plugin
以重新构建适当的META-INF目录,如果您将JAR作为JAR文件运行,那么一切仍然正常。
但是,因为AWS Lambda提取JAR,所以JVM不再看到META-INF目录,并且META-INF/版本中的任何内容都将被忽略。
要解决这个问题,我切换到maven-assembly-plugin
。它允许使用lambda的代码创建ZIP文件,并将依赖项添加为JAR文件。现在,当AWS Lambda解压缩此ZIP文件时,JAR保持完好,一切工作正常。
要进行配置,请创建一个文件assembly.xml
,如下所示:
<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2 http://maven.apache.org/xsd/assembly-1.1.2.xsd">
<id>zip</id>
<!-- Make sure the ZIP contents are not nested in a subdirectory -->
<includeBaseDirectory>false</includeBaseDirectory>
<formats>
<format>zip</format>
</formats>
<fileSets>
<fileSet>
<directory>${project.basedir}/conf</directory>
</fileSet>
<!-- Include the compiled classes as-is and put them in the root of the ZIP -->
<fileSet>
<directory>${project.build.directory}/classes</directory>
<outputDirectory>/</outputDirectory>
</fileSet>
</fileSets>
<dependencySets>
<!-- Include all dependencies in the lib/ directory -->
<dependencySet>
<outputDirectory>lib</outputDirectory>
<excludes>
<exclude>${project.groupId}:${project.artifactId}:jar:*</exclude>
</excludes>
</dependencySet>
</dependencySets>
</assembly>
然后您需要在pom.xml
中配置maven-assembly-plugin
:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<version>3.3.0</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
<configuration>
<appendAssemblyId>false</appendAssemblyId>
<descriptors>
<descriptor>assembly.xml</descriptor>
</descriptors>
<finalName>${project.artifactId}</finalName>
</configuration>
</execution>
</executions>
</plugin>
现在,只需像往常一样将生成的压缩文件部署到AWS Lambda,就可以了!
作为备注-阴影JAR文件包含数千个单独的.class
文件,而汇编的ZIP文件只包含少数几个JAR文件。即使总体大小(以字节为单位)更大,文件的数量也会少得多,从而减少冷启动时间。我还没有在AWS Cloud上测试过这一点,但在我的LocalStack上,冷启动时间从大约1分钟降到了6秒--这绝对是一个很好的开发助推器。
这篇关于AWS Lambda使用来自多版本JAR的不正确类文件?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持编程学习网!
本文标题为:AWS Lambda使用来自多版本JAR的不正确类文件?
基础教程推荐
- 如何强制对超级方法进行多态调用? 2022-01-01
- 如何对 HashSet 进行排序? 2022-01-01
- 如何使用 Eclipse 检查调试符号状态? 2022-01-01
- 首次使用 Hadoop,MapReduce Job 不运行 Reduce Phase 2022-01-01
- 如何使用 Stream 在集合中拆分奇数和偶数以及两者的总和 2022-01-01
- Spring Boot Freemarker从2.2.0升级失败 2022-01-01
- 如何在不安装整个 WTP 包的情况下将 Tomcat 8 添加到 Eclipse Kepler 2022-01-01
- 由于对所需库 rt.jar 的限制,对类的访问限制? 2022-01-01
- 在螺旋中写一个字符串 2022-01-01
- Java 中保存最后 N 个元素的大小受限队列 2022-01-01