cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gabriel Gruber <Gabriel.Gru...@workflow.at>
Subject Re: javaflow / URL of jar
Date Thu, 17 Apr 2008 21:04:35 GMT
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 <tcurdt@apache.org> 
16.04.2008 14:28
Please respond to
dev@cocoon.apache.org


To
dev@cocoon.apache.org
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


Mime
View raw message