On 22.03.2007, at 11:03, Reinhard Poetz wrote:
Torsten Curdt wrote:
And what configuration is necessary for production so that
classes are "only" instrumented?
For javaflow all you need is to use this store. For both -
compiling or reloading. Of course it would be good to configure
the packages that should be instrumented. I can add that to that
store directly if you want.
http://jakarta.apache.org/commons/sandbox/javaflow/apidocs/org/
apache/commons/javaflow/stores/JavaflowResourceStore.html
sorry, I'm a confused. What do you mean by "this" and "that"
store. The current implementation is
org.apache.commons.jci.listeners.ReloadingListener rl =
new CocoonReloadingListener();
rl.addReloadNotificationListener(classloader);
fam.addListener(directory, rl);
and if I look into CocoonReloadingListener() which extends
org.apache.commons.jci.listeners.ReloadingListener I find that it
creates stores of type MemoryResourceStore.
Am I right that, in order to support instrumentation for
Javaflow, I have to override the default behaviour and create
stores of type JavaflowResourceStore instead?
Correct! ...or we always use a javaflow store and work that out
via configuration.
I think that I understand the scope of the problem now.
For now I will concentrate on the release of cocoon-rcl-plugin
without Javaflow support. It can be added at any time later. I
won't have much available time over the next weeks (and no use case
that would justify to change my priorities) but if somebody else
wants to integrate it into cocoon-rcl, I'm available for dicussing
it on this list.
The only question is where and how to configure what is meant to be
instrumented.
...well and how people envision this to happen for non-dev mode.
The original implementation just defined the store class to use per
directory that is getting monitored. See
http://cocoongt.hippo12.castaserver.com/cocoongt/torsten-curdt-rapid-
app-development.pdf
cheers
--
Torsten
