I think the answer is that this is not how it is supposed to work. ClasspathResourcesUtil.getStream() calls ClassLoaders getResourceAsStream or getResource depending on if it wants a cached version of the resource or not.
According to the docs for org.apache.catalina.loader.WebappClassLoader this is correct. Only for whatever reason after a reload of the context, getResourceAsStream returns the most current version of the resource. And getResource() returns the older version. getResourceAsStream does not find the resource in its cache(makes sense if this is a new class loader) and returns the new updated version. The simple fix would be to swap the conditional logic in ClasspathResourceUtil. Turn the if (cache) into if (!cache). This business of returning a previously cached version is a concept introduced by the WebappClassLoader. At the java.lang.ClassLoader level getResourceAsStream is a simple wrapper on getResource. So maybe it is okay to take into account how the code works rather than how it is documented to work. Am Freitag, 28. Juli 2006 13:28 schrieb Chris Miner: > I see that there is a bit of infrastructure in place to redeploy module > files and access module resources during development. However it doesn't > seem to work for me. At least not the way I want it too. I have to > restart my tomcat instance and redeploy in order for the new changes to be > available. It does not seem to be enough that the magnolia context is > restarted. > > Is this how it is supposed to work? I don't know much about class loaders > and contexts, but it seems odd that classes come out of the new jar, but > not the resources. > ---------------------------------------------------------------- for list details see http://www.magnolia.info/en/magnolia/developer.html ----------------------------------------------------------------
