On Feb 8, 2008 10:33 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > 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.
+1 > > 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). shoulnd't need to stop the master thread, just the worker for the processor in question. > 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 cool - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
