SVT: App does not restart after doing Hot code replacement while Debugger is started.

[rumanaHaque]

I have installed Liberty Tools Eclipse 25.0.6 - as part of this TER - https://github.ibm.com/websphere/system-test/issues/1498

I started the Debugger, and while it is still running, I tried to change the method signature.

I tried to change the method signature - from private void issueEndLinesHtmlTest(PrintWriter out) to private void issueEndLinesHtmlTest(PrintWriter out, String test)
and saved the file.

However, the App didn't restart, and I did not see any pop-up for the Hot Code Replacement.

The only message I see in the console is that the app source compilation was successful:

[[1;34mINFO[m] [AUDIT  ] CWWKZ0001I: Application AcmeWebEjbEar started in 269.746 seconds.
[[1;34mINFO[m] AcmeAnnuityWeb source compilation was successful.
[[1;34mINFO[m] AcmeAnnuityWeb source compilation was successful.

Steps to recreate:

1. Get the Acme App from this repo (acme-ee10 branch) - https://github.ibm.com/was-svt/acme-ee/tree/acme-ee10
2. Update the acme-ee/pom.xml with this for Liberty Maven Plugin.

<!-- Enable liberty-maven plugin -->     
      			<plugin>
        			<groupId>io.openliberty.tools</groupId>
        			<artifactId>liberty-maven-plugin</artifactId>
       
       				<version>3.11.4</version>
      				<configuration>
      					<stripVersion>true</stripVersion>
       					<keepTempContainerfile>false</keepTempContainerfile>
      				</configuration>
      			
      			</plugin>   

3. Start the App in Debug mode using the Liberty Tools.
4. Make a change in the method com.ibm.wssvt.acme.annuity.web.AnnuityWebServlet,
   from private void issueEndLinesHtmlTest(PrintWriter out) to private void issueEndLinesHtmlTest(PrintWriter out, String test)
5. The App does not restart as expected.

[rumanaHaque]

This is the Eclipse version that I used.

[rumanaHaque]

In order to run the App, we also need the server.xml file.
I have al the files including the server.xml in this config dir, which should be placed in AcmeWebEjbEar/src/liberty/config - as shown here:

Here is the config dir zip.

config.zip

[awisniew90]

I was able to recreate this behavior on another app: https://github.com/openliberty/guide-maven-multimodules.git

When in debug mode, HCR does not detect any changes to code in the submodules. I also confirmed that this same behavior exists when starting in non-debug mode and attaching Eclipse's native Remote Java Application debugger, so this does not seem like an issue specifically with LTE.

I did notice, however, that an application will need to be started from the EJB module in order for the new "disableApplicationMonitor.xml" file to be generated. That is something we should probably document.

[awisniew90]

Still investigating how to get HCR to work for a Maven multi-module application.....

[rumanaHaque]

As @awisniew90 suggested, I did try to start Debugger, then access the AcmeAnnuityWebServlet and then try the HCR by modifying one of the methods in the AcmeAnnuityWebServlet. However, I still was not able to see the prompt for the HCR using my App.

[rumanaHaque]

@awisniew90 suggested that this HCR was dependant on the JVM that I was using.
For my App, I was using this java version

When I switched over to the java that was installed as part of the Eclipse install

java.home = C:\Eclipse-2025-03\eclipse\plugins\org.eclipse.justj.openjdk.hotspot.jre.full.win32.x86_64_21.0.7.v20250502-0916\jre
java.version = 21.0.7
java.runtime = OpenJDK Runtime Environment (21.0.7+6-LTS)
os = Windows Server 2022 (10.0; amd64) (en_US)

and followed the steps to change the issueEndLinesHtml method from a private to public, I did get the HCR prompt as expected.

[awisniew90]

It seems that different JRE implementations handle hot swapping (HCR) differently. Particularly, it seems that the Semeru and OpenJ9 implementations do not always function as expected, but this is something we need to investigate further.

This, however, is outside of the LTE debugger function, and we simply react according to what Eclipse and the JVM do in regards to hot code replace. Still, it would be good to better understand if there are differences in how each JVM functions in this area, so let's keep this issue open for future investigation.