I would suggest to fix it in all places where urls are used for opening
a stream. That wouldn't limit the patch to web applications.
As far as I understand we must modify the code
in XMLResourceProcessor, MessageFinderImpl, and URLResource.
Before:
URL url = resource.getResourceURL();
return new InputSource(url.getInputStream());
After:
URL url = resource.getResourceURL();
URLConnection conn = url.openConnection();
conn.setUseCaches(false);
return new InputSource(conn.getInputStream());
Achim
Am Fri, 01 Dec 2006 10:59:33 +0100 schrieb Knut Wannheden
<[EMAIL PROTECTED]>:
Hi Jim,
Thanks for the detailed problem description. I suppose we could add
this piece of code to the HiveMindFilter class. Other opinions?
--knut
On 12/1/06, Jimr <[EMAIL PROTECTED]> wrote:
I am writing this to document a resolution to a problem I have found
while
running HiveMind within a servlet container on Windows and the way that
HiveMind searches for xml files within jars on the classpath
(hivemodule.xml, etc)
This is specific to windows, and its file locking behaviour.
Environment: Windows XP SP2, JDK 1.5.0_05, HiveMind 1.1.1, Tomcat 5.5.12
Problem: When undeploying a webapp that uses HiveMind, the
Hivemind-1.1.1.jar, Hivemind-lib-1.1.1.jar (and any other jars that
contain
Hivemind module descriptors) within the webapp are locked and cannot be
deleted. This results in a failure to undeploy the webapp. If the
servlet
container (Tomcat) is shut down, the lock is released and the jars can
be
deleted.
XMLResourceProcessor involvement: This class appears to be involved in
searching for module descriptors on the classpath using a url. However
it
does not set caching to false before doing the url.openStream() call.
This
means that all the jars that it opens get locked by windows.
Root cause: Jar access using a URL with caching enabled. See:
[url]http://forum.springframework.org/archive/index.php/t-19516.html[/url]
[url]http://tomcat.apache.org/faq/windows.html#lock[/url]
Resolution:
Make sure the following code is ran before instantiating HiveMind (can
use
ServletContextListener for example):
[code]
try
{
if(System.getProperty("os.name").contains("Windows"))
new
URL("http://This-is-just-to-get-the-URLConnection";).openConnection().setDefaultUseCaches(false);
}
catch (IOException e)
{
e.printStackTrace();
}
[/code]
This is a vm-wide setting so it will affect all url connections. Why
isn't
this code cleaner? See:
[url]http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4851466[/url]
[url]http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4405789[/url]
I hope this helps anyone else in the same situation!
Maybe the code could also be in HiveMind itself? I'll leave that to the
dev
team.
There are three files in total that contain this type of code:
XMLResourceProcessor.java, MessageFinderImpl.java, and URLResource.java
Jim
--
View this message in context:
http://www.nabble.com/HiveMind-1.1.1---jar-locking---XMLResourceProcessor-tf2735127.html#a7630408
Sent from the Hivemind - User mailing list archive at Nabble.com.
