× Please, log in to give us a feedback. Click here to login

You must be logged to download. Click here to login


MrBool is totally free and you can help us to help the Developers Community around the world

Yes, I'd like to help the MrBool and the Developers Community before download

No, I'd like to download without make the donation


MrBool is totally free and you can help us to help the Developers Community around the world

Yes, I'd like to help the MrBool and the Developers Community before download

No, I'd like to download without make the donation

Other characteristics - Whats new in GlassFish 3.1 - Part 3

Check out the new features of Oracles application server. In this article we present new features of version 3.1 of the GlassFish application server, such as clustering, versioning, scoped resources and the RESTful API - part 3.

2011.09 - GlassFish 3.1 - Vitor Souza - English v1-p03.doc

Application Versioning

  Another novelty of GlassFish 3.1 is the ability of deploying the same application on the server multiple times, adding tags that indicate the version of each deployment and, later, specify which version of the application should be active.

  To demonstrate this functionality, the HelloGlassFish application that was created at the beginning of the article (to test the integration with NetBeans and Eclipse) will be used. However, we will perform the deployment using asadmin, not the IDE. To do so, we will need the HelloGlassFish.ear file containing the packaged enterprise application. If you use NetBeans, just perform a full build of  the application (Run > Build project) and this file will be found under the dist folder in your project directory. In case you use Eclipse, right-click the HelloGlassFish project and select Export > EAR.

  First, and in case it has not already been done, perform a normal deploy of the application with the following command:

asadmin deploy HelloGlassFish.ear

  Then, if you open the application in your browser by visiting the URL http://localhost:8080/HelloGlassFish-war/ the “Hello, World!” message will be displayed, as before. Moreover, it is possible to see that the application has been deployed on the server with the subcommand list-applications (# represents the terminal/command prompt)

# asadmin list-applications

HelloGlassFish  <ear, web>

  Now, using the IDE of your choice, make a change in the index.jsp page of the example application, changing the “Hello, World!” message to “Hello, World 2.0 Beta!”. Then, generate the EAR package and deploy the application on GlassFish again, but this time marking it with the tag BETA-2.0, indicating its version:

asadmin deploy --name=HelloGlassFish:BETA-2.0 HelloGlassFish.ear

  The subcommand list-application will show, now, both deployed versions:

# asadmin list-applications

HelloGlassFish           <ear, web>  

HelloGlassFish:BETA-2.0  <ear, web>  

  Open the application in your browser and you will now see that the text “2.0 Beta” was added to the message that was previously shown. This happens because the new deployed deployed version was automatically activated. Using the subcommand show-component-status it is possible to see which is the active version of a deployed application:

# asadmin show-component-status HelloGlassFish:*

  Status of HelloGlassFish is disabled.


  Status of HelloGlassFish:BETA-2.0 is enabled.

  It is also possible to deploy a version of an application and not activate it automatically. To do so, change again the message in index.jsp to say “2.1 Beta” instead and, when deploying, specify that the new version should not be activated, this way:

asadmin deploy --name=HelloGlassFish:BETA-2.1 --enabled=false HelloGlassFish.ear

  Using the show-component-status subcommand again you will see that the BETA-2.0 version is still active and if you refresh the page in your browser the 2.0 message will still be displayed. To activate the 2.1 version use another subcommand of asadmin:

asadmin enable HelloGlassFish:BETA-2.1

  Finally, removing an application from GlassFish with the undeploy subcommand also follows the same rules for tags, accepting * as a wildcard. Therefore, to remove all BETA versions of the server, use the follow command (note that this does not automatically enable the original version and if you want to do so you have to use asadmin enable HelloGlassFish):

asadmin undeploy HelloGlassFish:BETA*

  Application versioning is a good practice when it comes to make modifications in applications that are already in production, because it allows for quickly restoring the previous version in case errors are found in the most recent one. It is also useful for applications still at the test phase so you can experiment with some new functionality temporarily and quickly go back to the previous version with a single command.

