> > I have in the past felt the need of having a richer way > > to interact with matchers than just through the > > condition string, using instead child elements as with > > mailets. > > This has been a frequent area of discussion. For James v3, there > will be a > change. See > http://nagoya.apache.org/wiki/apachewiki.cgi?JamesV3/MailetConfigu > ration for > some proposals. You should be aware that there is little support for > Proposal #2. Regardless, we would simply add an "onException" > attribute to > the matcher element.
... and to the mailet element ... Yes, under the lights of such discussions this is the best way to do, being those "onException" information that apply to whichever mailet or matcher is invoked in that particular config.xml entry, and not to the specific mailet or matcher *class* being invoked there. > > I don't know how to access <mailet> attributes. I can dig > around the code > > but if you could give me a hint ... ;-) > > Look in the initialize code for the spool manager, which is > responsible for > loading the configuration. There would need to be some internal changes > between the spool manager and the processor. I'll look at it. Thanks. > > I probably can't help you much right now. I had a SCSI drive fail on a > server, and dealing with that will probably consume me for a little while. > I've got the server running again, but I need to get a new server into > service. Good luck! But didn't it happen to you already a few weeks ago? > > I think that the feature we are discussing is totally transparent > > and backwards compatible, as defaults to the current behaviour. > > I agree. But when we expose a new configuration option, we want to make > sure that we do it in a way that we want to support for a while. :-) Understood. > > > Regarding what to do about per-recipient exceptions, instead of > per-message > > exceptions, I agree that we may handle it better in the future. > > Something to put on the TODO list. :-) > > > To avoid future backward compatibility in configuration files, we can > [use] > > matchException="[matchall|nomatch|error|aProcessorName]", > > in the future > > matchException="[match|matchall|nomatch|error|aProcessorName]" > > I don't believe that we need to make that change. The exception, itself, > would provide that information. Depending upon the type of exception, it > will either require matchall or it would provide information on individual > exceptions. I think it differerently here: what and *when* to do should be a choice of the administrator, based on what is passed up from the mailet/matcher. > > Please note that ERROR *is* a processor name. It is a required > processor by > that name. I know, and we would go to that processor: same as writing <mailet ... class="ToProcessor> <processor> error </processor> </mailet>. > > please do commit for me now the patch to AbstractRedirect > > as I am doing small things here and there, and I would > > prefer not having a too big patch accumulating different > > things. > > Under normal circustances, I'd be happy to do it. If I can, I will. But > right now I have a server that I must attend to with some urgency. OK. Vincenzo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
