Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

Hot code replace in JBOSS4 and Eclipse3.1

If you are trying to debug your code using Eclipse, MyEclipse and JBOSS, then starting JBOSS via MyEclipse (in DEBUG mode) and setting your break points in Eclipse should be enough to trigger the debugger.

However while doing tool development the JBoss 4 hot-code-replace feature (not hot deploy) may be more used. Following these steps to debug a tool:

1. Use ant script to explode tool war into your <LAMS_EAR> (<jboss>/server/default/deploy/lams.ear) folder.

2. Redirect Eclipse classes output directory to <LAMS_EAR>/<tool_explode_folder>/WEB-INF/classes. This is only available in Eclipse3.1 - use the link external folder feature.

3. Turn on incremental compile feature in Eclipse IDE, so the classes will update to JBOSS deploy folder automatically once you save Java files.

4. For JSP files, synchronize them using an ant script to the corresponding JBOSS deploy folder. You have to run the ant task after updating some JSP files. We suggest using a shortcut to accelerate this operation.

Now startup JBOSS. If you change a java or jsp file, then just save the file or run ant and JBOSS will hot-replace the classes or jsp. No more over-one-minute re-deploy! The JBoss 4 hot replacement is a great improvement over the JBoss 3 hot replace.

If you follow this method, please ensure that the WEB-INF/classes classes are not deployed when using the master build script (build.xml in lams_build). This is fine for development and debugging but not for serious testing or production. Given the behaviour of the JBOSS class loader, having the same classes in more than one place can cause problems.


  • Hot code replace is supported on JDK 1.4.x VMs, and IBM J9 VMs. Hot code replace is limited to changes which do not effect the shape of a class. That is, changes within existing methods are supported, but the addition or removal of members is not supported. Note that hot code replace and stepping on JDK 1.4.0 VMs was unreliable. The underlying VM problems were fixed in JDK 1.4.1.
  • Hot code replace can not inspect most configuration file change,e.g., struts-config.xml, web.xml(works in Tomcat, not in JBoss) etc.