Mark Imel wrote:
I'm working on a List Serv that is more extensible/customizable then the
reference implementation provided with James. One of the features i've
added, is the ability to plugin new commands to the list serv manager.
<snip>
I wanted to enable the matcher to not have to guess about the currentlyAs far as I can see, you are trying to have the matcher determine whether or not a given command is valid, before passing it on to the list serv manager mailet. The more I think about it, the more a think that you probably don't need to do this anyway. If I were you, I would only use the matcher to determine whether or not the message is intended for the list serv. If it is, the list serv can then figure out whether the command is valid. (This will let the list serv send back a useful error message in the event that a command is specified incorrectly.)
registered commands. But, the commands are currently registered with the
list serv manager, and there wasn't an easy way that i could see to inform
the matcher about the specific commands that the list serv manager
understands.
As a result, i centralized the command lookup mechanism is in the list serv
manager, and i have the list serv matcher delegate to the list serv manager
to see if the incoming mail has a valid command. Based on the lookup to the
list serv manager, the matcher will return a true or false appropriately.
This approach fits in nicely with the "information expert" pattern for assignment of responsibilities. "Assign the responsibility to the ... class that has the information necessary to fulfill the responsibility". It also highlights the reason that this pattern exists. Obtaining the necessary information from your command registry is simple when you /are/ the command registry.
I am not sure how you are specifying your list serv commands, but it doesn't matter too much. Assuming that they are in one of the usual places (e.g. subject, recipient user, etc. ) you should be able to match list serv messages with one of the standard matchers.
Cheers
ADK
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
