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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
