Serge Knystautas wrote:
>
> Stefano Mazzocchi wrote:
> > Yes. Otherwise, if you don't, there is no way you can "componentize"
> > your pipeline without having to touch (or worse, recompile) your
> > components.
>
> I'm leaning against putting it in the conf file as a mailet will either
> be the kind that filters a message (adds a header, etc...) or receives
> the message (autoresponder, etc...). This doesn't seem like something
> to put in the conf file to change.
>
+1. Conf define how mailets work together, not how a single mailet
works.
> > If the mailet is able to modify the Mail object, then it must return it,
> > no question about it.
> >
> > A mailet is a filter, and every filter works like this
> >
> > Object filter(Object object)
> >
> > I don't understand why you are against this, I'm probably missing your
> > point.
>
> The problem I see is people writing autoresponders (creating a new
> message to send out) might create a new instance of Mail (for the
> response) and return that instead of the original Mail object. I
> consider this a serious problem because 1) I don't think you should be
> able to insert a Mail message midway through processing and 2) people
> start thinking the API should support returning multiple Mail objects.
> I think new Mail objects should be sent through a different part of the
> API. You are passed an Object... you filter it... that's all... the
> calling method already has a reference to that object... why do you have
> to insult it's intelligence by returning it. ;)
>
That's exactly my point.
And another thing to do is prevent mailet to add recipients to the Mail.
Adding a recipient is like creating a new Mail. So the Forward mailet
MUST create a new Mail with specified recipients (constructor parameter)
and MUST send it using SmartTransport (maybe with a nicer API) since it
cannot return it.
"Call it defensive programming... " [Brian] :-)
Fede
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
