Hi Mark (Maurizio is here on my side not answering due to annoying mail server issues) and we're working on reloading classloader configuration.
You're right, the TreeProcessor already behaves like this, by checking the value of
used also to control sitemap reloading. You can then easily configure this value differently in the different modes, e.g. dev mode uses 'yes'.
We preferred not to add yet another property since the class reloading functionality is about a very similar concern (actually reloading is pretty generic).
Is this what you meant?
As side note, did you already try the reloading classloader sample, which you can reach at , running cocoon-dist-samples block ? You should be able see automatic reloading the .class file of the generator org.apache.cocoon.core.container.reloading.MyGenerator; at the moment you must compile it explicitly, we tested it via Eclipse autobuilding feature and with maven (mvn compile).
BTW, any news about javaflow  ? Did anyone try how it works?
Any feedback is really appreciated!
Thanks for your interest!
[ http://issues.apache.org/jira/browse/COCOON-1929?page=comments#action_12455133 ]
Mark Lundquist commented on COCOON-1929:
w.r.t.: " I decided to provide the reloading class functionality only for dev mode, so, in order to get it working, you need to run the cocoon application with - Dorg.apache.cocoon.mode=dev "...
IMHO, Cocoon itself should never look at the value of o.a.c.mode, _except_ to decide what properties file to load from WEB-INF/cocoon/properties/ (or wherever it is). Feature selection should be driven by feature-specific properties. Unless I am missing something (wouldn't be the first time :)
> [PATCH] Reloading classloader in Cocoon 2.2
> Key: COCOON-1929
> URL: http://issues.apache.org/jira/browse/COCOON-1929
> Project: Cocoon
> Issue Type: Task
> Components: * Cocoon Core
> Affects Versions: 2.2-dev (Current SVN)
> Reporter: Maurizio Pillitu
> Attachments: addxconf.diff, cocoon-core-r469213.diff, cocoon-r469167.diff, cocoon.diff
> The attached patch provides a first implementation to enable reloading classloader configuration into the sitemap, using the sitemap syntax used in blocks/cocoon-core-sample/cocoon-core-main-sample/src/main/resources/COB-INF/sitemap.xmap.
> Referring to CocoonGT 2005 Torsten's code, I moved all the JCI listener configuration into the ReloadingClassLoaderFactory class, that is in charge to parse the classloader configuration (filled by AvalonUtils class) and instanciate all the JCI listeners.
> The TreeProcessor component is subscribed to the JCI listeners, in order to reload the component definitions when a file change event is triggered.
> The patch provides also a sample : http://localhost:8888/blocks/cocoon-core-main-sample/reloading/
> Try to change MyGenerator.java and compile it into blocks/cocoon-core-sample/cocoon-core-main-sample/target/classes (default eclipse location); if you need to change the location of the .class folder, edit the cocoon-core-main-sample sitemap.xmap.
> Obviously there are many parts of the code that can be optimized.
> The patch has been applied on revision 453682.
> 1. I decided to provide the reloading class functionality only for dev mode, so, in order to get it working, you need to run the cocoon application with - Dorg.apache.cocoon.mode=dev
> 2. The patch depends on a bugfix on Commons JCI (https://issues.apache.org/jira/browse/SANDBOX-174 ), so it's necessary to build jci-core from trunk; the patch will update the cocoon-bootstrap dependency to jci.
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira