Re: [Fwd: Re: Mailet API]

2002-04-29 Thread Dave Morris

Jeff,

 It would probably be helpful for the Mailet to explicitly know which mailing
list it is processing for.
 It may also be helpful to know which command was matched, but that's getting
even more complicated.

This is the kind of thing I as trying to do.
With the minimum changes to the current API, which is why I came up with the
idea of allowing the Mailet to create the Matcher.

In the example you describe.
The list name could be moved into the Mailet configuration rather than the
Matcher configuration.

mailet class=AvalonListservManager
listName[EMAIL PROTECTED]/listName
repositoryNamejames-list/repositoryName
/mailet

The Mailet gets the list name by reading the configuration when it is
initialised.
The Mailet then creates the Matcher, passing it the same list name.

/**
 * Our Matcher.
 *
 */
private Matcher matcher ;

/**
 * Initialise our Matcher, using the list name from our config.
 *
 */
protected void initMatcher()
throws MessagingException
{
//
// Create our Matcher.
//
matcher = new CommandForListserv() ;
MatcherConfigImpl config = new MatcherConfigImpl();
//
// Set the Matcher list name.
//
config.setCondition(myListname);
config.setMailetContext(getMailetContext());
matcher.init(config);
}

/**
 * Get our Matcher, creating a new one if required.
 *
 */
public Matcher getMatcher()
{
if (null == matcher)
{
initMatcher() ;
}
return matcher ;
}

So, both the Mailet and the Matcher get the same list name, set once in the
Mailet configuration.

If you want to add additional communication between the Matcher and Mailet.
To be able to change the list name for example (not a very practical example,
but just suppose).

You could extend the Matcher class, to add setListName() and getListName()
methods.

class XCommandForListserv
extends CommandForListserv
{
public void setListName(String name) {  } ;
public String getListName() {  } ;
}

The Mailet could then create an XCommandForListserv, and have access to the new
methods.
Internally, the Mailet has a reference to the extended class, but externally it
is still a generic Matcher.

/**
 * Our extended Matcher.
 *
 */
private XCommandForListserv matcher ;

/**
 * Initialise our Matcher, using the list name from our config.
 *
 */
protected void initMatcher()
throws MessagingException
{
//
// Create our extended Matcher.
//
matcher = new XCommandForListserv() ;
MatcherConfigImpl config = new MatcherConfigImpl();
//
// Set the Matcher list name.
//
config.setCondition(myListname);
config.setMailetContext(getMailetContext());
matcher.init(config);
}

/**
 * Get our Matcher, creating a new one if required.
 *
 */
public Matcher getMatcher()
{
if (null == matcher)
{
initMatcher() ;
}
return matcher ;
}

/**
 * Change the list name for no obvious reason.
 *
 */
public void sillyExample(String name)
{
if (null != matcher)
{
matcher.setListName(name) ;
}
}

Would this enable you to do what you wanted ?
Hopefully, without too many side effects on the rest of the Mailet / Matcher
code already in place.

In theory, it would be possible to extend XCommandForListserv to enable the
Mailet to ask the Matcher what command was matched.
However, it would probably need to be thread safe and sync  possible, but a
bit more complicated.

Hope this helps,
Dave


Jeff Keyser wrote:

 I agree that the work of matching and doing something should be separate.
 However, I'd like to suggest an alternative way of communicating, since it
 may be helpful for a Mailet to know what parameters were user by the
 Matcher.

 I'm thinking specifically about the CommandForListserv Matcher and the
 AvalonListservManager Mailet.  It would probably be helpful for the Mailet
 to explicitly know which mailing list it is processing for.  It may also be
 helpful to know which command was matched, but that's getting even more
 complicated.

 How to do this?  I'm not sure, but if it can be done cleanly, I see it being
 useful.

  -Original Message-
  From: Andrew Timberlake [mailto:[EMAIL PROTECTED]]
  Sent: Monday, April 22, 2002 12:00 PM
  To: [EMAIL PROTECTED]
  Subject: [Fwd: Re: Mailet API]
 
 
  Thanks Dave for the response
  I'm forwarding this thread back into the list as I would like to hear
  the main developers, and others, feedback and insight into this.
 
  Thanks
 
  Andrew
 
  -Forwarded Message-
 
  From: Dave Morris [EMAIL PROTECTED]
  To: Andrew Timberlake [EMAIL PROTECTED]
  Subject: Re: Mailet API
  Date: 22 Apr 2002 16:19:22

Mailet API

2002-04-22 Thread Dave Morris

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
domainmydomain.com/domain
/mailet

mailet class=LocalDelivery
domainmyother.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
domainmydomain.com/domain
/mailet

mailet match=RecipientIsInDomain=myother.com
class=LocalDelivery
domainmyother.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:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Test mailets

2002-04-18 Thread Dave Morris

Hi,

I've been working on some code to create some internal test tools for
James.
The idea is to add a set of test mailets inside James.
You send a trigger email from outside to [EMAIL PROTECTED]
This triggers each of the test mailets to send a set of test emails to
themselves and check results.
The trigger mailet then sends a set of replies back to the initiator
with the test results.

Has anyone else looked at this ?

Thanks,
Dave




--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]