cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian McCallister <bri...@apache.org>
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  
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