While this is certainly an interesting proposal, I don't think it is ready to replace application server class management/application redeployment.
--Application server class management usually gives you the ability to remove classes entirely from at least part of the classloader picture. --It does not appear possible from a quick glance to be able to change resources loaded by a classloader. david jencks On 2002.02.03 19:51:40 -0500 Kevin A. Burton wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > "Vincent Massol" <[EMAIL PROTECTED]> writes: > > > Kevin, > > > > I like your idea. However, I don't see what benefit it will bring for > server > > side development as all (or almost all) existing containers already > support > > dynamic reloading. For example, to run my Cactus tests, I do no start > and stop > > the application server but simply drop the new WAR (or EAR) over the > existing > > one. Am I missing something ? > > Yes... there are a number of issues: > > 1. Why do all application servers write the same class reloading code? > Duplication of effort and it isn't preserving separation of concerns. > this > should be dropped in favor of of a JPDA based mechanism (AKA the > Redefine > task) > > 2. Not everyone can use WAR reloading. We use it within Reptile and it > takes > about 20-30 seconds to reload the whole app. JPDA could do this > almost > instantaneously. > > 3. You can debug application that currently do not have application > reloading. > > 4. JPDA can do differential class reloading. IE if you have singletons > you > don't want to destroy these because you don't want to loose data. > With JPDA > I can redefine certain classes and not the whole application. > > Right now we run Tomcat with a 'reloadable' WAR. There are significant > issues > with this. I had to spend a lot of time making sure my application could > be > destroyed and restared. It also takes a LONG time (30 seconds) to > restart even > when complex tasks are disabled. > > With the Redefine task I could redefine in < 1 second. > > The only time this will change is when we need to pop frames off thread > stacks > in order to redefine the class. > > > Or do you want to externalize the dynamic reloading feature (in an Ant > task) > > so that containers or other type of code that do not already have this > feature > > can still benefit from it, i.e. generalize it by taking it outside of > the code > > base ? > > That is one of the reasons. > > > This is probably what JPDA of JDK 1.4 is about : have this feature > built into > > the JVM instead of in the code ... > > Yes... the docs mention this. > > > On a slightly different subject I am very interested by JPDA to provide > easy > > interception mechanisms for in-container testing with Cactus (to > provide > > hook-points in the container instead of having to provide explicit > redirectors > > at application package time), thus making the test process transparent > from > > the point of view of the application (in other words, no modification > > whatsoever to the WAR/EAR, only runtime modification to loaded classes > during > > the tests). > <snip/> > > Hm.. you mean you want to install/deploy classes under the remote VM that > by > default doesn't have them? AKA you want to install Cactus tests, and > libraries > under a target VM? > > I think it is a good idea but I don't think JPDA will support this. I > believe > that you can not DEFINE classes you can only REDEFINE them. > > Maybe in JDK 1.5 :) > > BTW... I am about 2/3 done a proof of concept task... > > Kevin > > - -- > Kevin A. Burton ( [EMAIL PROTECTED], [EMAIL PROTECTED], > [EMAIL PROTECTED] ) > Location - San Francisco, CA, Cell - 415.595.9965 > Jabber - [EMAIL PROTECTED], Web - http://relativity.yi.org/ > > Fist in the air in the land of hypocrisy! > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.6 (GNU/Linux) > Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt > > iD8DBQE8XdscAwM6xb2dfE0RAk3kAJwPF3AbqC408tsQW0c63yknOILFVwCdEfR0 > rkKHrFjEYS1/1Up53wLmYXw= > =BO4F > -----END PGP SIGNATURE----- > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
