2 Replies Latest reply on Jan 29, 2003 9:15 AM by Tim Hague

    Directory hot-deploy granularity

    dani Newbie


      I'm thinking about adding some code to JBoss to provide better granularity to the [hot] deployment of directories. Here's the situation: I'm getting tired of repackaging my EJB's into a JAR, creating a WAR, combining them into an EAR, dropping the EAR file into the deployment directory, and waiting for the whole EAR to redeploy before testing my one-line change.

      Now, I know JBoss lets you drop a directory in the hot-deploy directory, and as long as it matches the EAR file structure, it will deploy it, and I have considered using this. What I would like, however, is to be able to make my one-line change to one of the EJB's in the directory, recompile the .class file, and have JBoss automatically recognize that the one EJB in the application needs to be redeployed, instead of having to redeploy the whole application. This would speed my development on JBoss incredibly, and would mitigate what I consider to be the Achilles heel of J2EE development.

      I've looked through the JBoss code available for download on the site, and from my quick perusing am inclined to think that, among others, my changes need to happen in:

      org.jboss.net.protocol.file.FileURLConnection - change the implementation of getLastModified() so that it recurses all subdirectories and checks all files for modifications, not just the base directory.

      org.jboss.deployment.URLDeploymentScanner - change the implementation of scan() so that modified directories do not get bluntly undeployed and redeployed. Instead, intelligently determine which parts of the application need redeploying, and do them instead.

      Basically I'm looking for feedback here. Is there an easier way to achieve my goal than this? If not, am I on the right track as far as how to make the changes? Does anyone who is more familiar with the code than I have any suggestions or pointers?

      Thanks for reading my long rambling post :)


        • 1. Re: Directory hot-deploy granularity
          Vesa Varimo Newbie


          I have hundreds of beans in my application and reloading EAR takes 3-5 minutes (with AMD 1.2ghz 1gt RAM) even thought EAR is deployed as directories. I couldn't find a feature in JBoss which would reload a single bean in EAR.

          After wasting some huge amount of time waiting the EAR to be deployed, I created a little method in MainDeployerMBean which reloads given ejb component in EAR application without reloading EAR itself. I call this method over RMI in ant task.

          I run in to few problems, because of EAR classloaders... first of all the whole EAR classloader have to be reinitialized because there is no way to remove loaded class from classloader (afaik). Reloading classloaders isn't very hard, but after I have done this, all classes and instances in bean containers have to be reloaded. This is very painful, because the EAR classloader is quite widely used. Also all classloaders in webcontainer(s) have to be updated, I did this only for Tomcat.

          Well, I got this finally working and now my re-deployment takes about 30 seconds instead of five minutes, so I'm quite happy with this solution.

          JBoss gurus: If I send this patch to you, can you possibly
          think of including it in JBoss as an official feature (if it doesn't already exists)? I'm quite sure that every JBoss developer would like to use this feature.

          Best Regards,


          • 2. Re: Directory hot-deploy granularity
            Tim Hague Newbie

            Hi Vesa,

            I'm currently doing something very similar and would be interested in 'borrowing' your solution! Could you send me a copy or a link for download? Email is tj_hague@hotmail.com .