You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by ich bin <ic...@gmx.de> on 2007/02/23 12:33:12 UTC
JavaFlow in OSGi
Dear all,
I would like to know that if ContinuationClassloader is compatible with the standard ClassLoader mechanism in OSGi runtime environments(like Knopflerfish,etc....).
Second question is that can anyone provide me code snippets to prove that Continutation object can be serialized and can be reuse in another host running different type of JVM to the source one? In theory, I understand that Continuation object is implemented based on Serialization mechanism and this mechanism conforms across multiple implementations of JVMs. However, I would prefer to have a look insight.
Kind regards,
Conan.
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: JavaFlow in OSGi
Posted by ich bin <ic...@gmx.de>.
Hi Torsten Curdt,
> I suggest you read this paper http://vafer.org/blog/20061206232546 to
> understand the mechanism behind javaflow.
It sounds promising. Did you provide your well-done project "Continuation-based Mobile Agents" as an open source one somewhere? Or I just want to have a look insight how Javaflow can be utilized to capture current states of mobile agents from an external thread outside, therefore can you give me just some snippets of code?
Kind regards,
Conan.
--
"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
[javaflow] Re: JavaFlow in OSGi
Posted by Torsten Curdt <tc...@apache.org>.
> 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?
That's not what continuations are really about ...sounds you are more
after thread serialization. For javaflow you have call out and tell
when you want to suspend ...at least that's how it is now.
That being said triggering the suspend from an external Thread should
be possible. Of course that raises concurrency issues that need to be
solved. (I have actually already played with that some while ago)
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: JavaFlow in OSGi
Posted by ich bin <ic...@gmx.de>.
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 <tc...@apache.org>
An: "Jakarta Commons Developers List" <co...@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
Re: JavaFlow in OSGi
Posted by Torsten Curdt <tc...@apache.org>.
>>> 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
Re: JavaFlow in OSGi
Posted by ich bin <ic...@gmx.de>.
Dear Mr. Torsten Curdt,
Many thanks for your reply.
> > 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. My question is that can ContinuationClassloader can live together with the OSGi standard Classloader peacefully?
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?
Kind regards,
Conan.
--
"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
Re: JavaFlow in OSGi
Posted by Torsten Curdt <tc...@apache.org>.
> 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?
> Second question is that can anyone provide me code snippets to
> prove that Continutation object can be serialized and can be reuse
> in another host running different type of JVM to the source one? In
> theory, I understand that Continuation object is implemented based
> on Serialization mechanism and this mechanism conforms across
> multiple implementations of JVMs. However, I would prefer to have a
> look insight.
http://svn.apache.org/viewvc/jakarta/commons/sandbox/javaflow/trunk/
src/test/org/apache/commons/javaflow/bytecode/transformation/tests/
AbstractSerializationTestCase.java?revision=413604&view=markup
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org