james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Webb" ...@inovem.com>
Subject RE: [PATCH] mbox mail repository V2
Date Tue, 19 Aug 2003 08:32:08 GMT

> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com] 
> Sent: 18 August 2003 18:38
> To: James Developers List
> Subject: RE: [PATCH] mbox mail repository V2
> Jason,
> > Great! I will quite happily change the POP3 handler (and the other
> > repositories) if someone wants me to.
> That would be great.  :-)  First we've one issue to resolve.
> I think that we're agreed on void remove(Collection).  There 
> seems to be a bit of a dispute over the contents of the 
> Collection; whether to use String keys or Mail/MailImpl 
> instances.  Currently POP3Handler actually maintains the latter.
> If we were using JDK 1.5, it would be simple: we could have 
> both, just as we currently have both:
>    remove(MailImpl);
>    remove(String);
>    remove(Collection<MailImpl>);
>    remove(Collection<String>);
> However, that is not presently an option.
> > My prefered option is Collection<String>. Much lighter and most 
> > implementors (and users) of MailRepository use the keys to access 
> > items anyway.
> True enough, and my initial thought.  HOWEVER, at the moment 
> the only client for this method is the POP3 handler, and that 
> code is currently maintaining a Collection<MailImpl>, so 
> using a lighter weight Collection<String> would require more 
> code and memory, not less.

No, I think you're right. Its easier for the mbox repository, but it's
not a big issue. The remove(Collection<MailImpl>) is probably for the
> FWIW, the remove method is always implemented based on the 
> key.  The version that takes a mail object uses getName() to 
> get the key, and then calls the key-based method.  But that 
> doesn't mean that the key-based method couldn't have been protected.
> > No I don't think a redesign [of MailRepository] is needed.
> To elaborate, I was referring to the fact that we need to 
> redesign or replace MailRepository to support IMAP, which is 
> one reason why we've looked at JavaMail storage.
This is something I've been thinking about.
There are two options here:
1) I implement the remove(Collection<MailImpl>) using the current
MailRepository system and leave it at that. This could then be used in
v2 and early v3. The work for this is almost done. Oh, and sort out the
exceptions as well.
2) I will try and come up with an initial design for a JavaMail
implementation. This is NOT a quick fix :) 
> > All we need is an agreed behaviour to deal with the exceptions. The 
> > only time a runtime exception should be thrown is in the event of a 
> > critical error (e.g. I can't open the repository at
> > all) rather than more internal issues (unable to find a 
> message etc).
> Are you proposing that we add throws clauses to 
> MailRepository during this change?  What would you throw?  We 
> just need a nested exception.  Choices
> include:
>   - javax.mail.MessagingException
>   - org.apache.avalon.framework.Cascading*
>   - org.apache.commons.lang.exception.*
> Javadocs are below.
My current favourite would be to use javax.mail.MessagingException. This
is because when we finally implement JavaMail storage I think that these
are the exceptions the storage implementations should be throwing.
JavaMail already supports the the following:
"AuthenticationFailedException, FolderClosedException,
FolderNotFoundException, IllegalWriteException, MessageRemovedException,
MethodNotSupportedException, NoSuchProviderException, ParseException,
ReadOnlyFolderException, SearchException, SendFailedException,
StoreClosedException "

A lot of these exceptions could be meaingfully thrown by any of our
current storage implementations and it supports cascading exceptions so
I think it's a winner. Just my 2c worth :) 
> 	--- Noel
> javadocs:
>   Standard: 
> http://java.sun.com/j2se/1.4.1/docs/api/java/lang/Throwable.ht


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message