cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Oliver <res1c...@verizon.net>
Subject Re: Groovy support in Cocoon
Date Mon, 05 Apr 2004 02:42:19 GMT
The current implementation needs some work to qualify as "generalized 
Java continuations". It would be nice to make it work more like Scheme 
continuations:

1) When you access the "current" continuation, it captures the call 
stack up to but not including the current method (and makes a (shallow) 
copy of it). The current method continues as normal. The reason for 
making a copy is to prevent further modification of the captured 
continuation stack as the method call stack unwinds (see below).
2) To resume a continuation you invoke it - like a method call through 
reflection - and you can pass an object to this call (which becomes the 
return value of the method where the continuation was created).
3) Before the continuation is resumed another copy of the stack is made 
(the original continuation stack is treated as an immutable object). 
This makes it possible to invoke the continuation more than once.

It's possible to make the stack copying occur lazily as an optimization 
(in case another continuation is invoked the method at the top of the 
stack never returns so copying the remaining frames isn't necessary).

Chris

Brian McCallister wrote:

> I will be surprised if continuations based around the Cocoon javaflow  
> implementation don't leak into Groovy CVS based on the amount of  
> chatter in #groovy about continuations.
>
> I know James wants this very much, and hacked out a way to do it via  
> exceptions once (and hacked is the correct word), but has been 
> waiting  for generalized Java continuations rather than hack it into 
> the  language.
>
> -Brian
>
> On Apr 4, 2004, at 2:32 PM, Christopher Oliver wrote:
>
>> Stefano Mazzocchi wrote:
>>
>>> Antonio Gallardo wrote:
>>>
>>>> Hi:
>>>>
>>>> Hi:
>>>>
>>>> Some of us wanted to see Groovy support in Cocoon. Now we can 
>>>> "play"  a
>>>> little with Groovy using the recently added support for Groovy script
>>>> generator under the BSF block. More info about how to use it is here:
>>>>
>>>> http://cocoon.apache.org/2.1/userdocs/generators/script- 
>>>> generator.html
>>>>
>>>> SITEMAP CONFIGURATION FOR GROOVY:
>>>> ======================
>>>>
>>>> In components section add:
>>>>
>>>> <map:generator name="script"
>>>>     src="org.apache.cocoon.generation.ScriptGenerator"
>>>>     logger="sitemap.generation.scriptgenerator">
>>>>   <!-- Groovy support -->
>>>>   <add-languages>
>>>>     <language name="groovy"  
>>>> src="org.codehaus.groovy.bsf.GroovyEngine">
>>>>       <extension>groovy</extension>
>>>>       <extension>gy</extension>
>>>>     </language>
>>>>   </add-languages>
>>>> </map:generator>
>>>>
>>>> I hope this will have a good welcome in the Cocoon Community.
>>>>
>>>> Best Regards,
>>>>
>>>> Antonio Gallardo
>>>>
>>>
>>> Next I would like to see is a groovy implementation of flow ;-)
>>>
>> It should be _fairly_ straightforward. The only tricky part I see is  
>> controlling the byte-code transformation. All methods in the  
>> call-chain leading from the method invoked by  
>> Interpreter.callFunction()  to sendPageAndWait() or any other method  
>> that creates a continuation must be instrumented. The current  
>> implementation only instruments classes that implement the interface  
>> "Continuable". In the case of scripting languages like Groovy, 
>> Jython,  or Rhino, pretty much the entire interpreter and all classes 
>> generated  from scripts will need to be instrumented. Any callbacks 
>> from  non-instrumented code to instrumented code will break the  
>> continuation.
>>
>> One approach might be to instrument the build system to rename class  
>> files that require instrumentation to have a special extension  
>> (".iclass" or whatever) making them invisible to normal class 
>> loaders  but recognizable to the class loader that performs the 
>> byte-code  transformation.
>>
>> Another possible approach is to provide a configuration to the class  
>> loader using wildcard specifications (e.g. "groovy.*", etc) to allow  
>> it to identify which classes to instrument.
>>
>> Chris
>>
>
>
>
>


Mime
View raw message