commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kohsuke Kawaguchi <kohsuke.kawagu...@sun.com>
Subject Re: [javaflow] MethodLookup
Date Fri, 29 Jul 2005 05:51:10 GMT
Torsten Curdt wrote:
>> If I understand this correctly, for me to capture the continuation and
>> run it later, I do:
> 
> Have a look into the serialization testcase

Thanks. I did some experiments. I think I have misunderstood the way the 
stack restoration works. It seems like it's actually replacing local 
variable #0 (the 'this' pointer.)

This is interesting. I didn't know that you can do this in Java (I guess 
you can do it in JVM, just not in Java language.)





>> (I'm assuming that you designed ContinuationContext to
>> keep track of things you want to change between runs, so it's not  
>> reachable from Continuation if it's not executing.)
> 
> Sorry, did not get that ..what do you mean?
> 
> The ContinuationContext holds all the references
> that are required to restore the state but cannot
> really be part of the continuation. Logger,
> ComponentManager and things like that.

Yes, I think we are saying the same thing. Pardon my poor English.


> See the example in my blog ...which is actually
> taken from the Cocoon integration. (I think in
> there is also the link to the class) Would be
> great if you could also have a look into that
> class.

I looked at Cocoon code you had in [1]. I didn't particularly see 
anything that made me rethink (IOW, I don't see anything that absolutely 
requires MethodLookup nor ContinuationContext instead of Runnable.)

But at the same time, I saw that you have some existing investments with 
the current javaflow Continuation API and it's very understandable that 
you don't want it to change.

I see the desire to pass some contextual information to the invoked 
method, but that is a fairly common requirement even if you aren't using 
javaflow at all. javaflow just keeps it and stores it somewhere for 
later retrieval, which can be better done by the code that knows what 
the scope of a given context object is (like ThreadLocal, singleton, 
HttpSession, etc.)


Just to make sure that I'm not missing something, I rewrote the 
JavaInterpreter and CocoonContinuationContext by using the 
ContinuationThread class (which I renamed to Fiber) instead of the 
current Continuation API. The only difference is that you now do:

CocoonContinuationContext.getCurrent()

instead of:

(CocoonContinuationContext)Continuation.currentContinuation().getContext()

See the attachments for the exact code. All in all, I didn't think this 
re-write is ugly, but that is always a subjective issue.


Anyway, I'm no longer too keen about convincing you to change the API of 
the Continuation class. If you like my rewrite, that's good, but if not, 
that's also fine with me. The current Continuation API makes the Fiber 
class implementation uglier, but that's not too big a problem.

Instead, I'm hoping that you allow me to commit this Fiber class to 
javaflow, as this is what I primarily want to use in my code.



[1] http://svn.apache.org/repos/asf/cocoon/blocks/javaflow/trunk/
-- 
Kohsuke Kawaguchi
Sun Microsystems                   kohsuke.kawaguchi@sun.com

Mime
View raw message