> -----Original Message----- > From: Berin Loritsch [mailto:[EMAIL PROTECTED] > > Granted, this *might* be addressed by providing a work space to save these > config files. At the same time, it would be much simpler to store the > configuration where the rest of the configuration information is stored. > The only entity that knows that information is the container. That would > require and interface between the container and the component to be able > to change the config info and persist it between sessions.
Right, I see it now. It makes sense. I'd be a +1 for it. On a related thought: So suppose we have a JMX extension like the one Leo mentioned. The container hands it component A's configuration in the form of this MutableConfiguration (as opposed to DefaultConfiguration). The user adjusts the configuration and submits the changes. Okay, now what? Do we finally start using the Reconfigurable lifecycle? Decommissioning and restarting the component can have ripple effects for any services dependent on component A. I just wanted to point this example out as a decent use case for the Re* lifecycles which have never been supported. J. Aaron Farr SONY ELECTRONICS DDP-CIM (724) 696-7653 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
