Noel, > > Avalon frameworks manage the core tasks and should ideally > manage the > > reconfiguration of those tasks. Achieving this means that all Avalon > > components benefit from these advances. > > Ideally, yes. This is something that we should bring up with > Avalon, not > just here. They should provide the core facilities, and we > should know how > to use them.
Yep! > > The configuration file, config.xml, is essentially a > persistent store for > > the configuration parameters. As it is XML based we may as > well go with > it. > > We may well want to expose the parsed parameters as Java > objects through > > some kind of interface. > > You mean, other than the existing ones? Probably an extension of the current Configuration interface. One tactic is to parse the config into Java objects at startup (as now). During runtime make configuration changes by updating the parsed objects (not supported by the current Configuration inteface) notifying participants that they have changed. At shutdown, write the current state of the parsed objects back to the config (similarly not yet supported). > > > Probably James would use the Java objects as its > configuration source > > and perist any changes to the Java objects by updating config.xml. > > Avalon provides the configuration interfaces, and should be > responsible for > the core support. However, I would not want to see normal > components able > to effect configuratin changes. The JMX support should be > able to do so. Hmmm. What's a "normal component"? What makes JMX a special case? Once we expose a public interface for making configuration changes we have no control over what uses it. This is as it should be. These interfaces should be secure such that only an authorised entity can make configuration changes, be it via JMX or another avenue. I'm real keen on JMX but don't want to exclude the possibility of a non-JMX solution such as a simple terminal or GUI interface. > > Basically, I agree with your thoughts. I am simply > emphasizing that the > core integration of (re-)configuration and JMX should be part > of Avalon. I totally agree. Ideally James components should see reconfiguration events triggered by Avalon and act accordingly. Avalon should be in control. > If > we do it here, for example if that is something you want to > undertake, it > really should be done by contributing to Avalon. Currently I am just trying to promote a discussion of what needs to be done, and how, for James to be able to dynamically reconfigure. Personally, I expect that the eventual conclusion will be that much of the responsibility will fall on Avalon and James will respond to triggers. But that is just my opinion. I'll give it a week, then try and summarise everyones thoughts (on the Wiki?). See where it goes from there. I know where I'm going at that point - sailing! -- Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
