- This topic has 1 reply, 2 voices, and was last updated 17 years, 10 months ago by Riyad Kalla.
-
AuthorPosts
-
James HurffMemberI have the following configuration for Eclipse:
Windows XP Professional
JBoss -> 4.0.2
JDK -> 1.4.2_12
MyEclipseIDE Bundle -> 5.1.0 GAI have a J2EE application made up of the following:
MyApp.ear (contains the following modules)
MyWebApp.war
MyEjb1.jar
MyEjb2.jarI have deployed MyApp.ear as an exploded archive to my running JBoss 4.0.2 server instance. I can see the files and folders in the c:\jboss-4.0.2\server\myserver\deploy directory as an exploded filesystem.
When I make a change to a JSP and save the file in MyWebApp.war, the change is immediately propagated to the JBoss deployment directory and the change is available in the running JBoss server. However, when I make a change and save the file to a Java class in the MyWebApp.war application module, the change is not propagated. If I redeploy the application, the change is made. I’d like to get the hot sync working where when I save the Java source code, the hot sync immediately takes place. This is the way it works on another machine on my network with this same application set. Is there an issue with my IDE settings or is it something in the applications’ deployment descriptors or meta data?
Please advise.
Riyad KallaMemberjhurff,
There are 2 things (or settings) that make this work.1) Running your app server in debug mode, allows the MyEclipse debugger to hook into the running JBoss JVM. When classes change, MyEclipse attempts to hot-swap the class bytecode. If the “shape” of your class is changing, then this operation will always fail. You can turn on/off hotsync failure notices under Window > Prefs > Java > Debug. Chances are you turned this off at one point and that’s why you aren’t seeing any messages about it.
2) If #1 isn’t working or failing, you can setup JBoss/Tomcat to reload changed class files. It does this by reloading the web context itself (restarting the individual web application). In Tomcat this is on by default, and I thought in JBoss it was as well. Unfortunately I don’t know where this setting is in JBoss, so I can’t help on specifics here.
3) If all the above fails, you can always login to the JBoss application manager or admin console (I’m not sure what it’s called) and simply restart your individual web applications when necessary from there.
4) If ALL of the above fails, restart the app server.
That’s the order of operations I develop in, and most of the time 1-3 will work fine,I only have to restart the app server when the VM bombs out (which seems to occur after a lot of hot-code syncs).
-
AuthorPosts