Question

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.

Answer 1

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,