> 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
