Mailet API

[Dave Morris <da...@codon.demon.co.uk>]

Hi,

I would like to propose a change to the Mailet API, and would be
interested in thoughts and ideas.

At the moment, Mailets have no access to their Matcher.
I appreciate that this is probably by design.
However ..... I would like to suggest adding the following to the Mailet
API.

     /**
      * Create a Matcher for this Mailet.
      * Default is to return null and let the container create the
Matcher.
      * Advantage is that the Mailet can use it's internal data to
generate and configure a suitable Matcher.
      * Disadvantage is that the Mailet interface becomes tied to the
Matcher interface.
      *
      */
     public Matcher getMatcher() ;

And changing the code which loads the Mailets and Matchers in
JamesSpoolManager to this.

    Mailet mailet = null;
    Matcher matcher = null;
    //
    // Allow blank 'match' attribute in config XML.
    String matcherName = c.getAttribute("match", null);
    //
    // Load the Mailet.
    mailet = loadMailet(mailetClassName, mailetcontext, c) ;
    //
    // If the config specified a Matcher.
    if (null != matcherName)
        {
        matcher = loadMatcher(matcherName, mailetcontext) ;
        }
    //
    // If not, see if the Mailet has it's own Matcher.
    else {
        matcher = mailet.getMatcher() ;
        }
    //
    // If we still don't have a Matcher.
    if (null == matcher)
        {
    //
    // Two possible options.
    // a) Throw an Exception saying "No Matcher specified for Mailet".
    // b) Add a default 'All' Matcher.
    // Depends which people think makes more sense ....
    //
        }

This does not break any of the existing Maliets or configuration.
All of the existing mailets can implement the new method and return
null, leaving the container to configure the Matcher.
All of the exisiting configuration stays the same, any Matcher specified
in the config will override the Matcher generated by a new Mailet.

As an example of what this change would gain, consider the local
delivery Mailet and Matcher.

    <mailet match="RecipientIsLocal" class="LocalDelivery"/>

In order to check if the recipient is a local user, the Matcher needs to
access the local repository.
In order to store the mail, the Mailet needs to access the local
repository.

Two separate components, both of which need be configured to access the
local repository.

If the LocalDelivery Mailet was able to generate it's own Matcher, then
the configuration could be changed to this.

    <mailet class="LocalDelivery"/>

In this example, the Mailet would create it's own RecipientIsLocal
Matcher.
Not much of an advantage as yet.
However, the domain for the Mailet could be configurable, so we could
have this.

    <mailet class="LocalDelivery">
        <domain>mydomain.com</domain>
    </mailet>

    <mailet class="LocalDelivery">
        <domain>myother.com</domain>
    </mailet>

In each case, the Mailet would generate it's own Matcher, configured to
match recipients for the specified domain.
Yes, I know it is possible to implement this example using the current
API.

    <mailet match="RecipientIsInDomain=mydomain.com"
class="LocalDelivery">
        <domain>mydomain.com</domain>
    </mailet>

    <mailet match="RecipientIsInDomain=myother.com"
class="LocalDelivery">
        <domain>myother.com</domain>
    </mailet>

However, providing a link between the Mailet and Matcher would make it
easier to create more complicated Matcher/Mailet combinations to handle
dynamic lists of addresses.

Any thoughts ?

Thanks,
Dave




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>