'Hot code replace' not working -- Eclipse doesn't change any code on JBoss

Question

I'm currently experiencing a problem with 'hot code replace' not working on Eclipse Galileo and JBoss 4.2.3.

Among other applications I'm running an exploded Java WAR on my local JBoss. The project from which it is build is managed by Maven. I build the project using the Maven goal war:exploded and then I copy that directory to JBoss with an ANT script.

When I'm now running the application and set a breakpoint anywhere in the code, Eclipse properly halts at that line in the debug mode. But when I'm making a change to the source file and save it, Eclipse doesn't apply this change to the JBoss. For example, when I make a normal code line into a comment, the debugger still steps over this comment as if it was regular Java code. Or when I remove a line, the debugger seems to get out of sync with the file and starts stepping over parenthesis.

But I'm not getting any 'hot code replace error'-messages either. It seems to me that Eclipse applies the changes to the source files, but doesn't apply it to the JBoss.

Are there any special preferences that have to be turned on in order to make hot code replace work? Or are there any mistakes in how I build and deploy the application to the JBoss?

Pyromancy

Answer 1

I did not work with JBoss but I have two suggestions.

1. If you run your application in eclipse using the launch configuration
   
   Is your "Project" - "Build Automatically" flag enabled? If not, the code is not compiled and ignored t runtime.

2. When you debug an application in remote mode, you can not change the code, but you can change the value of parameters. (I think)

Biquadratic

The option 'Project -> Build Automatically' wasn't enabled. Now I've activated it and everything works fine. Danke, Markus. – Pyromancy

Thank you! This problem has been driving me crazy for weeks. Hot code replace suddenly stopped working, without any error messages. Turned out that I had switched off 'Build Automatically'. Switching it on again solved the problem. – Loan

It's not necessary to set "Build automatically" on. It's just important to "build" project, after you made changes. – Affiche

When you debug the application in remote mode you can modify the code. The hot swap does not always work, but it does not always work when you run the project in eclipse either. – Helices

This was the first answer that popped up when I googled, and sure enough, and I am not sure how this happened, but my Build Automatically was indeed unchecked. I was pulling my hair out as to why my breakpoints where not matching my code at all. – Remora

Expanded on this answer since I think it misses a subtlety where in certain cases you need to build after the debugger is attached. My answer below: #2674054 – Give

Answer 2

I had issues in a project with Maven and Eclipse. No errors were shown, but hot code replacement was not working. I read that "Build Automatically" has to be checked. I checked this and it still didnt work. I had some errors in other projects in my build path. I believe that was the error. When i researched, I found that the we had to uncheck the "Abort build when buildpath errors". I have given the details in the link below.

Forb

Thanks for your hint, although I do not have build errors (in any of my (related) projects), unchecking this option helped..! – Isotone

... where is the link?? – Dessertspoon

Link is here: help.eclipse.org/juno/…. Not working for me anyway :( – Pritchett

I have maven build with eclipse. How do you do hot code with that environment. Looking for a solution. Thanks Dhiren – Ayurveda

Since the link went stale I made a new answer below expanding on this: #2674054 – Give

Answer 3

I had a similar problem with Open Liberty. Let me build on the accepted answer plus the answer from @user513365 (since a link there is now dead).

In my case I had two issues:

1. Build path errors

In my case my Incomplete build path was because I was using a Maven project with only src/main/java but without a src/test/java (so probably could have solved this by creating the latter).

But I was able to fix Hot Code Replace by going to Preferences -> Java -> Compiler -> Building and make one of two changes:

Either:

1. uncheck Abort build when build path errors occur OR
2. using the drop-down, change Incomplete build path from Error to Warning.

2. Make sure Eclipse-built classes are getting loaded

In my case my remote JVM was using a full JAR artifact from my local .m2 Maven repository. The accepted answer of enabling: "Project" - "Build Automatically" misses a subtlety here.

The Eclipse project build in my case is only going to do a hot code replace, if I do the Eclipse build after the debugger is attached. Yes, it will do the Eclipse build automatically, but if I restart my remote JVM and simply attach the debugger, it is still configured to load this class from my local .m2 JAR, and NOT pick up my local change.

FINAL NOTE ON THIS ANSWER VS. OTHER ANSWERS

If you are constantly changing the class that you are building automatically you might not notice the subtlety in point 2., and the accepted answer combined with the build path error mentioned in @user513365's answer will be all you need.

Give

Answer 4

First check is the Project/Build automatically.

It may be also required to check the application server deployment configuration,

E.g. for JBoss, in Eclipse, in the Servers view, double click on the server and there is a Deployment Scanners section with two check boxes:

• Add missing deployment scanners
• Remove added deployment scanners before shutdown

https://docs.jboss.org/author/display/AS7/Deployment+Scanner+configuration JBoss AS/ Deployment Scanner configuration

Uniocular

Answer 5

I just recently had this problem in Eclipse 2019-06 and found I had to uncheck the option in "Replace classfiles containing compilation errors" in Preferences->Java->Debug->Hot Code Replace group. All the other options there were checked. Previous to doing that I was getting "Hot code replace failed - Delete method not implemented" despite my only change being to ass a System.out.println call. As soon as I changed that option ( in the same debug session ) it started working for me.

Totalitarianism