Serge,
If you are proposing that we add:
void remove(Collection);
to the org.apache.james.services.MailRepository interface, and to the
implementations, I agree. I think that would be the cleanest solution, at
least until we can replace/redesign MailRepository.
What shall the Collection hold? Our choices seem to be Collection<MailImpl>
or Collection<String>, which match the existing remove methods. Neither is
exposed to the Mailet API, although this is not an issue for services.
Collection<Mail> would be castable internally, and matches what we actually
have at the moment. Collection<String> is lighterweight.
FWIW, I have to say that I am not comfortable with the lack of exception
handling in the MailRepository interface. Throwing RuntimeException is
evil. However, I don't think that a redesign is necessary to add
remove(Collection). The question about exception handling comes up because
we ought to throw an exception chain for all failures, and we can't do that
with normal Throwable prior to JDK 1.4 (hence all of the ad hoc chained
exception classes in other parts of Java).
What does everyone think?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
