Skip to main content

How to use GlassFish application versioning

Posted by serli on August 30, 2010 at 12:39 PM PDT

Few weeks ago, a new “awesome” feature made appearence in the GlassFish Milestone 1. This feature, the “Application versioning”, aims to help you deal with the multiple versions of your Java EE applications in a simple and easy way with the usual GlassFish administration commands.

This feature allows users to deploy multiple versions of the same application in a GlassFish server at runtime with only one version enabled at a time. The application versioning provides a full set of commands to interact with the versions of an application naturally integrated in existing CLI commands.

The “versions” of an application can be pretty much anything because a version is really just a qualifier so you can use you maven version identifiers for instance (SNAPSHOT, BETA, etc ... ) or anything you want as version. Also there is no notion of “version sequence” so you can easily switch to any version from any other (actually GlassFish deals with a version like it’s an individual application).

And now, a little user story. To present how to use application versioning, let me introduce Robert

 

Robert is a Java EE developer and a GlassFish enthousiast since long time. Robert uses GlassFish on his laptop, on a “Continuous Build” server and on the production server. Right now, Robert is writting a very cool Java EE application, called “Foo”, and hopes to become rich with it.

After writing some GUI code, Robert decides to deploy the “foo” application on his laptop like this :

$ asadmin deploy foo.war

The deployed applications are :

$ asadmin list-applications
[prettify]foo <web>

at this point, the application is pretty basic and looks like this

during the development Robert uses the force option the redeploy “Foo”. For instance after replacing the JPS with a servlet :

 $ asadmin deploy --force=true foo.war 

The deployed applications are :

 $ asadmin list-applications  
foo <web>

Now let's use some cool Java EE stuff. After spending hours on the code, Robert thinks it’s time for a beta version. So he deploys the BETA-1.0 version on GlassFish

 $ asadmin deploy --name=foo:BETA-1.0 foo.war 

The deployed applications are :

 $ asadmin list-applications  
foo <web>
foo:BETA-1.0 <web>

You can notice here the versioning syntax used in the  command to create a BETA-1.0 version of the “Foo” application. Basically the syntax is used in the  --name option and is composed with the name of the app. and the identifier of the version separated by a column charater.

--name=application_name:version_identifier[/prettify]

It’s now time for a second BETA version. Robert wants to deploy it, but in a disable state because he has to check some things in the previous version. To do that he uses the following command

$ asadmin deploy --name=foo:BETA-1.1 --enable=false foo.war

The deployed applications are :

$ asadmin list-applications
[prettify]foo <web>

foo:BETA-1.0 <web>
foo:BETA-1.1 <ejb, web>

as you can see, the version is deployed, but the previous version is still active.

Now to enable the BETA-1.1 version, Robert uses the command :

 $ asadmin enable foo:BETA-1.1 

After some more lines of code, Robert thinks “It’s time for a new version !” and decides to publish a Release Candidate of the “Foo” application. To deploy it, Robert uses the command :

 $ asadmin deploy --name=foo:RC-1.0 foo.war 

The deployed applications are :

 $ asadmin list-applications  
foo <web>
foo:BETA-1.0 <web>
foo:BETA-1.1 <ejb, web>
foo:RC-1.0 <ejb, web>

This new Release Candidate version looks like this

Now with this new RC-1.0 version, BETA versions are useless to Robert. To undeploy all these versions, Robert uses what we call a “version expression” to handle multiple versions in a single undeploy command.

 $ asadmin undeploy foo:BETA-* 

The deployed applications are :

 $ asadmin list-applications  
foo <web>
foo:RC-1.0 <ejb, web>

 

Unfortunally for Robert, the “Foo corporation” company just release a first version of a similar application called “Magic Foo”. Naturally Robert wants to give it a try, download the app. and deploys it on GlassFish to find out that “Magic Foo” is way better than “Foo”

 $ asadmin undeploy foo:*  
$ asadmin deploy magicFOO.war [/prettify]

 

 

You can find the code of the “foo” application here.

The entire documentation of GlassFish versioning is available on the GlassFish wiki at http://wiki.glassfish.java.net/Wiki.jsp?page=ApplicationVersionings

You can see a screencast of the “Application versioning” feature on Alexis blog at

http://blogs.sun.com/alexismp/entry/glassfish_3_1_milestone_1

You can also try the feature by yourself with the latest GlassFish promoted build

 

Mathieu ANCELIN

SERLI Team




 

Related Topics >>

Comments

Thanks SERLI :)

    Very cool article, thanks a lot :)
Nevertheless, I'm wondering what's the best solution if we need to keep active more than one version of the same application. I'd like some people to work on a specific version, and other people to work on another one. We could need maybe a dozen of simultaneous working versions. The only solution I've found today is to install as many glassfish servers as many simultaneous versions I need ; I'm not sure the performances and memory are optimized with this kind of configuration.

Do somebody have a suggestion with it ?

Why hasn't anyone though of this before?

What a great idea. This seems ideal for staging a code fix release onto a production system (... assuming all the dependences match - like the DB schemas).

I am assuming that the disabled versions of the app have started up and run concurrently with the enabled one, and we could just switch over at the drop of a hat.

All it needs now is some way to test the new version, before it is enabled.