Home/ Questions/Q 8526663
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-11T08:20:10+00:00

As most developers, we make minor changes to the body of the method and

  • 0

As most developers, we make minor changes to the body of the method and wish to test it without having to stop and start the container viz. Tomcat. The hot swap feature provided by the JVM seemed promising and we wanted to make sure that both Tomcat and the Spring context are not reloaded. This works quite well when we have a single module maven project. However, when we are dealing with a multi-module maven web project of style

kilo
-kilo-business
-kilo-common
-kilo-dao
-kilo-web

and we wish to make changes to the method body of a class in a dependent module (say kilo-business module which the kilo-web module depends on), hot swap causes a reload of tomcat’s context and hence also spring’s. If the change was done to classes in kilo-web module itself, the context is not reloaded. This lead me to believe that because I have a jar that has now been modified in WEB-INF/lib, Tomcat is dealing with it differently that when something changes for classes in WEB-INF/classes. Of course, this inference is empirical – would be great if someone can point to an authentic source and its reasoning.

More importantly, any ideas to avoid this from happening? Would this problem go away if we have the contents of the dependent jars in WEB-INF/classes? I was not able to find a way to make the eclipse WTP plugin to deploy dependent projects as exploded directories in WEB-INF/classes.

We have heard of the good things provided by JRebel, but wanted to make sure that get the most out of what the JVM itself can provide.

Thanks in advance!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Actually, the tomcat instance was being run in debug mode via eclipse. When I changed the method body of a class in kilo-web, the JVMTI did a hot code swap and hence the changes were reflected in the output, but the class itself in WEB-INF/classes was not modified (verified from the last modified timestamp). The same also happens for the dependent modules like kilo-common though I have noticed it intermittently (but still works). So a red herring after all – my apologies.

    More generally, after listening to Jevgeni Kabanov’s talk about classloaders, the vanilla approach of reloading classes used by Tomcat necessitates a reload of the context because an entirely new Classloader is created which copies state from the existing Classloader (and running into quirks with associated leaks). Overall, a great video.

    • 0