cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian McCallister <>
Subject Re: Groovy support in Cocoon
Date Mon, 05 Apr 2004 01:13:00 GMT
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  


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:
>>> generator.html
>>> ======================
>>> 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

View raw message