Remy Maucherat <[EMAIL PROTECTED]> wrote:
It *does* delegate to its parent classloader (which is WebappClassLoader)
The only difference is that my solution sets useCaches to false on obtained URLConnection before opening an InputStream.
There are no repositories related with JasperLoader.
Look:
in o.a.j.c.JDTCompiler there is such an invocation in findType(String)
is = classLoader.getResourceAsStream(resourceName);
classLoader is an instance of JasperLoader, which does not override j.n.URLClassLoader.getResourceAsStream(String)
Since there is also no getResourceAsStream in its superclass j.n.URLClasLoader, ClassLoader's implementation getResourceAsStream(String) is used
It (java.lang.ClassLoader) is implemented like this:
public InputStream getResourceAsStream(String name) {
URL url = getResource(name);
try {
return url != null ? url.openStream() : null;
} catch (IOException e) {
return null;
}
}
Notice that openStream() is a short for getConnection().getInputStream().
As you can clearly see after applying my "hack" after an invocation of
is = classLoader.getResourceAsStream(resourceName);
"is" is assigned an InputStream opened on an *uncached* JarURLConnection.
There are other solutions:
- modify findType to use getResource instead of getResourceAsStream
- have JasperLoader.getResourceAsSteam (and possibly getResource as well) do nothing and delegate to parent.getResourceAsStream (and getResource)
I think I like the second one.
I didn't quite realize how this was working with the dependecies. The use of getResource would prevent caching (although the JAR wouldn't need to be found again), while using the parent's getResourceAsStream should speed up compilation a little (since the binary content of the class is only loaded once).
Te question arises - is there any benefit of having cached JarURLConnection??
Well, it locks your files, therefore hinting that you should be using Linux or something.
Seriously, I don't know the answer to that, but I imagine it could have consequences (the amount of accesses is not insignificant if there are lots of depedencies).
I haven't checked that in the sources of jdk as java.net.JarURLConnection is abstract and implemented in sun.net.www.protocol.jar.JarURLConnection.
Rémy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
