Stefano Mazzocchi wrote:
>
> >
> > I like the idea of a MailServletequest and MailServletResponse since
> > this patter is really evident and well known. But since this do not
> > allow forking... consider this:
> >
> > public void service(MailServletRequest req, MailServletResponse res)
> >
> > MailServletRequest gives you methods to easily access routing info,
> > headers and read body
> > MailServletResponse has some methods like
> > copyBodyFrom(MailServletRequest req) and copyMailFrom(MailServletRequest
> > req) etc to make easy and painless duplication of messages.
> >
> > This is just a filter and do not allw forking.
> >
> > Adding to the AbstractMailServlet a method like
> > MailServletResponse getNewMailServletResponse()
> >
> > gives the mailServlet the ability if necessary to fork a message while
> > should not make
> > criptic the use if just a filtering is needed.
> >
> > some example...
> >
> > <processor match="[*]" class="Find">
> > <find> aliens UFO cospiration </find>
> > <action> mailto:[EMAIL PROTECTED] </action>
> > <action> mailto:[EMAIL PROTECTED] </action>
> > </processor>
> >
> > IMPLEMENTATION
> >
> > public void service(MailServletRequest req, MailServletResponse res) {
> > res.copyMailFrom(req);
> > InputStream in = req.getBody();
> > if (findInStream(in, "aliens UFO cospiration")) {
> > MailServletResponse alarm = this.getNewMailServletResponse();
> > alarm.setSender("james@myhost");
> > alarm.copyMailAsAttachment(req);
> > alarm.setSubject("alarm");
> > this.send(alarm);
> > }
> > }
> >
> > while a simple MailingListServlet...
> >
> > public void service(MailServletRequest req, MailServletResponse res) {
> > res.copyMailFrom(req);
> > res.setRecipients(thisListRecipients);
> > }
> >
> > Sounds good to you?
>
> Hmmmm, the above is still a filter.
>
> mail --> ufo cospiracy mail servlet -> untouched mail
> |
> v
> signal
>
> the signal is a log signal. If this logs gets forwarded as a mail
> message, or stored into a database, this is _NOT_ of mail servlet
> concern. This is a system dependend feature. Same thing happens in case
>
> mail -> james -> mail
> |
> V
> critical error
>
> that is gets forwarded to your pager, nothing different.
>
> So, instead of extending the Mail Servlet API, I'd write something like
>
> public class UFOCospiracyMailServlet
> extends JamesSignalProducer
> implements MailServlet
> {
>
> public void service(MailServletRequest req, MailServletResponse res) {
> res.copyMailFrom(req);
> InputStream in = req.getBody();
> if (findInStream(in, "aliens UFO cospiration")) {
> signal("UFO", req.getSender());
> }
> }
>
> that also allows you to "decouple" molder and schully from the
> parameters of this servlet, which job is to filter a mail, not to send a
> message!!!
>
> Do I make sense?
Do not completly agree.
Agree most of mail servlet only acts like filter. Some others produces
signals (events that are "mail independent").
But take Serge ImOnVacation Servlet. It let any incoming mails pass
untouched (maybe a footer like "was replied by ImOnVacation") and
generate a new mail as reply. This I'm sure is not an event.
The easiest way to manage this is: the servlet may open anSMTP
connection with JAMES and send the new mail.
Of course this work perfectly even with my MailingListTranslator
servlet.
Since Forking mail servlet are 1% or so maybe this is the best solution
but I want to throw another couple of ideas into this brainstorm:
<!-- common processor pipe beginning --!>
<processor match="[*]" class="AddHeader">
<header> Recieved from ... by JAMES </header>
</processor>
<!-- forking point. one mail will follow subpipe 1 --!>
<fork name="fbi" match="[*]">
<!-- subpipe 1 --!>
<processor match="[*]" class="Find">
<find> bomb president tessosism </find>
<action> mailto:[EMAIL PROTECTED] </action>
<action> mailto:[EMAIL PROTECTED] </action>
</processor>
</fork>
<fork name="fbi">
<!-- subpipe 2 --!>
<processor match="[EMAIL PROTECTED] or to=badboy@[*]"
class="Null">
</processor>
<processor match="to=james@[localhost]" class="Archive">
<repository> jamesarchive </repository>
</processor>
<processor match="to=james@[localhost]" class="MailingList">
<list> james </list>
</processor>
<processor match="to=jam@[localhost]" class="MailingList">
<list> jam </list>
</processor>
<processor match="to=admin@[localhost] or to=root@[localhost]"
class="Forward">
<forwardto> scoobie@[localhost] </forwardto>
<forwardto> [EMAIL PROTECTED] </forwardto>
<forwardto> [EMAIL PROTECTED] </forwardto>
</processor>
<processor match="to=mario@[localhost]" class="Translator">
<language> italian </language>
</processor>
<processor match="to=natasha@[localhost]" class="Translator">
<language> russian </language>
</processor>
<processor match="to=scoobie@[localhost]" class="Forward">
<forwardto> [EMAIL PROTECTED] </forwardto>
</processor>
<processor match="to=faxto[*]@[localhost]" class="FaxSender">
<userrepository> faxrepository </userrepository>
</processor>
</fork>
<!-- end of forking. After that the two mails follow the same flow. --!>
<processor match="to=[*]@[localhost]" class="LocalDelivery">
<repository> localInbox </repository>
</processor>
<processor match="to=[*]" class="RemoteDelivery">
<outgoingmailserver> mail.tin.it </outgoingmailserver>
</processor>
I force the processor pipe to fork and to join again before delivery.
This means forking appends in the reactor, it's transparent for mail
servlets and it's up to the administrator.
processor 1
|
processor 2
|
forking
/ \
processor 3 processor 4
| |
processor 5 processor 6
| |
processor 6 |
\ /
\ /
end of fork
|
processor 7
.......
Comments ?
Federico
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
