Noel,
1) My problem with the "magic" addresses was that I didn't find another way to
overcome the the fact that the available constructors of MailAddress throw
ParseException, and so all different solutions I've tried where getting a "exception
not caught nor declared" compile error. Please give me a (java coding) suggestion.
2) Obviously no problem changing EMPTY to null, I'll do it, but he have to remember
that NULL will have a different meaning than null.
3) I'm exploring the convenience of having an AbstractRedirect class, extended by
Redirect and the other mailets; this way some minor "inconsistencies" required by
Redirect for backward compatibility (like "default" convergence between the handling
of "recipients" and "to") could be managed separately, keeping the overall code
cleaner.
I'll have to slow down for a couple of days; in the meantime I may do some minor work,
so please help me with point 1 above.
Thanks,
Vincenzo
>
> Vincenzo,
>
> I've started to look over the code. Looks good so far. A few apparently
> redundant methods, and some typos, but all in all it looks good.
>
> With the exception of the NULL address, I don't think that the rest belong
> in the general MailAddress class. They are specific to the
> processing done
> by Redirect and subclasses. That's why at one point I'd had
> something like:
>
> class Redirect {
> ...
> class MailAddress extends org.apache.mailet.MailAddress {
> ...
> }
> ...
> }
>
> Also, you called it EMPTY. I thought that we had agreed to call it NULL,
> since it is referred to as a null sender in the RFC documents.
>
> As I said, generally the work looks really good so far.
>
> --- Noel
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
