cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephan Michels <>
Subject Re: Groovy support in Cocoon
Date Mon, 05 Apr 2004 09:30:42 GMT
Am So, den 04.04.2004 schrieb Christopher Oliver um 20:32:
> Stefano Mazzocchi wrote:
> >
> > 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.

Yes, that's correct, the complete stacktrace must be 'instrumented' to
restore the continuation. I thought about it a long time to get
an idea how fix this problem, but I get no idea :-/

BTW, I must add a flag to the Continuation Class, to mark the
continuation as disabled for calling uninstrumented code.

> 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.

Are you talking about instrumenting at compile time?

> 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.

Yes, I think it's a good idea. It's same problem like specifying the
pointcuts in AOP.


View raw message