Serge Knystautas wrote: > > Steve Brewin wrote: <snipped> > > My approach would be entirely different to this, just because I don't > like the contextual lookups that anXMLSource and aMailetConfiguration > provide.
Maybe I should have chosen a more abstract example as I wasn't intending to suggest a design for the MailetProcessor, but rather create a hypothectical example that might help flush out whether the simple start/stop lifecycle states offered by many IOC container implementations are sufficient for our needs. <snipped> > > Can you provide examples of a mailet that consumes heavy > resources, but > reloading its configuration would have it do nothing? I'm having > trouble thinking of a mailet that has a lot to do initially that > wouldn't have to be redone with a different configuration. So am I! What I was trying to get at is that there may be components that we want to exclude from runtime reconfiguration and we cannot do that if there is no way to distiguish between a genuine start and stop events and a runtime reconfiguration event. Staying in James world, we might decide that its a bad idea to support runtime reconfiguration of the SMTP component as this would temporarily remove the mail server from the network. If the lifecycle includes a reconfigure event the SMTP component would exclude itself simply by not implementing the corresponding reconfigure() method. Without, it can't. In short, I'm simply saying that we may have scenarios for which a simple start/stop lifecycle is not enough. I would be happy to be proven wrong as it would keep things simple. -- Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
