-----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]>
