I think I finally found it. And fixed it.
JDTCompiler uses JasperLoader.getResourceAsStream() which is *not* overriden in JasperLoader and uses getResourceAsStream() derived from java.net.URLClassLoader (in fact from java.lang.ClassLoader). j.l.ClassLoader's getResourceAsStream() implementation does not setUseCaches(false), therefore causes locking. I suggest overriding getResourceAsStream in JasperLoader by adding the following (or similar) method:
public InputStream getResourceAsStream(String name) {
URL url = getResource(name);
if (url != null) {
try {
URLConnection urlc = url.openConnection();
urlc.setUseCaches(false);
return urlc.getInputStream();
} catch (IOException e) {
return null;
}
}
return null;
}
This actually *WORKS* for me.
It's a hack though. JasperLoader shouldn't have the JARs in its repositories, so it is supposed to delegate.
PS. I hope that I don't get cursed again.
It's easy: don't be annoying, and avoid whining.
For example, what's up with that bug ? http://issues.apache.org/bugzilla/show_bug.cgi?id=32746 Is it relevant or not ?
Rémy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
