[WELD-2800] Don't use jar cache in ServiceLoader.loadServiceFile

[WolfgangHG]

This should resolve https://issues.redhat.com/browse/WELD-2800

java.net.URL.openStream uses a jar cache. Thus the jar file is kept in memory as long as the Glassfish server is alive, and thus the jar file in "glassfish\domains\domain1\applications" cannot be deleted on windows when the app is undeployed.

Workaround: set URLConnection.setUseCaches(false) before accessing the InputStream:

URLConnection jarConnection = serviceFile.openConnection();
jarConnection.setUseCaches(false);
is = jarConnection.getInputStream();

I pushed it to the 5.1 branch as GlassFish 7.0.18 uses Weld 5.1.3.Final, and I hope that this fix makes it to next Glassfish.

I don't have much git experience and never pushed to a branch, so please be patient with me if I did this wrong ;-)

[manovotn]

Hello,

I am currently on PTO and unless @mkouba has some spare cycles, it won't get reviewed right away.
I'll keep it on my TODO list once I am back though :)

[manovotn]

Interesting find and thank you for the PR @WolfgangHG!
We will want to address this in both, 5.1 and master branch which will both have this problem.

thus the jar file in "glassfish\domains\domain1\applications" cannot be deleted on windows when the app is undeployed.

So this is a Windows-only problem but does that mean that what we do is wrong and should be done differently?
Turning off the caching seems like a workaround more so than a proper solution.
I don't have anything against turning off the caching as such (I don't think it does much here), just curious as you seem to have done quite some investigation already.

[WolfgangHG]

I can only provide a bit of information that I found last year when I first analyzed this stuff - it happened also in arquillian.

java.net.URL.openStream is a shortcut to openConnection().getInputStream(), and openConnection() returns a java.net.URLConnection, which has a subclass sun.net.www.protocol.jar.JarURLConnection (code e.g. here). This class uses a cache by default (see method connect). This cache causes the file leak. There is no API to flush the cache.

You are right: the locked file only happens with windows. But I don't know what happens with Linux when an application is redeployed - maybe the weld code would still access the previous jar that is still cached?