Application-scoped Resources

  A Java EE application deals with many external resources, as JDBC connections, JMS queues, JavaMail resources, etc. Such resources should be registered in the application server and then can be obtained via a JNDI lookup or CDI dependency injection.

  Up to version 3.0 of GlassFish, all resources had to be registered via asadmin or administration console and would automatically have global scope, meaning that any application deployed in the server could access them. Version 3.1 of GlassFish now allows for the registration of resources with application or module scope, bringing the following advantages:

  1. The resource is available only to a specific application, preventing other applications that should not have access to it to do so;
  2. The resource is automatically registered within GlassFish when the application is deployed and removed when the application is undeployed, allowing for “single click deploys”.

  To demonstrate the feature we will use the same project as before (HelloGlassFish), to which we will add a JDBC resource. To create this resource you need first to create a database in any Database Management System (DBMS) installed in your system. Instructions for this are out of the scope of this article, but if you use NetBeans you can open the Services tab, right-click Databases > Java DB and select Create Database.... In the following examples we assume a database called hello with user hello and password hello have been created.

  To add a resource to an application it is enough to describe it in a file called glassfish-resources.xml (which should follow a predefined syntax) and place it under one of the following places:

  1. Placing it under the META-INF folder of the EAR package, the resource will have application scope and will be accessible to any of its modules;
  2. Placing it under the META-INF folder of the JAR package that contains the EJB module, the resource will have module scope, being accessible only within the EJB module;
  3. Placing it under the WEB-INF folder in the WAR package that contains the Web module, the resource will have module scope, being accessible only within the Web module.

  To try this feature, create the glassfish-resources.xml file with the contents of Listing 1 and add it to the WEB-INF folder of the HelloGlassFish-war project (HelloGlassFishWeb in Eclipse). Then change the index.jsp page, adding the piece of code shown in Listing 2. Deploy the application and open the JSP page to see that under the “Hello, World!” message the result of the toString() method on the java.sql.DataSource object that represents the registered JDBC resource will be shown (something like com.sun.gjc.spi.jdbc40.DataSource40@e65575).

Listing  1. The file glassfish-resources.xml, configuring a module-scoped JDBC resource.

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE resources PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Resource Definitions//EN" "http://glassfish.org/dtds/glassfish-resources_1_5.dtd">


  <jdbc-resource enabled="true" jndi-name="java:module/jdbc/helloDS" object-type="user" pool-name="helloPool" />

  <jdbc-connection-pool datasource-classname="org.apache.derby.jdbc.ClientDataSource" max-pool-size="32" name="helloPool" pool-resize-quantity="2" res-type="javax.sql.DataSource">

    <property name="URL" value="jdbc:derby://localhost:1527/hello"/>

    <property name="serverName" value="localhost"/>

    <property name="PortNumber" value="1527"/>

    <property name="DatabaseName" value="hello"/>

    <property name="User" value="hello"/>

    <property name="Password" value="hello"/>



Listing 2. Piece of code for a JSP page that accesses the JDBC resource registered to the Web module.


javax.naming.InitialContext ic = new javax.naming.InitialContext();

Object ds = ic.lookup("java:module/jdbc/helloDS");


<p><%= ds %></p>

  The glassfish-resources.xml file registers a connection pool and a data source the same way they used to be registered in the global scope. The only difference, written in boldface in Listing 1, is the name given to the resource that the application has to lookup. Such name is due to a convention that says that it should start with java:module/ for module-scoped resources and java:app/ for application-scoped ones.

Both Eclipse and NetBeans have wizards for the creation of resources in the glassfish-resources.xml file. In Eclipse, right-click the project, select New > Other... and find the wizards inside the GlassFish folder. In NetBeans the procedure is almost identical: right-click the project, select New > Other... and choose the GlassFish category. Just pay attention where the IDE will put the file. If it is not in the desired folder (as explained above), move it to the correct position.

  With the registered resource, the index.jsp page can look it up using JNDI with the name that was previously declared. Then, the example prints the object in the page just to test that indeed a JDBC data source has being registered. Note that accessing data sources directly from JSP pages is not a good development practice and was done in the example just to test GlassFish's ability to automatically register the module-scoped resource. In a real application, we suggest the use of CDI to inject the resource in one of the application's beans, using, for instance, the annotation @Resource(lookup = "java:module/jdbc/helloDS").

  Application and module-scoped resources are very useful when the access to any given resource should be, indeed, restricted to one of these two scopes. In this case, not registering the resource as global in the server avoids that other applications and modules gain access to them and possibly create racing conditions. Moreover, this new functionality makes it more practical to deploy applications, as the resources are automatically registered in the server and we do not have to do it manually.

RESTful API for Administration

  REST stands for Representational State Transfer and is a software architectural style for hypermedia systems (for instance, Web applications). It consists on a client and a server that communicate by means of requests and responses, transferring in such communications the representations of the states of the objects (or, more generally, resources) that are being manipulated.

  In the past few years the use of RESTful Web Services has grown as an alternative to the W3C standard SOAP, because of its lightweight and fast communication with the server, using XML, JSON or any other standard for state representation. We can perceive this growth by observing the creation of new frameworks to help the development of clients and servers that use this technology. One example of this type of framework is Restfulie (see Links).

  Following this trend, GlassFish 3.1 makes its administration functions available not only through the terminal (the asadmin tool) and a Web interface (the administration console), but also via a RESTful API (meaning an API that conforms to the REST architecture). This API allows that any client can read and make changes to the server configurations in a request-response fashion.

  The base address of GlassFish's RESTful API is http://localhost:4848/management/domain/. If this URL is opened in a Web browser, an HTTP request will be made to the RESTful API and it will respond with an HTML document that shows the configuration elements. Attributes are shown in forms and their values can be changed and updated. Child resources are shown at the end of the page, which allows us to navigate to other configuration elements.

  Figure 1 shows a browser accessing a specific configuration elements: the configurations of the HelloGlassFish application, which was currently deployed at the server. To reach this screen from the base URL, click on the child resources applications > application > HelloGlassFish (which, not surprisingly, are the same elements that are added to the base URL to assemble the URL of this specific element).

