Hi there, we (me and Maurizio) are trying to use javaflow in 2.2, which uses the new jakarta commons implementation.
Cool ...unfortunately javaflow without the getting the sitemap reloading working again might not be much fun :)
We see that after a fi.show() the thread is not blocked at all, since breakpoints placed after the fi.show() got hit before the page displayed, and we can clearly see code executed even before we hit the submit button.
So it did not get instrumented.
In the new jakarta implementation there are two ways to enhance a class for continuations, either with a ant task, or with a classloader as it was in 2.1 javaflow implementation.
The most important one you guys missed: jci :) The idea is that you either have jar getting statically instrumented via ant task or maven plugin (there is currently work on the way to support instrumentation through the maven2 compiler plugin ...but still a fair amount to do as we need to port all existing compilers to jci) ...or you have source code and use the file monitor that either listens on file changes in your eclipse class directory or even compiles your java source files from source. That's the setup I've demonstrated in Amsterdam. (I've actually still have that setup on disk)
Currently in 2.2 javaflow there is no mention of the ContinuationClassLoader, nor there is a ClassLoader subclass or anything similar, so seems like the only way to achieve continuations is to build the classes using the ant task to enhance them.
The synchronous way of compiling revealt a few problems. As compilation was meant to work transparently during the compilation, instrumentation has also been changed to the asynchronous approach.
This is okay from a certain point of view, since a "static" enhancement performs better, but it is a pain since in 2.2 we don't use ant anymore, so the webapp developer should write an ant-run in his pom to enhance classes he needs in javaflow. This also prevents any kind of future compling classloader or similar stuff to do RAD on javaflow.
please see above...
Is this a known and desired behaviour or we are missing something?
Nope, you are missing the file monitor :-)
Shouldn't be there a CocoonContinuationClassLoader that mimics the jakarta common ContinuationClassLoader behaviour but enhancing classes that extends AbstractContinuable?
I am not really a big fan of the AbstractContinuable marker class/interface anymore. Well, was never really. I would prefer to separate the classes via package path or class name convention.
BTW, the default ContinuationClassLoader of jakarta commons has many drawbacks for which is not suitable for cocoon javaflow : - It must be configured with jar urls, which is not acceptable in a webapplication. - It uses BCEL by default, while ASM seems to be better, wasn't it?
Well, the BCEL one is still a bit more stable. The testcase seem to reproduce the same results ...but I think it does need some more testing and care. It would be nice to deprecated the BCEL implementation soon. But as it stands it's the one that's being used by most people at the moment.
- It has no way to detect which classes are to be enhanced and which are not, if not specifying package prefixes, which is error prone and not handy in cocoon, since we have the AbstractContinuable class to mark classes that must be enhanced.
see above At the moment I might not have too much time I can spend to help. ( http://vafer.org/blog/20060801000640 ) But I am happy to guide you through to get this working as good as I can. cheers -- Torsten
