On Monday, Aug 25, 2003, at 10:07 Europe/London, Simon Brooke wrote:
On Monday 25 Aug 2003 8:21 am, Alex Blewitt wrote:Good call. I suggest working with the o.a.g.mail.SMTPTransport class, though I think it is also desirable to have an AbstractTransport abstract superclass that you can descend from. If there's any common functionality that occurs, it can go in the AbstractTransport, which will make it easier to write other transports later.
Sun's implementation has
java.lang.Object +--javax.mail.Service +--javax.mail.Transport +--com.sun.mail.smtp.SMTPTransport
Where Service and Transport are abstract. Do I have to follow Sun's class
structure exactly w.r.t abstract classes, or do you suggest I fold the
functionality of Transport and Service into AbstractTransport?
I suggest that where possible, some of the helper methods of Service and Transport can be realised in AbstractTransport. (Don't know how much of that could be the case, but having worked with some of the Folder/Message things in the API code, I feel that an AbstractFolder is certainly going to come in handy, and will be commiting such later this week).
In simple terms, are we seeking to implement a system in which someone can
just run
sed 's/javax/org.apache.geronimo'
No, the idea is that the code will use all of the JavaMail classes, but the store/transport will be created using
session.getTransport().send(Message);
and 'magically' (i.e. reading the META-INF/javamail.default.providers) return an instance of SMTPTransport.
Final question: When I throw exceptions, what are the rules for the message I
throw? Do I just throw natural language (English) strings, or do I throw
tokens which can be resolved for i18n at print time, and if so what is the
format of those tokens?
Still an on-going issue; for the time being, use the javax.mail.MessageException. Once the [i18n] discussions settle, then it will be something we can retrofit afterwards.
Alex.
