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 in 2.2 and the continuation class loader
Date Tue, 01 Aug 2006 18:09:17 GMT
> 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

Mime
View raw message