You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Simone Gianni <s....@thebug.it> on 2006/08/01 18:18:47 UTC
Javaflow in 2.2 and the continuation class loader
Hi there,
we (me and Maurizio) are trying to use javaflow in 2.2, which uses the
new jakarta commons implementation. 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.
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.
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.
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.
Is this a known and desired behaviour or we are missing something?
Shouldn't be there a CocoonContinuationClassLoader that mimics the
jakarta common ContinuationClassLoader behaviour but enhancing classes
that extends AbstractContinuable?
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?
- 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.
Simone
--
Simone Gianni
Re: Javaflow in 2.2 and the continuation class loader
Posted by Reinhard Poetz <re...@apache.org>.
Maurizio Pillitu wrote:
> Torsten Curdt wrote:
>>>> That's the setup I've demonstrated in Amsterdam. (I've actually still
>>>> have that setup on disk)
>>> Currently this is not happening : the ReloadingClassLoader is there, and
>>> it manages Jci stores, but could not get how to actually configure a
>>> JavaflowResourceStore in it so that my javaflow classes/sources gets
>>> compiled/reloaded and most important enhanced.
>> With that sitemap feature you had a map:classpath section:
>>
>> <map:classpath
>> factory-role="org.apache.cocoon.components.classloader.ClassLoaderFactory/ReloadingClassLoaderFactory">
>>
>>
>> <class-dir src="../../eclipse/java"/>
>>
>> <class-dir src="../../eclipse/javaflow">
>> <store
>> class="org.apache.commons.javaflow.stores.JavaflowResourceStore"/>
>> </class-dir>
>>
>> </map:classpath>
> We tried to use this snippet into map:components of the sitemap, but it
> gives an error :
>
> Unknown component type 'classpath' at file:/home/mau/workspace/cocoon2.2/cocoon-crud/src/main/resources/COB-INF/sitemap.xmap:21:82
>
> Looking into the code of
> org.apache.cocoon.components.treeprocessor.sitemap.SitemapLanguage I see :
>
> private static final String CLASSLOADER_CONFIG_NAME = "classloader";
>
> so probably the name of the sitemap component is <map:classloader>
> instead of <map:classpath>.
>
> Trying with <map:classloader> we have the following error:
>
> No bean named 'org.apache.cocoon.components.classloader.ClassLoaderFactory' is defined
>
> Using ReloadingClassLoaderFactory it gives the same error.
>
> Could you please send your configuration so that we can try to figure
> out why is not working on ours?
I haven't followed this thread in every detail, but here are some comments:
- Carsten has re-added the classloader factory. I added the configuration to
cocoon-bootstrap (see cocoon-bootstrap-realoding-classloader-factory.xconf).
- In the sitemap you have to declare the classloader factory:
<map:classloader
factory-role="org.apache.cocoon.classloader.ClassLoaderFactory/reloading">
<class-dir src="blah"/>
</map:classloader>
HTH
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Re: Re: Javaflow in 2.2 and the continuation class loader
Posted by Torsten Curdt <tc...@apache.org>.
> >> > That's the setup I've demonstrated in Amsterdam. (I've actually still
> >> > have that setup on disk)
> >>
> >> Currently this is not happening : the ReloadingClassLoader is there, and
> >> it manages Jci stores, but could not get how to actually configure a
> >> JavaflowResourceStore in it so that my javaflow classes/sources gets
> >> compiled/reloaded and most important enhanced.
> >
> > With that sitemap feature you had a map:classpath section:
> >
> > <map:classpath
> > factory-role="org.apache.cocoon.components.classloader.ClassLoaderFactory/ReloadingClassLoaderFactory">
> >
> >
> > <class-dir src="../../eclipse/java"/>
> >
> > <class-dir src="../../eclipse/javaflow">
> > <store
> > class="org.apache.commons.javaflow.stores.JavaflowResourceStore"/>
> > </class-dir>
> >
> > </map:classpath>
> We tried to use this snippet into map:components of the sitemap, but it
> gives an error :
>
> Unknown component type 'classpath' at file:/home/mau/workspace/cocoon2.2/cocoon-crud/src/main/resources/COB-INF/sitemap.xmap:21:82
>
> Looking into the code of
> org.apache.cocoon.components.treeprocessor.sitemap.SitemapLanguage I see :
>
> private static final String CLASSLOADER_CONFIG_NAME = "classloader";
>
> so probably the name of the sitemap component is <map:classloader>
> instead of <map:classpath>.
Well, I know this was removed at some stage. I know Reinhard was
looking into getting it back in. We wanted to work on that but did not
get to do it during the Hackathon in Dublin. IIRC Carsten did some
changes in that area.
> Could you please send your configuration so that we can try to figure
> out why is not working on ours?
The snippet was from the configuration - so this probably has to get
fixed first.
cheers
--
Torsten
Re: Javaflow in 2.2 and the continuation class loader
Posted by Maurizio Pillitu <m....@thebug.it>.
Torsten Curdt wrote:
>> > That's the setup I've demonstrated in Amsterdam. (I've actually still
>> > have that setup on disk)
>>
>> Currently this is not happening : the ReloadingClassLoader is there, and
>> it manages Jci stores, but could not get how to actually configure a
>> JavaflowResourceStore in it so that my javaflow classes/sources gets
>> compiled/reloaded and most important enhanced.
>
> With that sitemap feature you had a map:classpath section:
>
> <map:classpath
> factory-role="org.apache.cocoon.components.classloader.ClassLoaderFactory/ReloadingClassLoaderFactory">
>
>
> <class-dir src="../../eclipse/java"/>
>
> <class-dir src="../../eclipse/javaflow">
> <store
> class="org.apache.commons.javaflow.stores.JavaflowResourceStore"/>
> </class-dir>
>
> </map:classpath>
We tried to use this snippet into map:components of the sitemap, but it
gives an error :
Unknown component type 'classpath' at file:/home/mau/workspace/cocoon2.2/cocoon-crud/src/main/resources/COB-INF/sitemap.xmap:21:82
Looking into the code of
org.apache.cocoon.components.treeprocessor.sitemap.SitemapLanguage I see :
private static final String CLASSLOADER_CONFIG_NAME = "classloader";
so probably the name of the sitemap component is <map:classloader>
instead of <map:classpath>.
Trying with <map:classloader> we have the following error:
No bean named 'org.apache.cocoon.components.classloader.ClassLoaderFactory' is defined
Using ReloadingClassLoaderFactory it gives the same error.
Could you please send your configuration so that we can try to figure
out why is not working on ours?
TIA
Maurizio Pillitu
Re: Re: Javaflow in 2.2 and the continuation class loader
Posted by Torsten Curdt <tc...@apache.org>.
> > That's the setup I've demonstrated in Amsterdam. (I've actually still
> > have that setup on disk)
>
> Currently this is not happening : the ReloadingClassLoader is there, and
> it manages Jci stores, but could not get how to actually configure a
> JavaflowResourceStore in it so that my javaflow classes/sources gets
> compiled/reloaded and most important enhanced.
With that sitemap feature you had a map:classpath section:
<map:classpath factory-role="org.apache.cocoon.components.classloader.ClassLoaderFactory/ReloadingClassLoaderFactory">
<class-dir src="../../eclipse/java"/>
<class-dir src="../../eclipse/javaflow">
<store class="org.apache.commons.javaflow.stores.JavaflowResourceStore"/>
</class-dir>
</map:classpath>
> Maurizio can have some time to sort this out and I'll be aside him, so
> quick questions are :
> - From a user point of view, how do we specify packages to be enhanced?
Forget what I said (was too late) - it's not even based on the package
...it's based on the whole source directory. I found that a very good
separation without compromising in the package naming scheme. So you
your application would have a
src/main/java/com/mycompany/...
src/main/javaflow/com/mycompany/...
The one getting instrumented ...the other one not. We would still need
to sort out the build time instrumentation - no maven2 plugin yet. But
we should be able to either call the anttask or come up with a quick
plugin ourselves. Easy one.
...but for me - I never needed it. I found it most comfortable to have
eclipse compile the classes for me and then have jci load and
instrument them. Like that you get that instant reload of components
and javaflow (plus debugging!) from within eclipse. (The Amsterdam
setup)
> ... What if the user have (and we have :) ) a helper class which extends
> AbstractContinuable as well since it needs to send some pages but is not
> in the same pakage as each javaflow class since it's shared among them?
> Ho do we enhance that too?
>From that point on it does not really matter anymore. It all depends
on the source directory.
> - How do we say to the JavaInterpreter that a certain class or package
> has already been enhanced with ant/maven and so the normal classloader
> should be used? Is there a way to determine it automagically?
That's the beauty - we don't have do. As everything works
transparently through jci. It basically appear like it is statically
enhanced.
> - How do we register a JavaflowResourceStore in the
> ReloadingClassLoader? (so that we can also subscribe to events and
> reload the methods only when it changes)?
See the above sitemap snippet
> Just give us pointers and hints, we'll take care of details if we manage
> to :)
Great ...hope this got you further!
> In the meanwhile i recovered the two basic javaflow samples (Calculator
> and Form) so that we have something to test with, I'm committing them now.
Just let me know if you want to have my Amsterdam setup to compare with.
> > 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.
>
> I do agree, but currently IMMO breaking compatibility completely with
> old applications is not a good idea. Maybe we should provide a
> "LegacyJavaflowClassloader" as well, which takes care of the old
> AbstractContinuable marker (and also make the transition between
> "doSomething" and "something" a bit softer) raising warnings as it has
> been made for the components in the sitemap.
Well, we could also go back to the "doSomething" syntax if we want
...or fall back to that. That's easy to fix in the JavaInterpreter.
Other than that you would only have to separate your java classes from
the javaflow. I think that's something that's reasonable for an
upgrade.
cheers
--
Torsten
Re: Javaflow in 2.2 and the continuation class loader
Posted by Simone Gianni <s....@thebug.it>.
Torsten Curdt wrote:
> 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 this is not happening : the ReloadingClassLoader is there, and
it manages Jci stores, but could not get how to actually configure a
JavaflowResourceStore in it so that my javaflow classes/sources gets
compiled/reloaded and most important enhanced.
>
> 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.
>
Maurizio can have some time to sort this out and I'll be aside him, so
quick questions are :
- From a user point of view, how do we specify packages to be enhanced?
... Use the flow class package by default?
... What if the user have (and we have :) ) a helper class which extends
AbstractContinuable as well since it needs to send some pages but is not
in the same pakage as each javaflow class since it's shared among them?
Ho do we enhance that too?
- How do we say to the JavaInterpreter that a certain class or package
has already been enhanced with ant/maven and so the normal classloader
should be used? Is there a way to determine it automagically?
- How do we register a JavaflowResourceStore in the
ReloadingClassLoader? (so that we can also subscribe to events and
reload the methods only when it changes)?
Just give us pointers and hints, we'll take care of details if we manage
to :)
In the meanwhile i recovered the two basic javaflow samples (Calculator
and Form) so that we have something to test with, I'm committing them now.
> > 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.
I do agree, but currently IMMO breaking compatibility completely with
old applications is not a good idea. Maybe we should provide a
"LegacyJavaflowClassloader" as well, which takes care of the old
AbstractContinuable marker (and also make the transition between
"doSomething" and "something" a bit softer) raising warnings as it has
been made for the components in the sitemap.
Also I think that a class that extends AbstractContinuable should be
enhanced anyway because it could call a sendPageAndWait somewhere and
simply generate exceptions.
Regards,
Simone
--
Simone Gianni
Re: Javaflow in 2.2 and the continuation class loader
Posted by Torsten Curdt <tc...@apache.org>.
> 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