Folks,
Off topic, so I'm going to be burning a little karma (OK, a lot).
Environment:
Window 7 64 bit
JRE 1.7.0_25
Tomcat 7.0.42 (with tcnative) run from startup.bat
I have a web application that scans for a resource path using:
this.getClass().getClassLoader().getResources(resourcePath)
It then wanders through the resources, checking the protocol for each
URL in the returned enumeration.
Based on the protocol, the URL is scanned for desired information and
the names of those resources are collected.
For a JAR file, I use the following code (don't shoot me - I'm an admin
/ architect, not a developer).
public ArrayList<String> getResources(String resourcePath,
String ending) {
JarURLConnection urlCon = null;
Pattern p =
Pattern.compile("^" + resourcePath + "/.+(" + ending + ")$");
try {
urlCon = (JarURLConnection) url.openConnection();
urlCon.setUseCaches(false);
JarFile jar = urlCon.getJarFile();
Enumeration<JarEntry> je = jar.entries();
while (je.hasMoreElements()) {
String entry = je.nextElement().getName();
if (log.isDebugEnabled()) {
log.debug("JAR entry: " + entry);
}
Matcher m = p.matcher(entry);
if (m.matches()) {
resources.add(entry);
}
}
} catch (IOException ex) {
resources.add("Could not open resource");
if (log.isErrorEnabled()) {
log.error("Could not open resource",ex);
}
} finally {
if (null != urlCon) {
urlCon = null;
}
}
return this.resources;
}
Finally,
this.getClass().getClassLoader().getResourceAsStream()
is used to obtain the resources, process them, and stuff them into a
HashMap managed by a singleton.
This is all done via a servlet context listener, and the HashMap is
emptied in the listener's contextDestroyed method.
On Linux, this all works well. I can deploy and undeploy with abandon.
The Tomcat manager reports no leaks.
On Windows, I cannot cleanly undeploy. The JAR files containing the
resourcePath (and hence the resources) remain in
%CATALINA_HOME%\webapps\appname.
However, once even a minor garbage collection occurs I can then cleanly
undeploy the web application.
I have several solutions:
1. context.xml antiResourceLocking="true"
This works, but there are a lot of downsides ( noted in the
documentation). This also indicates that an underlying InputStream is
being held open when parsing the JAR file. The solution is also Tomcat -
specific.
2. Never package the desired resources in a JAR
This works, but developers may balk. Also, the path to the desired
resources must be unique, otherwise you could still trigger loading from
a JAR (although I could just not handle JAR scanning).
3. Copy the JAR file to java.io.tmpdir, extract, and read
This is ugly, but might work. It would impact the application start up
time even more, but the JAR scanning issue would no longer exist. I
think Glassfish does this.
4. Use a properties file
Read in a properties file with a list of desired resources, and use that
list to populate the singleton. This is actually what I had in place
before, but this then requires developers to manage both the resources
and the list.
This solution also makes developing a modular, platform-independent
build system more difficult (it can be done, just creates an extra step
using Maven). Right now the build is a convoluted Ant script that
requires a specific environment. I'm trying to get away from that.
5. Do this right
How, I'm not exactly sure. Hence, the question.
/mde/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
