----- Original Message ----- From: "Cameron Fieber" <[EMAIL PROTECTED]> To: "Avalon Developers List" <[EMAIL PROTECTED]>
> On Thu, 2004-01-22 at 14:52, Leo Simons wrote: > <snip> > > (the main concern I have is in fact that Joe User may think that > > components modifying their own config is a good idea in general; and I > > don't think that's the case) > </snip> Thats certainly a not desirable side effect. > Joe User here ;-) Don't get us wrong. As a matter of fact our users should dictate our feature. Who gives a thing for a nice project with no users? > When you have the management capabilities that exist through JMX > interfaces in Phoenix, or whatever instrumentation equivalent exists in > Merlin, you end up with components that can get reconfigured on the fly > through their management interface. I'm not aware of that. Hows this configuration-management happens? Through 'set' methods or changing the Configuration (DefaultConfiguration) data and reapplying it? > To avoid losing that configuration, it has to be persisted somehow, and > this Persistable interface seems much cleaner than how I've ended up > solving the same problem in the past (which was basically creating my > own DefaultConfiguration, and serializing it in the block home using the > DefaultConfigurationSerializer, and reading it back on a call to > configure). Should the Configuration state be persisted or the component current state? In Merlin a lifecycle extension could easily be added to handle the persistence of component state. Which is the near from *the correct* approach? regards, hammett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
