On Apr 16, 2008, at 12:18, Saskia Heesen wrote:
Hello everybody!
I would like to use javaflow from Cocoon 2.2 since javaflow offers
more ways to test the code than flowscript. When I run the example I
get the error message:
2008-04-16 11:18:13,839 ERROR http-8080-Processor25
org.apache.commons.javaflow.bytecode.StackRecorder - stack
corruption. Is class org.apache.cocoon.components.flow.java.Invoker
instrumented for javaflow?
java.lang.IllegalStateException: stack corruption. Is class
org.apache.cocoon.components.flow.java.Invoker instrumented for
javaflow?
I think the main difference between Cocoon 2.1 and Cocoon 2.2
regarding javaflow is that javaflow is now based on
commons.javaflow. commons.javaflow needs an enhancement of these
classes, that are part of the continuation. So, we can't use the
default system class loader. However, commons.javaflow provides an
appropriate ContinuationClassLoader.
JavaInterpreter.java as part of cocoon-javaflow-impl still uses the
default system class loader:
final Class clazz =
Thread.currentThread().getContextClassLoader().loadClass(clazzName);
My idea is to replace it by ContinuationClassLoader
That's not a really good idea. In 2.2 javaflow basically works hand in
hand with the RCL from JCI.
The idea is that you can basically point cocoon to your eclipse
environment and JCI will pickup the class file changes whenever you
change a class through eclipse ...and it will instrument it. This is
for development.
For deployment the idea is that you should include the instrumentation
phase into your build process. Unfortunately there is still only an
ant task for it. The idea was to write a maven jci compiler plugin
that would essentially replace the original maven one. Being more
flexible and supporting things like instrumentations on compile time.
But as I don't see that happen in the near future it might be easier
to just turn the ant task into a very simple maven javaflow
plugin ...or call the ant task from maven.
Important thing to note is that in 2.2 the instrument/don't
instrumentation is handled via class separation - not a marker
interface. So essentially you have one jar with your custom classes
and one jar with your flow that should have been instrumented.
HTH
cheers
--
Torsten
