Noel J. Bergman wrote:
Stefano Bagnara wrote:
As an example the bayesian tasks that we added to the remotemanager and
that have duplicate configuration could be changed to interact directly
with the mailet. We could have each mailet to expose its own management
tasks.
do we have to extend the mailet API for that? for example by adding an
MailetMBean interface?
Imho we should start it as a specific James extension to mailets. If we
see it is used a lot we could add that specification to the mailet.
Actually, I think that this approach is flawed. The correct answer to "how
do I reconfigure a matcher/mailet" is: YOU DON'T.
The answer is not to reconfigure elements, but to create new ones at the
processor boundary. In order to reconfigure a matcher or mailet, you create
a new processor, with new configurations for the contained components.
Existing mail within that processor continues to run in the processor with
the configuration it had when they entered. Messages newly entering the
processor will be picked up by the new copy of the processor. When the old
processor is done, it goes away and is garbaged collected.
--- Noel
I was not talking about reconfiguration of mailets, but management
operations related to mailets.
E.g:
1) Bayesian db management
2) Outgoing queue manamement
3) JDBCVirtuserTable rules management
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
