serli's Blog

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 &lt;web&gt; </pre> <p>at this point, the application is pretty basic and looks like this</p> <p><img alt="" src="http://www.java.net/sites/default/files/untagged-half.png" /></p> <p>during the development Robert uses the force option the redeploy &ldquo;Foo&rdquo;. For instance after replacing the JPS with a servlet :</p> <pre> $ asadmin deploy --force=true foo.war </pre> <p>The deployed applications are :</p> <pre> $ asadmin list-applications
foo &lt;web&gt; </pre> <p><img alt="" src="http://www.java.net/sites/default/files/untagged-force-half.png" /></p> <p>Now let's use some cool Java EE stuff. After spending hours on the code, Robert thinks it&rsquo;s time for a beta version. So he deploys the <span class="caps">BETA</span>-1.0 version on GlassFish</p> <pre> $ asadmin deploy --name=foo:BETA-1.0 foo.war </pre> <p>The deployed applications are :</p> <pre> $ asadmin list-applications
foo &lt;web&gt;
foo:BETA-1.0 &lt;web&gt; </pre> <p>You can notice here the versioning syntax used in the  command to create a <span class="caps">BETA</span>-1.0 version of the &ldquo;Foo&rdquo; application. Basically the syntax is used in the  <code> --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 &lt;ejb, web&gt; </pre>
<p>as you can see, the version is deployed, but the previous version is still active.</p>
<p><img alt="" src="http://www.java.net/sites/default/files/beta-1-half.png" /></p>
<p>Now to enable the BETA-1.1 version, Robert uses the command :</p>
<pre> $ asadmin enable foo:BETA-1.1 </pre>
<p><img alt="" src="http://www.java.net/sites/default/files/beta-1.1-half.png" /></p>
<p>After some more lines of code, Robert thinks &ldquo;It&rsquo;s time for a new version !&rdquo; and decides to publish a Release Candidate of the &ldquo;Foo&rdquo; application. To deploy it, Robert uses the command&nbsp;:</p>
<meta charset="utf-8">
<meta charset="utf-8">
<meta charset="utf-8">
<pre> $ asadmin deploy --name=foo:RC-1.0 foo.war </pre>
<p>The deployed applications are :</p>
<pre> $ asadmin list-applications  
 foo &lt;web&gt;  
 foo:BETA-1.0 &lt;web&gt;  
 foo:BETA-1.1 &lt;ejb, web&gt;  
 foo:RC-1.0 &lt;ejb, web&gt; </pre>
<p>This new Release Candidate version looks like this</p>
<p><img alt="" src="http://www.java.net/sites/default/files/rc-1-half.png" /></p>
<p>Now with this new RC-1.0 version, <span class="caps">BETA</span> versions are useless to Robert. To undeploy all these versions, Robert uses what we call a &ldquo;version expression&rdquo; to handle multiple versions in a single undeploy command.</p>
<meta charset="utf-8">
<pre> $ asadmin undeploy foo:BETA-* </pre>
<p>The deployed applications are :</p>
<pre> $ asadmin list-applications  
 foo &lt;web&gt;  
 foo:RC-1.0 &lt;ejb, web&gt; </pre>
<p>&nbsp;</p>
<p>Unfortunally for Robert, the &ldquo;Foo corporation&rdquo; company just release a first version of a similar application called &ldquo;Magic Foo&rdquo;. Naturally Robert wants to give it a try, download the app. and deploys it on GlassFish to find out that &ldquo;Magic Foo&rdquo; is way better than &ldquo;Foo&rdquo;</p>
<pre> $ 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