Noel, A few days back we touched on the desirability of being able to reconfigure James on the fly.
Having given this a little thought I think there are two levels to this... 1) Tasks - They are managed by Avalon and Avalon would need to have the ability to manage and signal a reconfiguration events, such as start, suspend, resume, stop, add, remove, and modify task. 2) Transport Matchers and Mailets - They are managed by James and the ability can be added to James to manage and signal reconfiguration events. As the Mailet chain is a logical construct, the concept of starting, suspending, resuming or stopping an individual Mailet cannot apply as the logical construct would breakdown. We can add, remove and modify. So lets look at what can be done in (2) in more detail... - How would we add a Matcher/Mailet? Update the configuration, rebuild the mailet chain and send init() to the added mailet. - How would we remove a Matcher/Mailet? Update the configuration, rebuild the mailet chain and send destroy() to the removed mailet. - How would we modify a Matcher/Mailet? Update the configuration and send refresh() to the modified mailet. Only two new concepts are introduced here, an updateable configuration and the addition of the refresh() method to the Mailet and Matcher interfaces. Currently configurations are not updateable as org.apache.avalon.framework.configuration.Configuration does not support the setting of values or attributes. Ideally it should. They could then be made editable by exposing to a management interface such as JMX. At termination, a changed configuration would be written back to config.xml, ensuring synchronization. Adding the refresh() method to the Mailet and Matcher interfaces would break pre-existing code. GenericMailet and GenericMatcher could be fixed, but there is no rule that says these should be subclassed for all Mailets and Matchers. Better to extend the interfaces with one which adds the refresh() method and implement this in the Generic classes as a no-op. So, dynamic reconfiguration of the Transport Matchers and Mailets could be achieved more easily than full dynamic reconfiguration which requires Avalon support, but not without a fir amount of effort. I am not sure what the demand for dynamic reconfiguration is. Its great for developers in a code/test/fix cycle, lethal if abused in a production environment but sometimes a life-saver. Maybe others would wish to comment on if its worth the effort? -- Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
