cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <tcu...@apache.org>
Subject Re: javaflow / URL of jar
Date Wed, 16 Apr 2008 12:36:33 GMT

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

Mime
View raw message