Spring.jar locked when redeployed in a portal?

[GrantGochnauer]

I’ve been developing portlets under Jetspeed2 using the new Spring 2.0M2 release. I have been having a problem during redeployment of my .war file on only those portlets that use Spring. When the .war file is un-deployed, the spring.jar is the only file left in my /webapps/{portletname}/ folder.

What I have to do to redeploy, is undeploy the .war file, shut down Jetspeed2, remove the exploded folder, then startup Jetspeed2 and re-deploy the .war file. Why would the .jar file for spring be the only jar that isn’t being released by Tomcat? Again, I’ve only seen this issue when using Spring based portlets.

Thanks in advance to anyone who has an idea..



(I posted this question on the list serve but it didn't seem to get distributed.. sorry in advance is this is a dup)

[Cowboy Bob]

Are you running on Windows? In which case it may be the fault of the operating system and the way that NTFS/FAT locks files when they are in use.

You can find out more information here - http://forum.springframework.org/showthread.php?t=19516

[masrawi]

I had problems with the redeploying but this only occurs since upgrading to m2, when downgrading to 1.2.6 the problem disappear, so I guess it is more of a spring problem than a windows problem.

[GrantGochnauer]

Are you running on Windows? In which case it may be the fault of the operating system and the way that NTFS/FAT locks files when they are in use.

You can find out more information here - http://forum.springframework.org/showthread.php?t=19516

The interesting thing here too is that it ONLY happens with the spring.jar and not any other jar in any other portlets.

Also, I have added the following to Tomcat context.xml file which prevent the NTFS locking issue from being a problem:

<Context antiJARLocking="true">
</Context>

It just seems weird to me that it is only happening with the spring.jar.. I guess the next step to pinpoint would be to use the component based spring jars instead of using the all inclusive spring.jar..

--Grant

[masrawi]

I 've tried that and the problem now is in the spring-beans jar, you can reproduce that by trying merely to delete all the jar files in the lib dir, and only this jar is locked which means that it is opening some sort of stream and not closing it properly I guess

[masrawi]

correct me if I am wrong:I think the problem lies in PropertiesLoaderUtils which is using classLoader.getResources(resourceName) and used by
org.springframework.beans.factory.xml.PluggableSch emaResolver

from tomcat FAQ
"Most locking issues will occur with JARs from /WEB-INF/lib,
and are useally caused by access through URLs. ... when accessing resources using the getResource method of the URL classloader "

[masrawi]

the method PropertiesLoaderUtils.loadAllProperties should be changed to

public static Properties loadAllProperties(String resourceName, ClassLoader classLoader) throws IOException {
Properties properties = new Properties();
Enumeration urls = classLoader.getResources(resourceName);
while (urls.hasMoreElements()) {
URL url = (URL) urls.nextElement();
InputStream is = null;
try {
is = getInputStream(url);
properties.load(is);
}
finally {
if (is != null) {
is.close();
}
}
}
return properties;
}
private static InputStream getInputStream(URL url) throws IOException {
URLConnection con = url.openConnection();
con.setUseCaches(false);
return con.getInputStream();
}

[Cowboy Bob]

I disagree about changing the code in that way. I use exclusively Unix/Linux servers and desktops. I *want* the caching feature enabled.

There should be either a Windows only version of the class, or there should be some kind of init parameter.

Why should those of us who don't use Windows be punished for what is a major bug in its file handling?

[masrawi]

org.springframework.core.io.UrlResource is using the same technique by the way so I guess it is already a known issue

[Cowboy Bob]

No doubt it is a known issue. However, caching is normally used to improve performance. Its also obvious from this code that the caching is on by default and that Sun therefore regard it as a "good thing". Therefore, why do I as a non-Windows using developer get penalised by having slower workaround code in the framework?

Seems to me that the best code should always be the default, and if you happen to be Windows handicapped, that you should be able to configure the code to work around your issue. If the code stays as you suggested then I have no option but to have caching off or to write my own workaround code, when it isn't my OS that has the bug in the first place.

I don't want Windows workaround code in my application thanks.

[GrantGochnauer]

Could there be an option to disable this via some parameter in XML for us lowly Windowz users? :D

[Cowboy Bob]

Could there be an option to disable this via some parameter in XML for us lowly Windowz users? :D

That's exactly what I'm suggesting. However, I'm not a committer so can't do it myself...