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 Sun, 04 Apr 2004 18:32:58 GMT
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