I think it would also be nice to be able to change the order of the mailets, and change the "criteria" for a mailet's matcher.
What about a "test" mode so that changes could be validated/tested before being put on-line? > -----Original Message----- > From: Steve Brewin [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 25, 2003 5:12 PM > To: James Developers List (E-mail) > Subject: Dynamic Reconfiguration > > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
