commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ich bin" <ichbinco...@gmx.de>
Subject Re: JavaFlow in OSGi
Date Sat, 24 Feb 2007 14:17:59 GMT
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 <tcurdt@apache.org>
An: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org

-- 
"Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ...
Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message