Alexander Zhukov wrote: > > > Danny Angus wrote: <snipped> > If you need a runtime change in configuration or rather behaviour you > should write a component that supports such change and depend your > component on the runtime-changable-component. > > For example: > While running pop3 server some users have to be authorized in > JDBC and > other in LDAP. You write a class ChoiceUserStore that implements > UserStore interface, accepts an array of UserStore objects in > constructor and does the choice of concrete UserStore in > runtime. Then > you pass ChoiceUserStore to your POP3Server as a dependent > component and > forget about runtime configuration because it is transparent to your > POP3Server. > > For reference please check out the > http://devel.priocom.com:8083/viewrep/JamesNG/core/src/net/ukr post/store/SequenceUserStore.java and http://devel.priocom.com:8083/viewrep/JamesNG/core/src/net/ukrpost/store/Mul tiUserStore.java bundled with JamesNG
So, to be clear, taking the Mailet chain as an hypothetical example, we would have sequences something like... MailetConfiguration(URL anXMLSource) MailetProcessor(MailetConfiguration aMailetConfiguration) The startup sequence would be... MailetConfiguration mailetConfiguration = new MailetConfiguration(anXMLSource); MailetProcessor mailetProcessor = new MailetProcessor(mailetConfiguration); mailetConfiguration.start(); // Reads, verifies and instantiates a navigable tree from anXMLSource mailetProcessor.start(); // Instantiates the Mailet Chain described by the MailetConfiguration To reconfigure we would do... mailetProcessor.stop(); // Sends stop() to its dependent partsThrows away its instaniations mailetConfiguration.stop(); // Throws away its instaniations mailetConfiguration.start(); // Reads, verifies and instantiates a navigable tree from anXMLSource mailetProcessor.start(); // Instantiates the Mailet Chain described by the MailetConfiguration 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. There are many other scenarios where we need to discriminate further by adding additional lifecycle states and at the extreme there are components whose service cannot be withdrawn, even temporarily. Maybe I am missing something, but I cannot see how in realworld scenarios we can always boil lifecycle down to two states, start and stop. -- Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