Figure 1. Accessing the RESTful API of GlassFish through a Web browser.

The usefulness of a RESTful API, however, is not to provide a less user-friendly Web interface (if compared to the administration console), but to allow other types of clients to be developed with easier access to the configuration values of the server. To demonstrate how this is possible, we will use a simple tool that allows us to send REST requests to a server: cURL. In Linux and Mac systems this tool is usually already present. In case you need to install it in your system, just download it from their project website (see Links).

Using cURL we can read the configuration of our deployed application (the same information that is shown in the Web page of Figure 1), but in JSON format. Later, we can parse this result to reach the desired information. To obtain the information in JSON format, use cURL the following way:

curl -s -H "Accept: application/json" http://localhost:4848/management/domain/applications/application/HelloGlassFish

A huge amount of data will be shown in a format that is difficult to read for a person (unless you format it using some pretty printing solution), but easy to read for a machine. If we want, for instance, to see if the application is enabled, we can obtain the JSON object extraProperties, inside look for the object called entity and finally access the property enabled. Using JSON-java (one of the many JSON parser implementations in Java – see Links), the code of Listing 3 performs this navigation and prints the value of the enabled property.

Listing 3. Java program that reads the result of the curl command and prints the enabled property.

package json;

import java.util.Scanner;

import org.json.JSONObject;

public class JsonParserTest {

        public static void main(String[] args) throws Exception {

                Scanner scanner = new Scanner(System.in);

                String line = scanner.nextLine();

                Object enabled = jsonObj.getJSONObject("extraProperties").getJSONObject("entity").get("enabled");




The program of Listing 3 expects that the JSON string is passed to System.in. For that to happen, combine cURL with the Java program using the following command (all in one single line):

curl -s -H "Accept: application/json" http://localhost:4848/management/domain/applications/application/HelloGlassFish | java json.TesteParserJson

We can use cURL also to modify configuration data through the RESTful API. To change the enabled property to false, use the following command:

curl -F enabled=true http://localhost:4848/management/domain/applications/application/HelloGlassFish

After executing it, open the URL  http://localhost:4848/management/domain/applications/application/HelloGlassFish in your Web browser and check that the value of the property has been changed and the application is now disabled. In effect, if you try to access it by visiting http://localhost:8080/HelloGlassFish-war/ you will find a 404 (“resource not found”) error.


This article has presented the new features of version 3.1 of GlassFish, a server for enterprise applications in Java EE 6. In particular, four features were described in more detail and with examples to experiment with them: cluster management, application versioning, application-scoped resources and RESTful administration API.

At each new version, tools that we use for software development bring new features that facilitate the job of the developer or improve the final result of the application. We hope that this article helps you keep up-to-date with the novelties of GlassFish and encourages you to experiment with them, possibly using them in your work or personal projects.

To see the second part, access: http://mrbool.com/p/Clustering-Whats-new-in-GlassFish-3-1-Part-2/22712



Download page for GlassFish 3.1.


Download page for the NetBeans IDE.


Download page for the Eclipse IDE.


GlassFish documentation about remote management via SSH.


Example application for testing clusters, obtained from GlassFish 2 and published in the blog of Arun Gupta.


Instructions for the configuration of load balancing on GlassFish using Apache and mod-jk.


Framework for the implementation of RESTful services and clients.


Download page for the cURL tool.


Source-code of the JSON-java parser.

Columnist not avaible

What did you think of this post?
To have full access to this post (or download the associated files) you must have MrBool Credits.

  See the prices for this post in Mr.Bool Credits System below:

Individually – in this case the price for this post is US$ 0,00 (Buy it now)
in this case you will buy only this video by paying the full price with no discount.

Package of 10 credits - in this case the price for this post is US$ 0,00
This subscription is ideal if you want to download few videos. In this plan you will receive a discount of 50% in each video. Subscribe for this package!

Package of 50 credits – in this case the price for this post is US$ 0,00
This subscription is ideal if you want to download several videos. In this plan you will receive a discount of 83% in each video. Subscribe for this package!

> More info about MrBool Credits
You must be logged to download.

Click here to login