The first thing I want to be able to do is implement the Reconfigurable lifecycle. I've had requests from clients to be able to change the configuration without restarting the app. My first thought it to have a Monitor component watch the config file(s) for changes and then follow this process:
1. read in the configs
2. see if the config for a particular component has changed (see proposal below)
3. if it has, then initiate a reconfigure. This may require doing a suspend, stop, etc. first (correct?)
3a. Reconfigure the service, then 'restart' it.
3b. If the service doesn't implement reconfigure, create a new one and replace the old one
Sound about right?
It took me a good day to follow the process by which the default container startsup, and while I'm sort of comfortable with it, I'm not sure what components would be involved in doing this. For example, would I have to create a new context, or a new FortressConfig, etc.?
On the proposal, to make this happen for the config, I'm thinking of implementing the equals() method on the default configuration object and have it do a deep equals check. This would probably mean having an equals() method exposed in the Configuraiton interface as well, no?
Thanks for any insights into this - Robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
