More later, but I wanted to reply to: > I believe that matchers should be renamed interceptors and the config > changed to look more like this example: > <mailet> > <interceptor> > <class>my.package.fooInterceptor</class> > <condition>domain=me.com</condition> > <otherparam>somevalue</otherparam> > <interceptor> > <class>my.package.fooMailet</class> > <params> > <somename>somevalue</somename> > </params> > </mailet>
Please see http://www.mail-archive.com/james-dev@jakarta.apache.org/msg02208.html and related messages. According to the scheme Andrei and I discussed, the example could be encoded as: <mailet match="fooInterceptor" class="fooMailet"> <matcher-config:domain>me.com</matcher-config:domain> <fooInterceptor:otherparam>somevalue></fooInterceptor:otherparam> <fooMailet:somename>somevalue</fooMailet:somename> <mailet-config:othername>othervalue</mailet-config:othername> </mailet> matcher|mailet-config and the matcher|mailet classname are synonyms in context, and just used for illustration purposes. I posted the outline of the code changes necessary to support this right now in James. By now Andrei may have put them in, else I can do them this week. And I don't especially care what we call matchers, but interceptor does not carry an a priori semantic meaning to me. If they are going to be renamed, I'd just as soon call them "conditions": <mailet condition="condClass" class="mailetClass" /> > the interceptor might poll a remote device or query a database > and handle the mail based upon the results. The problem I have with that sentence is that a matcher is not supposed to "handle" the mail; it is supposed to yield a filtered set of recipients, which the processor will use with the mailet. I know that you know that, and quite well, but the words used in your description blurred the distinction between matcher and mailet. --- Noel -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
