javax.el - Implementation of Glassfish

3

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'm going to use glassfish, but there are the following implementations:

org.glassfish (latest version):

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

E org.glassfish.web (latest version):

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

Is there a difference between the implementation of org.glassfish and org.glassfish.web , disregarding the version of both implementations?

    
asked by anonymous 17.04.2014 / 22:53

1 answer

2

For typical web applications

Use the implementation available on the application server.

If you are developing a web application to be published to GlassFish (or any other application server), you do not need an EL implementation, only the API (in scope provided ) . GlassFish itself will make the implementation available:

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

Do not forget the APIS endorsed (JAXB , JAX-WS JDBC APIs for the container , 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>

This is basically what the archetype webapp-javaee7 does.

Making the API out of the App Server

That said, your question makes sense if you need to make an EL implementation available along with your application. For example, if you are using an embedded container and want to make the Expression Language reference implementation available.

EL 3.0 / Java EE 7

For version 3.0 of EL use the following combination of dependencies:

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

GlassFish also maintains a project with standalone versions 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 / here is a tutorial ). Today both containers (Tomcat 8 / Jetty 9.1) already make EL 3.0 available.

Why are there different packages? Because the GlassFish developers have changed the convention for maven group names and artifacts.

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

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

18.04.2014 / 06:46