- This topic has 5 replies, 2 voices, and was last updated 21 years, 2 months ago by
.
-
Posts
-
Hi,
I have a session bean that I can deploy successfully and for which sync-on-demand also works. I use exploded deployment.
After adding a private method (without any XDoclet tags) and trying to rerun the application, I get the error
org.jboss.Main at localhost:6164 (may be out of synch) was unable to
replace the running code with the code in the workspace.Reason: Hot code replace failed – Scheme change not implemented.
Redeploying the application works. Still, after redeploying the application, making changes to this file still results in this message everytime I save this file. This means I cannot use sync-on-demand anymore.
What should I do to correct this problem?
Cheers
ErikErik,
What is happening are two things. First, the Eclipse debugger compiles your Java class and attempts to update it into the remote JVM using hot code replacement, as supported by the 1.4 JPDA spec. Second, Sync-on-Demand updates your Java file to all your deployment locations.
The error you’re seeing is a failure of step one because you’ve modified the class in such a way that hot code replacement is currently unsupported by the JVM. The basic rule is that for hot code replacement to work, you can’t change the “shape” of the class. This includes adding methods, member variables, etc. This will get better in the future as the debugging spec matures, but that’s where the limitation now is.
Since Sync-on-Demand has already made sure that the deployment class has been updated, you’ll simply have to stop and restart the application server after making a change in a Java class that isn’t supported by hot code replacement.
–Scott
MyEclipse SupportErik,
What is happening are two things. First, the Eclipse debugger compiles your Java class and attempts to update it into the remote JVM using hot code replacement, as supported by the 1.4 JPDA spec. Second, Sync-on-Demand updates your Java file to all your deployment locations.
The error you’re seeing is a failure of step one because you’ve modified the class in such a way that hot code replacement is currently unsupported by the JVM. The basic rule is that for hot code replacement to work, you can’t change the “shape” of the class. This includes adding methods, member variables, etc. This will get better in the future as the debugging spec matures, but that’s where the limitation now is.
Since Sync-on-Demand has already made sure that the deployment class has been updated, you’ll simply have to stop and restart the application server after making a change in a Java class that isn’t supported by hot code replacement.
–Scott
MyEclipse SupportHi,
This type of restriction is good to know. If it applies to all classes that are part of deployment, it is a serious restriction for sync-on-demand because adding methods to classes is what I do in many cases.
Unfortunately, JBoss takes about 20 seconds to startup on my computer. Perhaps it is good anyway to develop functionality using regular Java classes (not EJBs) and write EJBs to delegate to these classes. In this case, the sync-on-demand functionality will not be needed that much and regular Junit tests will suffice.
Cheers
ErikErik,
A little clarification is in order.
If it applies to all classes that are part of deployment, it is a serious restriction for sync-on-demandErik,
A little clarification is in order.
If it applies to all classes that are part of deployment, it is a serious restriction for sync-on-demand
This isn’t a limitation of sync-on-demand, it’s a limitation imposed by Sun in the JDK 1.4 debugging architecture (JPDA). Sync-on-demand will dutifully update the file as requested, but the JVM won’t reload it through the hotswap mechanism because the limitations of hotswap have been exceeded. Once this happens, however, you should be able to trigger an application reload in your server to get your code back in sync. Reloading is server-specific and we’ll be adding direct support for it soon, but in JBoss you need to “touch” the application.xml file. You can do this by modifying it slightly in MyEclipse and when the deployer updates it in the JBoss installation your application should be reloaded.
Perhaps it is good anyway to develop functionality using regular Java classes (not EJBs) and write EJBs to delegate to these classes.
This is actually what we recommend to our consulting clients.
–Scott
MyEclipse Support
