Kenny,
Good question. And something that we can discuss for the revision of the
Mailet API.
Please do not use the class references. Those are implementation issues,
and would tie the configuration file to the Java source code. No one should
use them.
Until/unless we can handle {<header></header>}* or even a nested
configuration, my thought would be to use <header-n></header-n>.
--- Noel
-----Original Message-----
From: Kenny Smith [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 09, 2002 0:00
To: James Developers List
Subject: RE: Request for new Mailet
Hi Noel et al,
Is there a good way to have multiple tags in a mailet config without just
adding a counter to the name? I notice that the MailetConfig interface
assumes only a single parameter per name (I assume because the Interface
doesn't know it's configured in XML and can do that, it's just a generic
interface).
I was considering doing something like:
<mailet match="All" class="org.....RemoveHeader">
<string-1>X-MyCustomHeader</string-1>
<class-ref-1>RFC2822Headers.RETURN_PATH</class-ref-1>
<class-ref-2>com.journalscape.mail.CustomHeaders.ENTRY_ID</class-ref-2>
</mailet>
The basic idea is that you can specify a header in one of two (three) ways:
1) A direct String which is the header to remove, or
2) A String field reference in a class that contains the header, which is
grabbed through reflection.
[3) The class allows short hand for RFC2822Headers so you don't have to
include the whole package name]
The idea behind was that if you are adding the header with one of your
classes, you can reference it directly from that class, to preserve
encapsulation, etc.
I don't know how to address multiple parameters with the same name, so I
figured I could just arbitrarily add a counter. Then in the init() of the
mailet, I could iterate over all of the parameters and decide what to do
based on the name (whether it started with class-ref or string.
Also... PLEASE suggest better names for those parameters. I can't find
anything I like... something that is descriptive and yet concise. :)
Kenny Smith
JournalScape.com
> -----Original Message-----
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, December 08, 2002 8:38 PM
> To: James Developers List
> Subject: RE: Request for new Mailet
>
>
> Kenny,
>
> Hmmm ... good question. I suppose that you could parameterize the mailet
> with the list of headers to remove. That could work well with the regex
> matchers I have for matching headers with regex patterns. I should be
> posting them after v2.1 ships.
>
> --- Noel
>
> -----Original Message-----
> From: Kenny Smith [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, December 08, 2002 22:58
> To: James Developers List
> Subject: RE: Request for new Mailet
>
> Hi Noel,
>
> Would you (or anyone else) find benefit in a Mailet that could remove
> multiple headers? Or should I leave the removal of multiple headers to
> multiple instances of a one-header removing mailet?
>
> Kenny Smith
>
> > -----Original Message-----
> > From: Noel J. Bergman [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, December 06, 2002 1:25 PM
> > To: James Developers List
> > Subject: RE: Request for new Mailet
> >
> >
> > Kenny,
> >
> > Sounds good. :-) See MimeMessage[Wrapper].removeHeader(), e.g.,
> >
> > //We need to remove this header from the copy we're sending around
> > message.removeHeader(RFC2822Headers.RETURN_PATH);
> >
> > from GenericListserv.java.
> >
> > If this were only about return-receipts, I suppose that one
> could add the
> > option directly to a mailing list processor, but having a
> generic facility
> > might prove useful.
> >
> > --- Noel
> >
> > -----Original Message-----
> > From: Kenny Smith [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, December 06, 2002 16:02
> > To: James Developers List
> > Subject: Re: Request for new Mailet
> >
> >
> > Hi there,
> >
> > I can't make any promises due to my inexperience, but I'll give
> > it a try! :)
> >
> > Kenny Smith
> > JournalScape.com
> >
> > Noel J. Bergman wrote:
> >
> > > If someone feels like writing and submitting a Mailet to
> remove specific
> > > headers, such as "Disposition-Notification-To:", that'd be
> appreciated.
> > >
> > > I don't have time right now, but I'll eventually get to it if
> > no one else
> > > does.
> > >
> > > Motivation: I want to be able to remove the @#$% return
> receipt request
> > > notifications from e-mails sent to mailing lists.
> > >
> > > --- Noel
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> >
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
