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 Thu, 03 Feb 2005 21:36:22 GMT
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message