处理Java EE和java.endorsed.dirs的最佳实践？ [英] Any best practices for dealing with Java EE and java.endorsed.dirs?

问题描述

最近我遇到了glassfish standalone（v3.1）vs glassfish embedded（v3.1）vs java SE以及使用java.endorsed.dirs的问题。我遇到的具体问题是这里，但我不认为这是我最后一次碰到类似的东西。

我发现的信息这里和这里建议在编译时将glassfish批注的库添加到引导类路径中。但是，这个错误报告表明，使用时很难正确设置背书库因此，当我部署到独立的glassfish容器时，我的应用程序将运行在glassfish包含的已认可的库上，但在使用嵌入式它不会的容器。我遇到了我原来的问题，因为maven-embedded-glassfish-plugin没有使用像glassfish standalone这样的背书库来启动glassfish。我也不确定其他容器（例如：jboss）是否包含与glassfish相同的背书库。

那么，我（1）是否应该奋斗（一个很多），以确保我的应用程序是针对已批准的库进行编译的，并且始终将其部署到使用已认可的库进行引导的容器，或者我应该坚持使用与Java SE 6捆绑在一起的内容吗？

如果我选择（2），将我的应用程序部署到使用更新的背书库启动的容器时，我是否会担心不兼容？

<我很感激任何人都可以提供的见解。

解决方案

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

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

对于第一部分，如果您使用Maven，我喜欢 Codehaus原型设置认可的库。它既是干净的，也是Application Server不可知论者：

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

...

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

...

 <插件> 
< groupId> org.apache.maven.plugins< / groupId> 
< artifactId> maven-dependency-plugin< / artifactId> 
< version> 2.1< / version> 
<执行次数> 
<执行> 
<阶段>验证< /阶段> 
<目标> 
< goal>复制< / goal> 
< /目标> 
<配置> 
< 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> 
< /执行> 
< /执行次数> 
< / plugin> 
  

这几乎是您根据Java EE 6 API编译项目所需的全部内容。任何符合Java EE 6标准的App Server都应该提供这些服务，您不应该担心它们如何让您的应用程序可用。

引导Java EE服务应该是你的应用服务器。如果你尝试自己的内部解决方案，那么JAR Hell可能会失败。

干杯，

I've recently run into a problem with glassfish standalone (v3.1) vs glassfish embedded (v3.1) vs java SE and the way java.endorsed.dirs is used. The specific problem I had is here, but I don't think it's the last time I'm going to run into something similar.

The information I found here and here suggests adding the glassfish endorsed libs to the bootstrap classpath when compiling. However, this bug report suggests it is difficult to get the endorsed libs set correctly when using glassfish embedded.

So, it seems like when I deploy to a standalone glassfish container my application is going to run against the endorsed libs that glassfish includes, but when using the embedded container it won't. I encountered my original problem because the maven-embedded-glassfish-plugin doesn't start glassfish embedded using the endorsed libs like glassfish standalone does. I'm also unsure whether other containers (ex: jboss) include the same set of endorsed libs as glassfish.

So, am I (1)supposed to struggle (a lot) to make sure my application is compiled against the endorsed libs and always deployed to a container that is bootstrapped using the endorsed libs or should I (2)just stick to using what's bundled with Java SE 6?

If I choose (2), will I have to worry about incompatibilities when deploying my application to a container that is bootstrapped with newer endorsed libs?

I would appreciate any insight that anyone can offer.

解决方案

I may be missing something obvious here but... Isn't GlassFish Embbeded shipped with libraries compatible with the Java EE specs? And aren't those libraries loaded by default? (If they aren't, please fill a bug here: http://java.net/jira/browse/EMBEDDED_GLASSFISH).

What I mean is: You should compile against Java EE spec APIs, and just let the container use it's own implementations.

For the first part, if you use Maven, I like the way Codehaus archetypes sets the endorsed libs. It is both clean and Application Server Agnostic:

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

Which is pretty much all you need to compile your projects against Java EE 6 APIs. Any Java EE 6 compliant App Server should provide those services, and you shouldn't be worried about how they are making it available to your application.

The responsibility of bootstrapping Java EE Services should be of your App Server. If you try your own "in house" solution, chances are that JAR Hell will break loose.

Cheers,

这篇关于处理Java EE和java.endorsed.dirs的最佳实践？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！