james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Brewin" <sbre...@synsys.com>
Subject RE: [James-NG] Avalon-free James proposal and reference implementation
Date Wed, 02 Feb 2005 22:43:14 GMT
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message