Jean-Francois Arcand's Blog

Fast web application redeployment using JMX

When developing a web application (Servlet, JSP or JSF), you always have to redeploy many times your war files (at least I need to!) to see your changes in real time. GlassFish has an option called deploydir which I found very usefully. The idea here is to deploy your web application without having to bundle it inside a war file. So instead of doing:

% cd myApp
% jar myApp.war *
% asadmin deploy myApp.war

you do:

% asadmin deploydir myApp

note that myApp can be located everywhere, and doesn't need to be under a special directory. Now if I change something, let say myServlet.java and then recompile, I still need to redeploy my application. So you can always do:

% cd ../
% asadmin deploydir myApp

and your web application is redeployed. Well, redeployment in GlassFish means your web application will be undeployed and then deployed. Even if redeployment is fast, I was looking for a way to redeploy without having to undeploy first. Fortunately, I've found a trick by using JMX.

When a web application is deployed in GlassFish, its mBean is exposed using the following:

com.sun.appserv:J2EEApplication=null,J2EEServer=server,j2eeType=WebModule,name=//server/XXX

where XXX is your web application context root. Cool, because it means the WebModule object can then be queried using any JMX client (ex: jconsole). I'm not an expert with jconsole, so I will not discuss how to do it in details here.

The WebModule exposes some usefull methods that can be executed. Amongs all of them, three are realy interesting:

WebModule.reload()
This method is designed to deal with reloads required by changes to classes in the underlying repositories of our class loader. It does not handle changes to the web application deployment descriptor. If that has occurred, you should stop this Context and create (and start) a new Context instance instead.

WebModule.start()
Start the WebModule

WebModule.stop()
Stop the WebModule

What it means is if I can locate the WebModule mBean and if I don't make any change to my web.xml, I can always do a reload() and all my new compiled classes will be loaded in memory. But what is the difference between doing reload() versus stop() and then start()? The only difference is the reload() will mark your application as paused, so upcoming request will not get a "Not Found", but instead an "Unavailable" error page. Well, I doubt the reload() can be used in production, so using stop() and then start() should be enough. That's good because now I can do:

% asadmin deploydir myApp
% cd myApp //do some change and recompile
% open jconsole, get the mbean and stop()/start()

OK but doing this is slower that using the deploydir command (in my case at least) because there is too much typing ;-). Fortunately, I was able to programmatically implement the JMX call by looking inside the GlassFish code, and now I can do:

% asadmin deploydir myApp
% cd myApp //do some change and recompile
% jmxDeploy --restart myApp

Look promising, does it? But it has its limitation. Since the JMX call skip the entire GlassFish deployment code, annotation will not works. I didn't extensively tested it, but I was able to make it work with EJBs (but you need to recompile the code, because I have hard coded J2EEApplication=null). It shouldn't be difficult to extends the functionality to ear file by default.

Still interested? You can checkout the code here. It contains a tested jmxDeploy.sh script and an untested jmxDeploy.bat. The starting script consist of:

#!/bin/sh

AS_HOST=localhost
AS_ADMINUSER=admin
AS_ADMINPASSWORD=adminadmin
AS_ADMINPORT=4848

$JAVA_HOME/bin/java -classpath ./target/classes:$S1AS_HOME/lib/appserv-deployment-client.jar:$S1AS_HOME/lib/jmxremote_optional.jar:. org.glassfish.deployment.util.JMXReload $1 $AS_HOST $2 $AS_ADMINUSER $AS_ADMINPASSWORD $AS_ADMINPORT

Make sure you change those values if they don't match your configuration. The JMXjmxDeploy support two options:

jmxDeploy --reload|restart

where reload map to the mBean reload(), and restart does stop()/start().

Finally, this is not officially supported, and if you find bugs (which I'm convinced you will), then please do not open bugs, but instead add your finding using that blog. For our next official release, we may or may not decide to support the feature directly.

Patches are more than welcome!
technorati: glassfish

Comments

• This is great. It works well and I like it.

  In fact, it even works when all you change is a .properties file in JSF.

  Bravo!

  Ed (JSF co-spec-lead)

  Posted by: edburns on March 01, 2006 at 07:38 AM

• NetBeans uses directory deployment with GF and SJSAS 8.x... too.

  
  vbk

  Posted by: vbkraemer on March 03, 2006 at 07:48 PM

This work is licensed under a Creative Commons License.