Over a million developers have joined DZone.

Migrating an Automated Deployment Script from Glassfish v2 to Glassfish v3

DZone's Guide to

Migrating an Automated Deployment Script from Glassfish v2 to Glassfish v3

· Java Zone
Free Resource

Learn how our document data model can map directly to how you program your app, and native database features like secondary indexes, geospatial and text search give you full access to your data. Brought to you in partnership with MongoDB.

Just recently we attempted to update an Ant script which we are using to do automated deployments to Glassfish v2 servers, to deploy to our new Glassfish v3 servers instead. This Ant script is invoked from our Jenkins automated deploy pipeline process (another blog post about this later) and copies a .war file from our Nexus repository and installs it to a Glassfish instance running on a remote server. I ran into a number of issues that prevented the Ant script from being used “as-is”.

The first thing that this assumes is that there is a Glassfish v3 server running on the build machine from which this script is executed. The build script needs access to the “asadmin” tool in the glassfish/bin directory in order to deploy a .war file to a remote Glassfish server.

The first issue was that the Ant deploy/undeploy tasks for Glassfish are in a different location in v3. Actually, not only is the .jar file with the Ant tasks in a different location in the newer version of Glassfish, its not installed by default! In order to get the Ant task you’ll need to go to the Update Tool on the admin web page of your Glassfish v3 instance and install the “glassfish-ant-tasks” component. Once you’ve done that then you can modify your Ant script to use the new Ant tasks (which are also located in a different Java package also). The code snippets from an Ant script below compare the differences between the Glassfish v2 and v3 ant task usage.

<!—Glassfish v2 ant tasks –>

<taskdef name="sun-appserv-deploy" classname="org.apache.tools.ant.taskdefs.optional.sun.appserv.DeployTask">
      <classpath><pathelement location="/nas/apps/cisunwk/glassfish/lib/sun-appserv-ant.jar"/></classpath>
<!—Glassfish v3 ant tasks –>

<taskdef name="sun-appserv-deploy" classname="org.glassfish.ant.tasks.DeployTask">
     <classpath><pathelement location="/nas/apps/cisunwk/glassfishv3/glassfish/lib/ant/ant-tasks.jar"/></classpath>
The next change that needs to be made to the build script is the call to the sun-appserv-deploy task itself. The "” installDir” property has been changed to “ asinstalldir” for Glassfish v3. A comparison of the v2 vs. v3 code snippets are below.
<sun-appserv-deploy file="/tmp/${app.name}-${version.number}.war"
   name="${app.name}-${version.number}" force="true"
   host="${server.name}" port="${admin.port}" user="${env.Admin_Username}"
   passwordfile="/tmp/gf.txt" installDir="/nas/apps/cisunwk/glassfish"/>
<sun-appserv-deploy file="/tmp/${app.name}-${version.number}.war" 
   name="${app.name}" force="true"
   host="${server.name}" port="${admin.port}" user="${env.Admin_Username}"
   passwordfile="/tmp/gf.txt" asinstalldir="/nas/apps/cisunwk/glassfish311"/>

The final task in getting this to work is to enable remote commands on each of the target Glassfish instances to which the apps will be deployed.

./asadmin enable-remote-admin –port <glassfish-admin-port>

where <glassfish-admin-port> is the admin port that domain (4848 by default).

The last “gotcha” to keep in mind here is that the Glassfish that is defined in the <sun-appserv-deploy> task with the “asinstalldir” property MUST be the same version as the remote target Glassfish instances where the web app will be deployed to. At least this was the case when we attempt to specify a Glassfish v3.0 instance in the installDir property, deploying to a Glassfish v3.1 remote instance. When we updated the installDir to point to a v3.1 instance, the deployment went fine. (v3.1 to v3.1.2 may be OK)

Hopefully this will help others that have encountered similar issues while attempting to do deployments to remote Glassfish instances either from Jenkins, Ant or other automated processes.

Discover when your data grows or your application performance demands increase, MongoDB Atlas allows you to scale out your deployment with an automated sharding process that ensures zero application downtime. Brought to you in partnership with MongoDB.


Opinions expressed by DZone contributors are their own.


Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.


{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}