commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <tcu...@apache.org>
Subject Re: [javaflow] MethodLookup
Date Fri, 29 Jul 2005 11:28:16 GMT
>> 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.)

Had a look into your implementation
...you have the "run" method delegating to
the different methods.

If you want to get rid of the of the method
lookup you do need to pass in the Runnable
also to the continueWith ...not sure if I
like that.

I had similar idea in the beginning:

  startWith(Method, ContinuationContext)
  continueWith(Method, Continuation, ContinuationContext)

What I did not like: Passing in of the
Continuation already implies the Method.

Beforehand the method was saved inside
the Continuation object. But this does
not work when it comes down to serialization.

BTW: IIRC I needed to mark the static as
transient for the XStream serialization
...but not totally sure.

> 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.

Well ...it's still marked alpha so as long
as it makes sense to me I am fine changing
it.

But TBH I currently would like to focus on
the current bytecode rewriting stuff first
before changing the API that much.

> 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()

Hm... it's shorter but I don't like it.
It's not obvious where the context comes
from.

I would -1 that one.

> 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.

I don't understand this forking and cloning
stuff - you don't need that. A continuation
should be re-entrant and always create a new
one as a result.

> 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.

If you don't mind I would prefer if you keep
that code in your codebase for now. Let's get
back to that once we have the rewriting based
on ASM in place. I would like to focus on the
hard part first ;)

Would that be ok for you?

cheers
--
Torsten

Mime
View raw message