If you run in debug mode *from* eclipse this change should take effect over the debug wire, not via the deployments. Are you saying that does not work ? Or are you only using the IDE to deploy files and running the server externally ?
To get it to pick up changes no matter if you are using debug then you must restart the module.
In later versions of JBoss Tools/Developer Studio we automatically suggest to do the restart to the module if you changed classes and not running in debug mode.
I am running in debug mode from Eclipse. I use JBoss Tools to start WildFly in debug mode.
That's correct, I am saying that the change does not take effect right away over the debug wire but only under those conditions:
- The modified class is part of a Java project deployed as a JAR in WEB-INF/lib
- The modified class has not yet been loaded
When the class is loaded before being modified, everything is fine.
The change is not a signature change. It is only a small modification in some method body.
Is it worth restarting the module (as it works most of the time)? I even get the proper dialog to restart the server/module when changing a method signature.
By the way, in the overview of the WildFly server definition, I set up the "Application Reload Behavior" like this:
- "Use default pattern" is unchecked (the default pattern is: "\.jar$")
- "Intercept hot code replacement failures" is checked
- "On hot code replacement failure": Show Dialog
hmm - interesting. I could swear this worked in the past. Maybe WildFly changed how they load these that somehow makes the class "hidden" for the debug protocol.
I'll need to look into that ;/
"Is it worth restarting the module (as it works most of the time)?"
well, if you want it to work *everytime* restart of module is the safest but yeah, need to find out why jars are affected but not exploded classes.
"I even get the proper dialog to restart the server/module when changing a method signature."
even? the dialog is supposed to only show up if the debugger thinks update fails (which it will be in case of changing a method signature and you don't run something like jrebel)
If you feel that it's an issue, I could create an entry in the JBoss/WildFly issue tracker.
In the mean time, we wrote some code to read all the entries in the JAR file and do a Class.forName() on each of those. As all the classes are loaded, modifying a class is not a problem anymore. It's ugly but it is done only once when the web application starts and only when we are in development mode.
List<String> classNames = jarFiles
.flatMap(jarFile -> jarFile.stream())
.filter(jarEntry -> (!jarEntry.isDirectory() && jarEntry.getName().endsWith(".class")))
.map(jarEntry -> jarEntry.getName().substring(0, jarEntry.getName().length() - 6).replace("/", "."))
.filter(className -> (!className.endsWith("Test") && !className.endsWith("TestCase")))
classNames.parallelStream().forEach((className) -> Class.forName(className));
We have never tried to restart modules because we were scared that it would impact some stateful singletons. Since we made the switch to WildFly, we improved the situation to make the application more stateless. Now, I believe that we could give it a shot to restart the module. I'll experiment with this.
Restarting a module when a class is modified, is it only the matter of checking the checkbox that uses the regex in the "Application Reload Behavior" (Chapter 3. JBoss Server Editor)?
For the dialog showing up when a method signature is changed, it was just a note on the fact that this works fine when the class is loaded and that we do a signature change It was not really related to the issue with the classes in modules not being loaded right away.
It's interesting. When I check "Force module restart on following regex pattern" and using the pattern: "\.jar$", I see WildFly republishing a JAR with the modified file inside. The problem is still occurring though. It seems that it does not take into account the modification if the class has never been loaded.
This sounds *really* weird.
I unfortunately can't test it right now - but if you could try reduce this to its simplest example and attach the project plus steps to a Tools (JBoss Tools) - JBoss Issue Tracker jira I will find someone to look at this.