Possibilité d'éviter de recharger le contexte Spring dans Tomcat lors de l'échange de classes à chaud

Question

Comme la plupart des développeurs, nous apportons des modifications mineures au corps de la méthode et souhaitons la tester sans avoir à arrêter et à démarrer le conteneur, à savoir Tomcat. La fonction de remplacement à chaud fournie par la JVM semblait prometteuse et nous voulions nous assurer que Tomcat et le contexte Spring n'étaient pas rechargés. Cela fonctionne assez bien lorsque nous avons un projet maven à module unique. Cependant, lorsque nous avons affaire à un projet web maven multi-modules du type

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

et que nous souhaitons apporter des modifications au corps de la méthode d'une classe dans un module dépendant (disons kilo-business que le module kilo-web dépend), la permutation à chaud provoque un rechargement du contexte de tomcat et donc aussi de celui de spring. Si le changement a été effectué sur des classes dans kilo-web lui-même, le contexte n'est pas rechargé. Cela m'a amené à penser que parce que j'ai une jarre qui a été modifiée dans le module WEB-INF/lib Tomcat gère cela différemment : lorsque quelque chose change pour les classes dans WEB-INF/classes . Bien entendu, cette déduction est empirique - il serait bon que quelqu'un puisse indiquer une source authentique et son raisonnement.

Plus important encore, avez-vous des idées pour éviter que cela ne se produise ? Ce problème disparaîtrait-il si nous avions le contenu des pots dépendants dans le fichier WEB-INF/classes ? Je n'ai pas réussi à trouver un moyen de faire en sorte que le plugin WTP d'Eclipse déploie les projets dépendants en tant que répertoires éclatés en WEB-INF/classes .

Nous avons entendu parler des avantages de JRebel, mais nous voulions nous assurer que nous tirions le meilleur parti de ce que la JVM elle-même peut fournir.

Merci d'avance !

Answer 1

En fait, l'instance de tomcat était exécutée en mode débogage via eclipse. Lorsque j'ai modifié le corps d'une méthode d'une classe dans kilo-web Le JVMTI a procédé à un échange de code à chaud et les modifications ont donc été reflétées dans la sortie, mais la classe elle-même dans WEB-INF/classes n'a pas été modifiée (vérifié à partir de l'horodatage de la dernière modification). Il en va de même pour les modules dépendants tels que kilo-common bien que je l'aie remarqué par intermittence (mais cela fonctionne toujours). Il s'agit donc finalement d'une fausse piste, je vous prie de m'en excuser.

Plus généralement, après avoir écouté Exposé de Jevgeni Kabanov sur les classloaders En revanche, l'approche vanille de rechargement des classes utilisée par Tomcat nécessite un rechargement du contexte, car un tout nouveau Classloader est créé, qui copie l'état du Classloader existant (ce qui entraîne des bizarreries et des fuites associées). Dans l'ensemble, une excellente vidéo.