javax.el - Implementation of Glassfish

Question

There is a JSR-000341(Expression Language - EL) API in version 3.0.0.

Maven dependency on the javax.el API:

<dependency>
    <groupId>javax.el</groupId>
    <artifactId>javax.el-api</artifactId>
    <version>3.0.0</version>
</dependency>

But as for the implementation I will use the glassfish one, but there are the following implementations:

Of org.glassfish (latest version):

<dependency>
    <groupId>org.glassfish</groupId>
    <artifactId>javax.el</artifactId>
    <version>3.0.0</version>
</dependency>

And org.glassfish.web (latest version):

<dependency>
    <groupId>org.glassfish.web</groupId>
    <artifactId>javax.el</artifactId>
    <version>2.2.6</version>
</dependency>

There is some difference between the implementation of org.glassfish and org.glassfish.web, disregarding the version of the two implementations?

Answer 1

For typical web applications

Use the available implementation on the application server.

If you are developing a web application to be published on Glassfish (or any other application server), you nay needs an EL implementation, only the API (in scope provided). Glassfish itself will provide the implementation:

<dependency>
    <groupId>javax.el</groupId>
    <artifactId>javax.el-api</artifactId>
    <version>3.0.0</version>
    <scope>provided</scope>
</dependency>

In practice however we hardly include a dependency for this API directly, we usually work at a higher granularity level. Web applications are consumers of major Java EE Apis (including Servlets, JSP, JSF, Expression Language, etc.):

<dependency>  
   <groupId>javax</groupId>    
    <artifactId>javaee-web-api</artifactId> <!-- Ou javaee-api se realmente precisar -->   
    <version>7.0</version>  
    <scope>provided</scope>
</dependency> 

Don’t forget the APIS either endorsed, that is, updates to JDK necessary for the container (especially relevant to JAXB, JAX-WS, etc.):

<properties>
    <endorsed.dir>${project.build.directory}/endorsed</endorsed.dir>
</properties>

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.1</version>
            <configuration>
                <compilerArguments>
                    <endorseddirs>${endorsed.dir}</endorseddirs>
                </compilerArguments>
            </configuration>
        </plugin>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-dependency-plugin</artifactId>
            <version>2.6</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>7.0</version>
                                <type>jar</type>
                            </artifactItem>
                        </artifactItems>
                    </configuration>
                </execution>
            </executions>
        </plugin>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-war-plugin</artifactId>
            <version>2.3</version>
            <configuration>
                <failOnMissingWebXml>false</failOnMissingWebXml>
            </configuration>
        </plugin>
        <!-- Demais plugins -->
    </plugins>
</build>

Et voilà:

<!-- Lambda dentro de uma EL, não fica mais legal que isso --> 
<h1>Hello World! ${((x, y) -> x + y)(3, 4)}</h1>

That’s basically what the archetype webapp-javaee7 ago.

---

Providing the API outside the App Server

That said, your question makes sense if you need to provide an EL implementation along with your application. For example, if you are using a Embedded container and to make available the reference implementation (ROI) of Expression Language.

EL 3.0 / Java EE 7

For EL version 3.0 use the following dependency combination:

<!-- API -->
<dependency>
    <groupId>javax.el</groupId>
    <artifactId>javax.el-api</artifactId>
    <version>3.0.0</version>                
</dependency>
<!-- Implementação -->
<dependency>
    <groupId>org.glassfish</groupId>
    <artifactId>javax.el</artifactId>
    <version>3.0.0</version>
    <scope>runtime</scope>
</dependency>

EL 2.2 / Java EE 6

The Glassfish also maintains a project with versions standalone of EL 2.2.x:

<!-- API -->
<dependency>
    <groupId>javax.el</groupId>
    <artifactId>javax.el-api</artifactId>
    <version>2.2.5</version>
</dependency>
<!-- Implementação -->
<dependency>
    <groupId>org.glassfish.web</groupId>
    <artifactId>javax.el</artifactId>
    <version>2.2.5</version>
    <scope>runtime</scope>
</dependency>

At the time of Tomcat 6 / Jetty 6 this type of arrangement was common to enable EL 2.2 (here’s a tutorial). Today both of them containers (Tomcat 8 / Jetty 9.1) already available EL 3.0.

---

Why are there different packages? Glassfish developers have changed the convention to Maven group names and artifacts.

• In Glassfish version 3.x artifacts related to web development were grouped into org.glassfish.web.
• In version 4.x the artifacts were regrouped into org.glassfish (that is, you will find recent versions of the implementations in this group). Artifact names have also been rethought to match the service root package they implement.

Coincidentally the JSR 341 (EL 3.0) was the first separate specification of the Expression Language. Version 2.2 of the API was part of JSR 245 (Javaserver Pages).