1 of 1 people found this helpful
Lets please separate the two cases:
Editing java classes:
For having classes hotswapped you need to be debugging. It is via the connected debugger that methods in classes can get changed in standard java vm's. This afaik *just* works.
You just mention class - not if it is a .java or .jsp you are editing but if it is .java this does "just work" afaik.
Unless you somehow stumbled on a bug jbosstools does not do anything but copy the jsp resources over. Restart of an app will by default not happen unless you explicitly force a full publish or change a jar (since for jars a reload is necessary in all cases). If you can create a sample project and outline which steps you do to see the app get restarted (the server console should print info about this) I would be very interested.
Huh, ok. So I went about creating a minimal test case, which worked pretty much exactly as I wanted it to. Then on re-running the app that I had been running, it worked properly too!
In the course of doing all that, I noticed in the Servers view that there were two versions of my app under the Wildfly server, one of which had [Started, Synchronized] next to it, and one of which just said [Started] next to it. I have no idea how the duplicate entry got into there (how is it even possible?), but when deploying my test case I just cleared everything out, and having re-run my app afterwards there now seems to only be one entry there. I presume that that is related to the constantly-redeploying issue, but I have no idea how to recreate it now (and don't really want to ). Hopefully if anyone else has this issue they might be able to find an answer here as to how to get out of it.
Thanks anyway for answering Max
Thanks for helping
If you ever manage to recreate the situation where you deployed both let us know.
But here is my theory:
Maybe you have a .war of the project somewhere that gets updated automatically and you used "mark as deployable" which would make it possible to deploy the
war to the server ...then after that you actaully deployed the "real project" and boom you could end up in this situation I imagine.
Could that match what you did ?
I'm a bit new to the tooling for running this stuff from inside eclipse, so it's entirely possible that I clicked "mark as deployable" at some point to see what it did.
I don't think I have a war that gets updated automatically, unless the eclipse files generated by the gradle eclipse-wtp plugin set things up to do that.
Anyway if I manage to recreate it I'll let you know.