Hi, >From the tutorial of how to program with Javaflow, I have just only learned >that we can obtain the continuation object of one thread if we insert some a >statement "Continuation.suspend" within its funtions/procedures: http://jakarta.apache.org/commons/sandbox/javaflow/tutorial.html
Let's assume that I have a class extends Thread and it is complied and packed in a file of .jar format. Addtionally, I consider the class as a black box. How can I acquire the continuation object of this class in any random instant point of time? Is it mandatory to inject/weave "Continuation.suspend" into its all functions in order to capture its states? Kind regards, Conan. -------- Original-Nachricht -------- Datum: Fri, 23 Feb 2007 15:58:35 +0100 Von: Torsten Curdt <[EMAIL PROTECTED]> An: "Jakarta Commons Developers List" <[email protected]> CC: Betreff: Re: JavaFlow in OSGi > >>> I would like to know that if ContinuationClassloader is compatible > >>> with the standard ClassLoader mechanism in OSGi runtime environments > >>> (like Knopflerfish,etc....). > >> > >> What's the exact meaning of "compatible" here? > >> > > > > As I understand that Javaflow has a typical class ...bytecode.Stack > > object which serves as a "virtual" stack in the memory and over it, > > we have a full control. The class looks like every normal class > > has to be either treated statically with the Javaflow ant task, or > > loaded by javaflow's ContinuationClassLoader which instruments the > > code at runtime. Thus, you can replay the stack whenever it is > > needed. The problem with this approach is that in OSGi, the > > classloading is crucial and cannot be easily replaced by a > > different classloading mechanism. > > Ehm ...I am far from being an OSGi expert but I recall that this > should not be a problem ...at least according to the discussion we > had over at Cocoon. > > > My question is that can ContinuationClassloader can live together > > with the OSGi standard Classloader peacefully? > > As of now I can only say "maybe" ...or "probably". As I have never > tried that myself. > > But maybe the real question is - does it have to? As far as I know > OSGi already support reloading ....maybe the right way is to have a > look how OSGi loads the classes and then hook in there. I would be > very interested in pursuing this question further. > > > Well, I also think that how this class could work among different Java > > VMs. The layout of the stack heavily depends on the implementation > > of the > > JVMs. Without verifying, I assume that if you have a Sun VM and a > > VM using the GNU Classpath, this is very likely to fail. Are my > > arguements absolutely wrong? > > Well... yes, they are wrong :) > > I suggest you read this paper http://vafer.org/blog/20061206232546 to > understand the mechanism behind javaflow. > > As long as the the class layout stays the same - what is on the stack > should also stay the same. This is dependent on the underlying byte > code - not the jvm implementation of it. (Although different > compilers could create different class layouts) But every jvm should > do the same on the same class layout - otherwise we all have a big > problem ;) > > Just make sure to keep the original .class alongside with the > continuation and you should be fine - even across different jvms. > > HTH > > cheers > -- > > Torsten > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- "Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ... Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
