Danny Angus ha scritto:
On Feb 5, 2008 3:09 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
I'm not sure I understand the advantages of the redeploy of a single
processor.
Processors are bigger than collections of mailet/matchers, they can
invoke one another and can be implemented in different ways, e.g.
jsieve.
They are in fact "Mail Applications"
I've always said (well for several *years* anyway) that we should
allow archived processors with their config archived with them in a
WAR-like structure to be deployed in James simply by dropping them in.
Then you just have to set up a "to processor" rule to have mail
handled by the app you've deployed.
Get it now?
No. What is the problem in redeploying all the processors every time you
need to redeploy one of them? You will have to stop the spoolmanager
thread anyway, so I don't see a big advantage in the big effort needed
to be able to redeploy a single processor (It would require much more
changes in our CoP, than full spoolmanager redeploy).
About this topic you may remember I refactored the spoolmanager code to
be more modular and you now are able to specify the class for the main
processor (default to StateAwareProcessorList) and in that case you can
specify a different class for each "state" processor (default to
LinearProcessor). This code is in trunk since may 2006:
http://issues.apache.org/jira/browse/JAMES-491
HTH,
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
