Hey Torsten! I have been watching the mailinglist for the last year or so to see changes in javaflow in 2.2 which I would love to use.
It seems that you are the only one with the "complete" knowledge to finish javaflow in 2.2... I am sure there are others around which would like to help to get the job done. but my feeling so far is that it would be only minimum effort for you compared to all the others who have given up so far on this job... another option would be if you could lay out your plan for implementation and some other interested comitters could do it? WDYT? I would love to use javaflow and i would love to help too if i can... thanx gabriel ______________________ Mag. Gabriel Gruber Senior Consultant +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Workflow EDV GmbH, Dannebergplatz 6/23, A-1030 Wien Torsten Curdt <[EMAIL PROTECTED]> 16.04.2008 14:28 Please respond to [email protected] To [email protected] cc Subject Re: javaflow / URL of jar 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
