Brian,
Again, my points may be considered purely "academic" or "theoretic", but:
> I have my WildcardAddress matcher configureed like this:
>
> <!-- Wildcard Address matching -->
> <!-- This should replace the 'match="All'
> class="ToProcessor"' -->
> <!-- mailet/matcher pair. The argument is a regular
> expression -->
> <!-- a single group that extracts the real user from the user -->
> <!-- portion of the recipient address -->
> <mailet match="WildcardAddress=([^-]+)-.+" class="ToProcessor">
> <processor> transport </processor>
> </mailet>
>
> <!-- Send remaining mails to the transport processor for either
> local or remote delivery -->
> <!-- mailet match="All" class="ToProcessor">
> <processor> transport </processor>
> </mailet -->
>
> Thus, I've replaced the 'All' matcher with the 'WildcardAddress'
> matcher, so
> that before the spool sees the messages, the message recipients will have
> been "fixed".
>
You have in fact the equivalent of:
<mailet match="WildcardAddress=([^-]+)-.+" class="Continue">
(assuming that a Continue mailet exists that simply returns). It means that your
matcher behaves as a mailet.
As you only change the recipients list on an unmodified message, you could have:
<mailet match="All" class="WildcardAddressSubstitution">
<recipientMatch>([^-]+)-.+</recipientMatch>
</mailet>
Is it better? I dont't know, but it's more readable (IMHO).
> The way you describe "forking" a mail in a Mailset (setting the Recipients
> on the Mail object) is that I've done in my oither
> MailSisveMailet. When I
> need to add a user-specific header to the message, I have to CLONE the
> entire messages, add the header, set the recipient o be that user, send it
> -- and then remove that user from the original Mail's recipient
> list and let
> it continue. Granted, because I have to add user-specific
> headers, it is a
> more complex forking operation.
>
> When I read the Javadoc for Matcher when planning to do
> WildcardAddress, it
> said that the Mailet container has the awesome capability to fork messages
> for you and all you have to do is return the recipients you wish
> to receive
> that message. So I bent the rules a little bit and made it return the
> entire recipient list, but with the recipients who were wildcarding their
> MailAddress replaced with their normal MailAddress.
>
> Now I can see how this would be done in a Mailet instead of a
> Matcher. But,
> then, what is the purpose of a Matcher? What is this "awesome forking
> capapbility" that the Mailet container has and can only be
> accessed through
> a Matcher.
For me, the matcher is equivalent to the boolean condition in an "if" statement, and
the mailet is equivalent to the bofy of the "if". You would use it for a fork if you
need to do a conditional modification to the message, for example if you add a header
to only the messages that match your regex, and not to the others. In this case you
would use your matcher to fork to a mailet that would change the recipient and add the
header, while the non-regex-matched recipients would continue unmodified.
Communications between a matcher and a mailet coupled by the same <mailet> entry could
take place through mail attributes.
The point is that both matchers (those directly extending GenericMatcher) and mailets
are able to do anything to the Mail object, as they can access and manipulate the Mail
object (casting to MailImpl if necessary - this is the core of the discussion about
V3). You could even substitute all the matcher/mailet logic in config.xml with your
own coded "super matcher" or "super mailet" (looks like "super Mario") if you like to,
but the beautiful and great thing of all the mailet processor architecture is that all
functionality is factorized and an administrator, not only a java programmer, can
tailor/extend it smoothly. That's why I think it makes sense to keep a clean
distinction between matchers and mailets.
>
> I'm truly concerned about what you describe about the upcoming
> API changes.
> It sounds like much of what I currently do, and what I hoped to do in the
> future, will become impossible.
>
I don't think so, but comments from other people would be useful to better clarify
this point. From my understanding, in V3, with the new APIs, only "official" matchers
and mailets will have access to MailImpl; user written matchers and mailets will have
only access to methods exposed through the Mail interface. But I may be missing
something.
Vincenzo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
