Steve,
Interesting point ... RemoteDelivery is unique that way. No other mailet is
both the generator and consumer of its own messages.
This also sounds like it ought to be part of the logging package, though,
doesn't it? I don't mean logkit; I mean the overall approach that James
ought to take to logging. Right now that is a bit haphazard, but for
tracking messages through the system, it probably ought to be better
specified and uniform, perhaps even follow a known log format so that
existing log reporting tools can work.
What is the current art in this area? I haven't looked to see what qmail,
sendmail, postfix, et al, do in terms of any common log format.
--- Noel
-----Original Message-----
From: Steve Short [mailto:[EMAIL PROTECTED]
Sent: Friday, February 28, 2003 13:17
To: James Developers List
Subject: RE: User-Log
It is a nice solution, but I don't think it will work in this case
because a tracking service will need to log delivery status on a per
message basis. RemoteDelivery can split up messages for different target
recipient domains and now also has partial delivery capability, so one
invocation to RemoteDelivery could yield multiple tracking entries with
different status value and RemoteDelivery can also store message in a
retry queue for later delivery.
Steve
> -----Original Message-----
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
> Sent: Friday, February 28, 2003 10:03 AM
> To: James Developers List
> Subject: RE: User-Log
>
>
> > Perhaps consideration should be give to wrapping mailets
> > in mailets, that way the tracking mailet could contain
> > any mailet, all it has to do is delegate calls to the
> > mailet methods to the wrapped class, and intercept those
> > its interested in on the way.
>
> Very clever and general solution! Nicely done. :-D Best of
> the lot so far.
>
> > I suspect the config model isn't up to this though.
>
> <mailet match="..." class="Wrapper">
> <Wrapper-target>RealMailet</Wrapper-target>
> <Wrapper-param>...</Wrapper-param>
> <foo>...</foo>
> </mailet>
>
> The wrapper would instantiate the inner mailet instance, and
> pass along the lifecycle calls, including the config object.
> The inner mailet wouldn't know about or bother with the
> wrapper's configuration parameters.
>
> > I'm also concerned that this mailet is not portable
>
> I don't think that there is much question of that, right now.
> But at least it is isolated into one place.
>
> --- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
