Ed Burns's Blog

(near) Zero (re-)Deployment Time for JSF

One oft cited complaint about Java Web Applications is the slow and laborious deployment step. This step seriously undermines the ability to get into a flow state and is generally a major buzz kill. The absense of a deployment step is one reason why people like Ruby on Rails so much.

JSF-Extensions Design Time brings good news for flow-impaired Java Web application Developers: the JMX PhaseListener.

The implementation of this was really simple. I just took Jean-Francios Arcand's JMXDeploy class, modded it ever so slightly, as you can see in the source code, and called it from a PhaseListener.

I did a screencast about it too.

Comments

• how's this different than the tomcat start/stop tasks with ant?

  Posted by: jhook on December 01, 2006 at 08:32 PM

• from talking to Ryan, what I'd like to see the RI do is have a com.sun.faces.Development init param which will keep Configs in memory and periodically check them for updates, if so, reload them. This can be done on a much smaller scale with managed beans, if the class type is different, push a new instance back in, maybe doing some magic with copying properties first. This kind of automatic deployment and refreshing is something developers would really like in my opinion.

  by having a development mode, you can sacrifice performance up front for development speed while not committing to exposing restartable URLs in your application.

  Posted by: jhook on December 01, 2006 at 08:56 PM

• Long time I took a look at the Tomcat"s code, but I suspect the ant task is also using JMX, or the task invoke the StandardContext method directly.

  Posted by: jfarcand on December 02, 2006 at 11:08 AM

• Ed, even if JF JMX approach is great, it does not work for an enterprise application (ie, an EAR). What we need is realy, a "zero deployment" solution.

  IMHO, the glassfish team should work with Java EE team (plus netbeans and eclipse team) to introduce an standard for exploded Java EE archive structure (how do you explode an EAR, up to which level ? you stop to WARs, go up to JARs ?).

  Such structure woud be mandatory for internal implementers to store the live version of the archives in this way. Doing so, it would be consistent from development phase up to deployment phase. Simply the WAR or EAR, but exploded ;-)

  This should be the same way that deploydir is working for WAR fils already, that is you can work live on the directory as long as the structure is correct.

  This way, people could for instance FTP a production website (nobody does that ... well...) and simply update live a JSP or an XML configuration file, without the need to go back on the development too and again build, package, deploy ... blahblah ... pain ... time lost ...

  It can be done, and is already part of netbeans and glassfish issue tracker ;-)

  Rgs,
  JB

  Posted by: bjb on March 07, 2007 at 10:05 AM

This work is licensed under a Creative Commons License.