Hi Thorsten, to comment your options mentioned below: 1. since Cocoon is Maven, based I sort of dislike the option of falling back to ant. 2. Wouldn't this ad a dependency to JavaFlow to cocoon itself? It seems not a lot of people seem to be using JavaFlow. Otherwise I would read a lot more questions here and in the user list, so I think this is no real option. But on the "upside", it would make integration with Eclipse a lot easier. I have no real knowledge about the RCL, but if it were extendable with plug-ins registering for certain classpath sections ... this should be a cool approach. 3. At the moment I think I would like this option a lot ... even if my gut-feeling tells me in your next mail you're going to say "cool ... write it" ... I guess I would need more detailed information about JavaFlow for this ... maybe you're going to drop by near Frankfurt someday ;-) One thing I like about this, is that I would get pre-instrumented JavaFlow classes form my flows. The downside is that It might need some kind of Eclipse plug-in to accompany it since Eclipse would replace the instrumented class with a non instrumented one as soon as someone changes it ... 4. Ok ... this one sounds a little more complex. In some projects I am currently working on, we are using the eclipse compiler instead of the ordinary maven-one since the default Jdk compiler seems to have some problems dealing with some Java 1.6 features (strange thing that suns compiler seems to have problems with suns features) ... this would rob me of this option.
I would propose that a solution of 2 + 3 sounds safest from my point of view. Writing a plug-in for the RCL (assuming there is something like that). In addition creating a Maven plug-in doing the instrumentation would be great. Both could work together: The Maven could set some kind of mark in the instrumented classes to indicate the RCL-plug-in that this class was already instrumented. In this case the RCL simply relays the class. If the flag is not set it instruments the class. This would make development a lot easier and boost the default performance of production builds. Every time I say, that I would gladly contribute, Murphy comes along and steals all my free time, so let me say, that if the information I need sort of pops up in my Mail-Folder, and Murphy left over some time, I will gladly try to do something with this information ... even if it is only printing it and throwing paper balls at Murphy ;-) Chris -----Ursprüngliche Nachricht----- Von: [email protected] [mailto:[email protected]] Im Auftrag von Torsten Curdt Gesendet: Mittwoch, 31. Dezember 2008 14:52 An: [email protected] Betreff: Re: Problems with JavaFlow > the "Continuation.suspend()" call would freeze > until the page is submitted - not anymore. I have noticed that there seems > to have been a change in the Apache-Javaflow project, since I needed to > manually build and install this to be able to build the cocoon-javaflow > block. This build no longer requires tweaking of Testcases to build, so I > guess they have changed something. After having a look at the svn-log I > could read that they seem to have changed the default Byte-Code manipulation > engine from BCEL to ASM but I really doubt, this should be causing the > fundamental Continuation.suspend() call to fail, unless there has to be some > more setting up to do now. I think I have to dig into this a little more, > but at the moment I would suggest that the bytecode manipulataion needed for > JavaFlow is simply not executed. Sounds like it - yes. The question is: how/when is the instrumentation done? (remember: there no longer is a marker interface and no classloader doing the instrumentation!) When I was demoing the javaflow and jci integration in Amsterdam (years ago) that was with 2.2 IIRC. Let me describe how that worked: In the sitemap I pointed jci to the eclipse output folder. Whenever a class changed the reloading classloader reloaded the class AND instrumented the class! So the RCL was not just for class reloading but also for javaflow reloading and instrumentation! For the final deployment you would use the ant task to build a jar and instrument it during the build http://svn.apache.org/repos/asf/commons/sandbox/javaflow/trunk/src/java/org/ apache/commons/javaflow/ant/AntRewriteTask.java So there are a couple of options: 1. use the existing ant task within the build with the maven ant task plugin 2. configure/change/fix the cocoon reloading to also support instrumentation (or does it already?) 3. write a quick maven plugin to do the instrumentation after compilation 4. finish the final goal of to replace the maven compiler plugin with a maven jci plugin (that also supports compile time instrumentation) That is also in the reverse order of complexity/time to spend. HTH cheers -- Torsten
