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.
This brings me to my other question: The cocoon-rcl-plugin is only
useful at development time. What options to instrument Javaflow
classes for production use do we have?
There is an ant task for it in javaflow atm, the maven-jci-compiler
plugin will support that (but that's still a way to go) and we could
write a quick and easy maven plugin for that. These are all options I
see.
..or just use a FileResourceStore or serialize the
MemoryResourceStore ;)
cheers
--
Torsten
