So, to be clear, taking the Mailet chain as an hypothetical example, we would have sequences something like...
MailetConfiguration(URL anXMLSource) MailetProcessor(MailetConfiguration aMailetConfiguration)
My approach would be entirely different to this, just because I don't like the contextual lookups that anXMLSource and aMailetConfiguration provide. Something like this...
new JDBCMailet(DataSource) new UserStoreMailet(UserStore) new RecipientIsMatcher(String)
These are assembled into a SortedMap or something that goes into...
new SimpleMailetProcessor(MailSpool, SortedMap (of matcher/mailets))
Then hot-restart is as simple as MailetProcessor.dispose(), when that's over, then instantiate your new MailetProcessor with the new set of Mailets and it starts grabbing.
Or maybe instead of passing MailSpool into the processor...
new SimpleMailetProcessor(SortedMap) MailSpool.removeListener(oldProcessor) MailSpool.addListener(newProcessor)
This is just fine. But let's progress our hypothectical example. MailetProcessor.start() and stop() sends start() and stop() to each of its Mailets. Some of these Mailets incur significant overheads when starting and stopping but have no configuration. None the less, using a simple lfecycle with just start() and stop(), they will be started and stopped when we want to reconfigure even though it is an unnecessary overhead. Of course, being a heavy consumer of resources we absolutely do want to stop cleanly on a genuine stop. What we need to be able to signal to these components is that we are reconfiguring so that they know that they have to do nothing.
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.
-- Serge Knystautas Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
