classloader and caching of /lib (follow up on initial IDEA redeploy problem)

[kbachl]

Hi,

in #25771 I wrote about the problem I faced with redeploy and IDEA. So far the new BETA of 2025.3 fixed the base problem of files not getting updated, but glassfish (7.0.25 here) still puts me on some headache.

To explain lets take this resource:

file:/home/user/dev/projects/project-a/app/target/app-v1.0.0/WEB-INF/lib/plugin-module-1.0.0.jar!/com/example/plugin/tiles/header/Header.html

• -> in a regular app that gets redeployed, the Header.html is not reloaded by the classloader as it doesn't reload the plugin-module-1.0.0.jar

• -> hot reload/ resource update only pickup a changed XML file in it, but no html files that got changed and also class files seems to be ignored

• -> in DEBUG mode same behaviour as in regular server mode

• -> only way to fix this is make a special exploded war and make sure the content of the "plugin-module-1.0.0.jar" gets put into /class folder and also remove the "jar" itself from lib as then CDI errors would come up (duplicated declarations)

I really find this not perfect as the now worked on exploded war is not the same as the one that is later beeing deployed. Especially that in debug mode the server wont pickup a newer dated JAR file seems neither logical nor straightforward.

I would at least expect to see the classloader upon redeploy/ hot reload etc. scan the JAR files and watch for newer date/time on it and in case it sees newer ones he redeploys them like he does with the content of the /class directory. I know classloader caching is a thing, but I never would expect it at that level and ignoring newer versions of libraries.

Any comments are really appreciated.

[RinZ27]

This looks like a collision between the JVM's native JarFile caching and GlassFish 7's startup optimizations. Even if GlassFish creates a new WebappClassLoader on redeploy, the underlying JVM URLConnection caches often hold onto file handles or canonical paths of the old JARs, especially on OSs with strict file locking.

Here is the technical breakdown and the configuration changes needed to force a clean reload in GF 7 / Jakarta EE 10.

1. JVM-level Caching

The most effective way to force the JVM to release file handles and ignore cached paths is to disable memory mapping and canonical caching.

Add these to your JVM options (via domain.xml or Admin Console):

-Dsun.zip.disableMemoryMapping=true
-Dsun.io.useCanonCaches=false

2. GlassFish / Jakarta EE Configuration

GlassFish 7 defaults to aggressive caching for deployment speed. You need to explicitly disable internal resource caching in your web descriptor.

Make sure you are using the correct Jakarta EE 10 schema in WEB-INF/glassfish-web.xml to avoid compatibility mode behavior, and add the use-internal-servlet-cache property:

<?xml version="1.0" encoding="UTF-8"?>
<glassfish-web-app xmlns="https://jakarta.ee/xml/ns/jakartaee"
                   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                   xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee https://jakarta.ee/xml/ns/jakartaee/glassfish-web-app_6_0.xsd"
                   version="6.0">

    <class-loader delegate="false">
        <!-- Force reload check on every request if needed during dev -->
        <property name="reload-interval-in-seconds" value="0"/>
    </class-loader>

    <!-- CRITICAL: Disable internal caching for resources inside JARs -->
    <property name="org.glassfish.web.use-internal-servlet-cache" value="false" />
    
    <property name="reload" value="true"/>
</glassfish-web-app>

3. Application Scope

Check your domain.xml for the preserveAppScopedResources property. If set to true, GlassFish attempts to reuse resources across redeployments. Ensure it is disabled for development environments:

<application ...>
    <property name="preserveAppScopedResources" value="false"/>
</application>

Note on IDEs:
When using "Redeploy" in IntelliJ, the IDE often attempts a hot-swap or partial update. If the above settings don't resolve it, the issue is likely that the IDE isn't triggering a full undeploy/deploy cycle. In that case, the only consistent fix is to change the Run Configuration to build an Exploded WAR artifact, which bypasses the JAR locking mechanics entirely.

[OndroMih]

We hit this issue in a MicroProfile TCK, which, by mistake, deployed 2 different test apps under the same name, with the same WAR file name. GlassFish (more specifically, Weld), uses URLConnection, which caches the list of file contents in a JAR file if it was previously opened. That resulted in the second TCK test not finding the expected files, which were in the WAR but were not in the previous test's WAR, the contents of which were cached.

We addressed this in GlassFish 8-M15, with this change: #25835

Can you try with GlassFish 8.0.0-M15 if it fixes your issues, @kbachl ?