> 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/MailetConfiguration 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. Also, a JNDI context could be used to provide information to matchers and mailets. FWIW, the example in proposal #1 shows multiple matchers. I'm actually not sure how Danny has that in mind to work. I don't know if they are parallel or serial, nor if the set operation (matchers don't return boolean, they return recipient sets) is a union or an intersection. > I agree on switching to attributes. :-) > 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 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. > 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. :-) > 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. Please note that ERROR *is* a processor name. It is a required processor by that name. > 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. --- Noel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
