Federico Barbieri wrote:
>
> 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.
Yes, I totally share this vision. But one mailet acts as componentizer,
others as callable components.
In general, given the ability of a Mailet to call another, it doesn't
really matter.
> > > 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 agree.
> > 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.
You guys seem to fail a simple programming practice that is used to
"defend" yourself from such API abuses: make the Mail constructors and
all the methods you don't want the mailet to mess with private.
If you need another instance, then you pass thru a factory but you need
to get the instance of the factory and this instance is provided to you
if you are entitled to do this job.
I still don't get it.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
