有处理 Java EE 和 java.endorsed.dirs 的最佳实践吗？

Question

我最近遇到了 glassfish 独立版 (v3.1) 与 glassfish 嵌入式版 (v3.1) 与 java SE 以及 java.endorsed.dirs 的使用方式的问题。我遇到的具体问题是 在这里，但我不认为这是我最后一次遇到类似的事情。

我在此处和此处建议添加glassfish 在编译时将库支持到引导类路径。但是，此错误报告表明，在使用时很难正确设置认可的库嵌入玻璃鱼。

因此，当我部署到独立的 glassfish 容器时，我的应用程序似乎将针对 glassfish 包含的认可库运行，但在使用嵌入式容器时则不会。我遇到了最初的问题，因为 maven-embedded-glassfish-plugin 不会像 glassfish 独立那样使用认可的库启动内嵌 glassfish。我也不确定其他容器（例如：jboss）是否包含与 glassfish 相同的一组认可库。

那么，我是否 (1) 应该努力（很多）确保我的应用程序是针对认可的库进行编译的，并始终部署到使用认可的库引导的容器中，或者我应该 (2) 只坚持使用捆绑的内容使用 Java SE 6？

如果我选择 (2)，在将应用程序部署到使用较新认可的库引导的容器时，我是否需要担心不兼容性？

我将不胜感激任何人都可以提供的任何见解。

Answer 1

编辑：上面的javaee-endorsed-api方法可能会很好地工作，但它让我感到不安。我认为它不再被生产或维护了。此外，它包含的 pom.xml 反映了它在某个时候被称为 javaee-compact-api，您可以看到他们如何从中剥离实现类。相比之下，挑选您想要使用的 API jar（正如我在下面推荐的那样）似乎更加稳定和灵活。最后，如果您仍然想使用javaee-endorsed-api方法，您仍然可以使用我推荐的通用方法并指向javaee-endorsed-api.jar 。

瑞安；我刚刚梳理了您在同一旅程中对此的长期跟踪（涉及 StackOverflow、java.net 论坛等）。

如您所知，在单元或集成测试期间，您需要设置 java.endorsed.dirs 系统属性。

诀窍是您必须以这样的方式执行此操作，以便运行测试的 JVM 能够识别它。这取决于 Surefire 的运行方式。

如果由于某种原因您将 Surefire 设置为而不 fork，这可能是一件坏事，您应该在此处重新评估您的配置。

如果您将 Surefire 设置为 fork，那么您可能会认为您可以简单地将 java.endorsed.dirs 包含在 systemPropertyVariables 节中，如下所示：

<systemPropertyVariables>
  <java.endorsed.dirs>weWillGetToThisInAMoment</java.endorsed.dirs>
</systemPropertyVariables>

...但这将是错误的。原因是实际运行的程序称为 ForkedBooter，并且 ForkedBooter 以编程方式为单元测试设置系统属性。也就是说，当 节被 ForkedBooter 读取时，已经太晚了。

但是你可以使用在 Surefire 配置中如下所示：

<configuration>
  <argLine>-Djava.endorsed.dirs=weWillGetToThisInAMoment</argLine>
</configuration>

现在，Surefire 分叉的 VM 将适当设置其认可目录。现在我们来谈谈要提供什么价值。

您想要挑选要覆盖的 API。就您而言，javax.annotation.* 是一个合法的选择。您想要提供本地 Maven 存储库中包含相关 jar 的目录。

以下是我使用的值：

${settings.localRepository}${file.separator}org${file.separator}glassfish${file.separator}main${file.separator}javaee-api${file-separator}javax.annotation${file.separator}${javaxAnnotationVersion}

• Maven 保证 ${settings.localRepository} 将扩展为本地 Maven 存储库所在位置的值。
• ${file.separator} 是一种在 Maven 属性替换中获取 System.getProperty("file.separator") 值的方法。
• 就我而言，我已经在 按照 Java 中的定义捆绑 javax.annotation 包的 GlassFish 工件EE 6。所以在这里我构建了一条通往工件的路径。我还定义了一个名为 javaxAnnotationVersion 的属性，对我来说，它设置为 3.1.2。

完成所有这些操作后，当 Surefire 分叉 VM 来运行单元测试时，认可的目录将设置为本地 Maven 存储库中的目录，其中包含包含 javax.annotation 类的 jar ，现在嵌入的 GlassFish（在进程中运行）将使用 Java EE 6 版本的 javax.annotation 类，而不是 Java SE 6 版本。我希望这对你有帮助。

Answer 2

我可能在这里遗漏了一些明显的东西，但是...GlassFish Embeded 不是附带与 Java EE 规范兼容的库吗？这些库不是默认加载的吗？ （如果不是，请在此处填写错误：http://java.net/jira/browse/ EMBEDDED_GLASSFISH）。

我的意思是：您应该针对 Java EE 规范 API 进行编译，并让容器使用它自己的实现。

对于第一部分，如果您使用 Maven，我喜欢 Codehaus archetypes 设置的方式认可的库。它既干净又与应用程序服务器无关：

<properties>
   <endorsed.dir>${project.build.directory}/endorsed</endorsed.dir>
   <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>

……

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>2.3.2</version>
    <configuration>
        <source>1.6</source>
        <target>1.6</target>
        <compilerArguments>
            <endorseddirs>${endorsed.dir}</endorseddirs>
        </compilerArguments>
    </configuration>
 </plugin>

这

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-dependency-plugin</artifactId>
    <version>2.1</version>
    <executions>
       <execution>
            <phase>validate</phase>
            <goals>
                <goal>copy</goal>
            </goals>
            <configuration>
                <outputDirectory>${endorsed.dir}</outputDirectory>
                <silent>true</silent>
                <artifactItems>
                    <artifactItem>
                        <groupId>javax</groupId>
                        <artifactId>javaee-endorsed-api</artifactId>
                        <version>6.0</version>
                        <type>jar</type>
                    </artifactItem>
                </artifactItems>
            </configuration>
        </execution>
    </executions>
</plugin>

几乎是您根据 Java EE 6 API 编译项目所需的全部内容。任何符合 Java EE 6 的应用程序服务器都应该提供这些服务，并且您不应该担心它们如何将其提供给您的应用程序。

引导 Java EE 服务的责任应该由您的应用服务器负责。如果您尝试自己的“内部”解决方案，JAR Hell 很可能会崩溃。

干杯，