[EMAIL PROTECTED] wrote:
>
> On Sat, 15 Sep 2001, Bojan Smojver wrote:
>
> > - 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)
>
> What do you mean ( i.e. how do you load the properties ) ? We create a new
> loader, and getting resources with the new loader should return the new
> stuff ( I'm not sure for Bundles, maybe they're caching something - need
> to check ).
>
I have used Tomcat 4 with resource bundles, and when the manager does a reload
of a webapp the new property files are used. All OK.
> > - 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)
>
> Again, need more details.
>
> > 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.
>
> DependClassLoader is a wrapper around the real webapp loader - it's role
> is to record dependencies.
>
> Parent is the real loader, parent2 is the grand-parent ( the parent of
> all webapps ). If a resource can be loaded by parent2, it is loaded
> ( to respect the delegation rules ). If not, we get the resource from
> parent ( i.e. from the application WEB-INF ).
>
> The class is created by DependClassLoader so class deps will also go
> to DCL ( and we can record them ).
>
> URLClassLoader is the standard JDK1.2+ loader. It has some important
> features besides loading classes - it checks sealing, load the right
> security context, and many other things that are imporant.
>
> You can of course replace it with anything you want - including
> SimpleClassLoader or replacement. All you need to do is replace
> LoaderInterceptor with your custom-made one.
>
> > 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...
>
> If you can provide more details, I can take a look. Reloading seems to
> work fine for me ( but I'll try again ).
>
> > And finally, do we just write a replacement for this (probably buggy)
> > method, or is there are known workaround or fix for this?
>
> We must first find out which of the buggy methods we need to replace :-)
>
> Costin
--
----------------------------------------------------------------------
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
