You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by "Kevin A. Burton" <bu...@openprivacy.org> on 2002/02/03 22:46:01 UTC
[PROPOSAL] 'redefine' task that uses JDK 1.4/JPDA class redefinition
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
OK.
Has anyone read about the JPDA 1.4 enhancements that have made it into JDK 1.4:
http://java.sun.com/j2se/1.4/docs/guide/jpda/enhancements.html
I am specifically talking about class redefinition. AKA the ability to
recompile and update classes within a running JVM.
This is done through JPDA and should support any application that runs within
JDK 1.4.
Some applications like Tomcat have class reloading built into them. This is
primarily due to the fact that Java has not been able to redefine classes at
runtime.
What I want to do is build a new ant task named 'redefine' that takes a
directory of .class files, compares it to a directory of deployed class files
(if available) and redefines them.
So for example one could:
<redefine host="localhost" port="2112">
<new-classes>
<fileset dir="../bin/classes" includes="**/*.class"/>
</new-classes>
</redefine>
This would connect to localhost:2112 with JPDA and redefine every class under
../bin/classes.
This isn't as easy as it sounds... there are some issues.
Specifically if you have singleton classes, these will not be reloaded. In
order to do this you have to pop entries off the stack before this class was
used.
Obviously in a lot of situations this is not desirable. We should have the
ability to enable/disable this via pop-frames="false|true" (should be false by
default)
This should provide a significant increase in functionality for both server
applications and developers.
Developers could have compile, redefine, and test (with cactus or RPC style
code) within seconds without having to wait for their ENTIRE application
reload. Application server admins will be able to redefine necessary code
without having to restart their application (think availability).
Thought?
I think this is a good idea. Of course I will contribute this to Apache if it
is requested.
The only other drawback is that this will require JDK 1.4 to compile. It might
be a good idea to put this under a CONTRIB directory.
Kevin
- --
Kevin A. Burton ( burton@apache.org, burton@openprivacy.org, burtonator@acm.org )
Location - San Francisco, CA, Cell - 415.595.9965
Jabber - burtonator@jabber.org, Web - http://relativity.yi.org/
Windows is easy to learn and hard to use, while *nix is hard to learn but easy
to use.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt
iD8DBQE8Xa+YAwM6xb2dfE0RAkzYAKC/dLJws35YStdaVHTCdmnRGT92pgCeJaG6
260llFeSASt3UjOIPrhk4z8=
=j4+F
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] 'redefine' task that uses JDK 1.4/JPDA class redefinition
Posted by Stephane Bailliez <sb...@apache.org>.
----- Original Message -----
From: "Kevin A. Burton" <bu...@openprivacy.org>
> What I want to do is build a new ant task named 'redefine' that takes a
> directory of .class files, compares it to a directory of deployed class
files
> (if available) and redefines them.
[...]
did not read it deeply but sounds good :-)
> The only other drawback is that this will require JDK 1.4 to compile. It
might
> be a good idea to put this under a CONTRIB directory.
This is not an issue we have another task dealing with JDK 1.4 (regexp
wrapper) and we have loads of conditional compilation that roughly avoid any
committer to fully build Ant. :-)
Stephane
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] 'redefine' task that uses JDK 1.4/JPDA class redefinition
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 5 Feb 2002, Peter Donald <pe...@apache.org> wrote:
>> ... can ant have sub projects?
>
> probably - never really been discussed.
It has a rather inactive one, Antidote.
> What I would suggest is to go the commons project and then develope
> it there.
+1
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] 'redefine' task that uses JDK 1.4/JPDA class redefinition
Posted by Peter Donald <pe...@apache.org>.
On Tue, 5 Feb 2002 08:02, Kevin A. Burton wrote:
> It also seems like this might be overkill. What I would actually like to
> see is an improvement to JPDA.
It maybe overkill but I can't wait for it. Can you imagine java applications
that start up *faster* that native applications? *drool*
> > > I think this is a good idea. Of course I will contribute this to
> > > Apache if it is requested.
> > >
> > > The only other drawback is that this will require JDK 1.4 to compile.
> > > It might be a good idea to put this under a CONTRIB directory.
> >
> > We can keep it in the optional hierarchy as not all of that is all
> > compiled and we can have conditional compilation there. Though it may be
> > an idea to keep it on separate project so you can release it on a faster
> > cycle than ant does releases so you can tune it faster then again - maybe
> > not ! ;)
>
> <snip/>
>
> Yeah... this is actually a good idea. One of the things I don't like about
> the ASF is that chaos needs to be harnessed a little better.
>
> ... can ant have sub projects?
probably - never really been discussed.
> The redefine task is somewhat complicated,
> should be released under its own schedule, has a number of TODO items
> associated with it, should have its own documentation, etc.
>
> Would be a shame to hide it in an optional package.
What I would suggest is to go the commons project and then develope it there.
That gives you a much easier way to to do experimentation and release stuff.
When it is ready you can pull it into ant if you like ;)
> > The big mistake that men make is that when they turn thirteen or fourteen
> > and all of a sudden they've reached puberty, they believe that they like
> > women. Actually, you're just horny. It doesn't mean you like women any
> > more at twenty-one than you did at ten. --Jules Feiffer (cartoonist)
>
> ha... I didn't realize this was your .sig... I started reading it and that
> "what the hell is he talking about" :)
:)
--
Cheers,
Pete
----------------------------------------------
Money is how people with no talent keep score.
----------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] 'redefine' task that uses JDK 1.4/JPDA class redefinition
Posted by "Kevin A. Burton" <bu...@openprivacy.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Peter Donald <pe...@apache.org> writes:
> On Mon, 4 Feb 2002 08:46, Kevin A. Burton wrote:
> > OK.
> >
> > Has anyone read about the JPDA 1.4 enhancements that have made it into JDK
> > 1.4:
> ...
> > Developers could have compile, redefine, and test (with cactus or RPC style
> > code) within seconds without having to wait for their ENTIRE application
> > reload. Application server admins will be able to redefine necessary code
> > without having to restart their application (think availability).
> >
> > Thought?
>
> Sounds interesting. There is actually JSRs in progress that will address this
> and specifically allow much cleaner and faster compartmentalization/isolation
> (which leads to faster startup times and ability to almost instantly redeploy
> apps if the different parts are isolated. However this will not be in place
> before JDK1.5 so this could be useful in some areas I expect.
It also seems like this might be overkill. What I would actually like to see is
an improvement to JPDA.
At the very minimum the ability to define new methods but also the ability to
look at a hashcode or lastModified of classes in the target VM so that you can
do differential updating.
> > I think this is a good idea. Of course I will contribute this to Apache if
> > it is requested.
> >
> > The only other drawback is that this will require JDK 1.4 to compile. It
> > might be a good idea to put this under a CONTRIB directory.
>
> We can keep it in the optional hierarchy as not all of that is all compiled
> and we can have conditional compilation there. Though it may be an idea to
> keep it on separate project so you can release it on a faster cycle than ant
> does releases so you can tune it faster then again - maybe not ! ;)
<snip/>
Yeah... this is actually a good idea. One of the things I don't like about the
ASF is that chaos needs to be harnessed a little better.
... can ant have sub projects? The redefine task is somewhat complicated,
should be released under its own schedule, has a number of TODO items
associated with it, should have its own documentation, etc.
Would be a shame to hide it in an optional package.
> The big mistake that men make is that when they turn thirteen or fourteen and
> all of a sudden they've reached puberty, they believe that they like women.
> Actually, you're just horny. It doesn't mean you like women any more at
> twenty-one than you did at ten. --Jules Feiffer (cartoonist)
ha... I didn't realize this was your .sig... I started reading it and that
"what the hell is he talking about" :)
Kevin
- --
Kevin A. Burton ( burton@apache.org, burton@openprivacy.org, burtonator@acm.org )
Location - San Francisco, CA, Cell - 415.595.9965
Jabber - burtonator@jabber.org, Web - http://relativity.yi.org/
Non-cooperation with evil is as much a duty as cooperation with good.
-- Mohandas Gandhi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt
iD8DBQE8XvbhAwM6xb2dfE0RApWqAKDPWB65YtosdonttObPeukS69jguwCgxNNl
Fn8xLevK8HkjzvWlvzIGuso=
=y9oN
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] 'redefine' task that uses JDK 1.4/JPDA class redefinition
Posted by Peter Donald <pe...@apache.org>.
On Mon, 4 Feb 2002 08:46, Kevin A. Burton wrote:
> OK.
>
> Has anyone read about the JPDA 1.4 enhancements that have made it into JDK
> 1.4:
...
> Developers could have compile, redefine, and test (with cactus or RPC style
> code) within seconds without having to wait for their ENTIRE application
> reload. Application server admins will be able to redefine necessary code
> without having to restart their application (think availability).
>
> Thought?
Sounds interesting. There is actually JSRs in progress that will address this
and specifically allow much cleaner and faster compartmentalization/isolation
(which leads to faster startup times and ability to almost instantly redeploy
apps if the different parts are isolated. However this will not be in place
before JDK1.5 so this could be useful in some areas I expect.
> I think this is a good idea. Of course I will contribute this to Apache if
> it is requested.
>
> The only other drawback is that this will require JDK 1.4 to compile. It
> might be a good idea to put this under a CONTRIB directory.
We can keep it in the optional hierarchy as not all of that is all compiled
and we can have conditional compilation there. Though it may be an idea to
keep it on separate project so you can release it on a faster cycle than ant
does releases so you can tune it faster then again - maybe not ! ;)
--
Cheers,
Pete
The big mistake that men make is that when they turn thirteen or fourteen and
all of a sudden they've reached puberty, they believe that they like women.
Actually, you're just horny. It doesn't mean you like women any more at
twenty-one than you did at ten. --Jules Feiffer (cartoonist)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] 'redefine' task that uses JDK 1.4/JPDA class redefinition
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Kevin A. Burton" <bu...@openprivacy.org>
To: "Ant Developers List" <an...@jakarta.apache.org>
Sent: Monday, February 04, 2002 12:54
Subject: Re: [PROPOSAL] 'redefine' task that uses JDK 1.4/JPDA class
redefinition
> If a redefined class has instances then all those instances will have the
fields
> defined by the redefined class at the completion of the call. Preexisting
fields
> will retain their previous values. Any new fields will have their default
> values; no instance initializers or constructors are run.
ooh.
actually this makes sense from a debug perspective, which is what JPDA is
meant to be about; the implementation of edit-and-continue
> The canUnrestrictedlyRedefineClasses functionality is what is needed but
JDK
> 1.4 doesn't support this. Of course there is also NO documentation about
when
> this will happen.
>
> God I hate closed source :(
in a couple of places in the java bugbase there are comments of mine to that
effect, roughly going "if you dont know what you are doing, leave the code
alone, and if you arent going to fix what you have done, give us the source
and let us do it ourselves". related to incompatible behaviour changes
between 1.2 and 1.3...
> Tomcat can't do dynamic reloading. It can't reload a single class. It
has to
> reload whole web contexts. It may seem that you are just reloading one
class
> but really the ClassLoader just obsoleted itself and the new classloader
> redefines clases.
ok, maybe it was bluestone then, I forget. All I know is now my code to
retrieve a servlet context validates what we got back rather than just
assumes that it is ok, even though being an immutable object its state
should always be valid.
-steve
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] 'redefine' task that uses JDK 1.4/JPDA class redefinition
Posted by "Kevin A. Burton" <bu...@openprivacy.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
"Steve Loughran" <st...@iseran.com> writes:
> What happens to objects which are stored in data structures after a reload if
> the no. or position of fields change?
Good question which is hard to find the answer to:
If a redefined class has instances then all those instances will have the fields
defined by the redefined class at the completion of the call. Preexisting fields
will retain their previous values. Any new fields will have their default
values; no instance initializers or constructors are run.
The canUnrestrictedlyRedefineClasses functionality is what is needed but JDK
1.4 doesn't support this. Of course there is also NO documentation about when
this will happen.
God I hate closed source :(
> I ask as I had an experience on Tomcat 3.x with a dynamic reload of a servlet
> where an object saved to the ServletContext was still there, even after the
> classes signature changed.
yes... you can handle this.
> That's one reason I dont use dynamic reloading any more; just restart the
> whole web app.
Tomcat can't do dynamic reloading. It can't reload a single class. It has to
reload whole web contexts. It may seem that you are just reloading one class
but really the ClassLoader just obsoleted itself and the new classloader
redefines clases.
For the time being the Redefine task will have to go hand and hand with web
application reloading. They both have their advantages.
Kevin
- --
Kevin A. Burton ( burton@apache.org, burton@openprivacy.org, burtonator@acm.org )
Location - San Francisco, CA, Cell - 415.595.9965
Jabber - burtonator@jabber.org, Web - http://relativity.yi.org/
Questions are the beginning of wisdom.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt
iD8DBQE8XvT0AwM6xb2dfE0RArjwAJ44FQyAKWZ6SRCXTAt7JwXsIZEv9QCcDf0O
+9DOqP8846C0LaI2ts8WxOs=
=6nI/
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] 'redefine' task that uses JDK 1.4/JPDA class redefinition
Posted by Steve Loughran <st...@iseran.com>.
What happens to objects which are stored in data structures after a reload
if the no. or position of fields change?
I ask as I had an experience on Tomcat 3.x with a dynamic reload of a
servlet where an object saved to the ServletContext was still there, even
after the classes signature changed.
That's one reason I dont use dynamic reloading any more; just restart the
whole web app.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] 'redefine' task that uses JDK 1.4/JPDA class redefinition
Posted by "Kevin A. Burton" <bu...@openprivacy.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
David Jencks <da...@directvinternet.com> writes:
> While this is certainly an interesting proposal, I don't think it is ready to
> replace application server class management/application redeployment.
... of course... not right now :)
JPDA in JDK 1.4 doesn't not support defining new methods. This sucks.
hopefully this will be fixed soon.
> --Application server class management usually gives you the ability to remove
> classes entirely from at least part of the classloader picture.
Have you ever looked into the mechanisms that applications use to reload.??
Very ugly stuff. At least with JPDA I feel WAY more confident.
... and no... you can't REMOVE classes but neither can anything else.
Application server reloaders can't remove a class either. It is just defined in
an orphaned ClassLoader.
With this mechanism the class will remain in the same classloader but won't be
called.
> --It does not appear possible from a quick glance to be able to change
> resources loaded by a classloader.
<snip/>
Hm... I put that on the TODO list. It is a good point. I can directly invoke
methods on the remote ClassLoader via ObjectReference.invoke. It does appear
that you can define classes that aren't available otherwise.
I could probably find out a way to include resources.
Kevin
- --
Kevin A. Burton ( burton@apache.org, burton@openprivacy.org, burtonator@acm.org )
Location - San Francisco, CA, Cell - 415.595.9965
Jabber - burtonator@jabber.org, Web - http://relativity.yi.org/
For evil to win, is for good men to do nothing.
- Winston Churchill.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt
iD8DBQE8Xj4kAwM6xb2dfE0RAr9dAJ45q109Npk8MeHJb+WyXmKg2I32SgCgnS9h
vx26I6M2uytxF0u46j1BxRc=
=n5rc
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] 'redefine' task that uses JDK 1.4/JPDA class redefinition
Posted by David Jencks <da...@directvinternet.com>.
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" <vm...@octo.com> 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 ( burton@apache.org, burton@openprivacy.org,
> burtonator@acm.org )
> Location - San Francisco, CA, Cell - 415.595.9965
> Jabber - burtonator@jabber.org, 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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] 'redefine' task that uses JDK 1.4/JPDA class redefinition
Posted by "Kevin A. Burton" <bu...@openprivacy.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
"Vincent Massol" <vm...@octo.com> 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 ( burton@apache.org, burton@openprivacy.org, burtonator@acm.org )
Location - San Francisco, CA, Cell - 415.595.9965
Jabber - burtonator@jabber.org, 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PROPOSAL] 'redefine' task that uses JDK 1.4/JPDA class redefinition
Posted by Vincent Massol <vm...@octo.com>.
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 ?
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 ? This is probably what JPDA of JDK 1.4 is
about : have this feature built into the JVM instead of in the code ...
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).
-Vincent
> -----Original Message-----
> From: burton@universe.yi.org [mailto:burton@universe.yi.org] On Behalf
Of
> Kevin A. Burton
> Sent: 03 February 2002 21:46
> To: ant-dev@jakarta.apache.org
> Subject: [PROPOSAL] 'redefine' task that uses JDK 1.4/JPDA class
> redefinition
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> OK.
>
> Has anyone read about the JPDA 1.4 enhancements that have made it into
JDK
> 1.4:
>
> http://java.sun.com/j2se/1.4/docs/guide/jpda/enhancements.html
>
> I am specifically talking about class redefinition. AKA the ability
to
> recompile and update classes within a running JVM.
>
> This is done through JPDA and should support any application that runs
> within
> JDK 1.4.
>
> Some applications like Tomcat have class reloading built into them.
This
> is
> primarily due to the fact that Java has not been able to redefine
classes
> at
> runtime.
>
> What I want to do is build a new ant task named 'redefine' that takes
a
> directory of .class files, compares it to a directory of deployed
class
> files
> (if available) and redefines them.
>
> So for example one could:
>
> <redefine host="localhost" port="2112">
>
> <new-classes>
>
> <fileset dir="../bin/classes" includes="**/*.class"/>
>
> </new-classes>
>
> </redefine>
>
> This would connect to localhost:2112 with JPDA and redefine every
class
> under
> ../bin/classes.
>
> This isn't as easy as it sounds... there are some issues.
>
> Specifically if you have singleton classes, these will not be
reloaded.
> In
> order to do this you have to pop entries off the stack before this
class
> was
> used.
>
> Obviously in a lot of situations this is not desirable. We should
have
> the
> ability to enable/disable this via pop-frames="false|true" (should be
> false by
> default)
>
> This should provide a significant increase in functionality for both
> server
> applications and developers.
>
> Developers could have compile, redefine, and test (with cactus or RPC
> style
> code) within seconds without having to wait for their ENTIRE
application
> reload. Application server admins will be able to redefine necessary
code
> without having to restart their application (think availability).
>
> Thought?
>
> I think this is a good idea. Of course I will contribute this to
Apache
> if it
> is requested.
>
> The only other drawback is that this will require JDK 1.4 to compile.
It
> might
> be a good idea to put this under a CONTRIB directory.
>
> Kevin
>
> - --
> Kevin A. Burton ( burton@apache.org, burton@openprivacy.org,
> burtonator@acm.org )
> Location - San Francisco, CA, Cell - 415.595.9965
> Jabber - burtonator@jabber.org, Web -
http://relativity.yi.org/
>
> Windows is easy to learn and hard to use, while *nix is hard to learn
but
> easy
> to use.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt
>
> iD8DBQE8Xa+YAwM6xb2dfE0RAkzYAKC/dLJws35YStdaVHTCdmnRGT92pgCeJaG6
> 260llFeSASt3UjOIPrhk4z8=
> =j4+F
> -----END PGP SIGNATURE-----
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>