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