> I'm playing with Classloader issues in Tomcat 3.3 (but from what I hear
> it's not much different in TC 4) and the whole thing behaves really,
> really strange. This is what I can observe, with automatic reloading
> enabled:
>
> - a jar file in WEB-INF/lib will be picked up with no issues the very
> first time the application is started
> - if the jar file is changed, the application will reload (due to some
> recent fixes there in DependClassLoader), but some resources might not
> get loaded properly (for instance a properties file from within that
> jar)
> - if old version of the jar file, or a new jar file with the same binary
> of the class is returned back to WEB-INF/lib, sometimes the app will
> come back to normal after an automatic reload (not always though)
> - if you keep replacing jar file long enough with different versions, it
> will eventually fail even when loading class files from it and the whole
> app will stop working (ClassNotFoundException)
>
> I've checked the code in DependClassLoader and (unfortunately) it calls
> the parent's equivalent methods for getResourceAsStream() and
> getResource(), where parent is java.net.FactoryURLClassLoader. parent2
> is the same as class as parent, but different object (ie. another
> instance of the same thing). I'm guessing those things are part of the
> JDK.
>
> So, my real question here is, do any of you Sun guys (or any of you with
> better knowledge of JDK) know what this java.net.FactoryURLClassLoader
> actually does? Is it kind of 'caching' stuff and then it gets seriously
> confused when there are changes? Or maybe I'm doing something I'm not
> supposed to do...
>
> My environment is JDK 1.3.1_01, Linux. In some other discussions, people
> from TC 4 team mentioned that there are similar problems on Windows too.
TC 4 uses a 100% custom URLClassLoader clone, and it accesses the JARs
directly (using JarFile objects). I'm really careful about properly closing
these objects when the CL is dumped when reloading. However, there are still
problems, at least under Windows (the symptoms are roughly what you
describe). So it looks like the problems are with the java.util.jar package.
> And finally, do we just write a replacement for this (probably buggy)
> method, or is there are known workaround or fix for this?
Nope :(
Remy
