Re: Groovy support in Cocoon

[Brian McCallister]

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