cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Torsten Curdt" <>
Subject Re: Re: Javaflow in 2.2 and the continuation class loader
Date Wed, 02 Aug 2006 04:40:41 GMT
> > 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"/>


> 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'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


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

> ... 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

> - 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


View raw message