You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Simon Brooke <si...@jasmine.org.uk> on 2003/08/25 11:07:10 UTC

Newbie stuff - implementing SMTPTransport in mail

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?

In simple terms, are we seeking to implement a system in which someone can 
just run 

sed 's/javax/org.apache.geronimo' 

over their code which extends (e.g.) the JavaMail classes and have it all 
guaranteed to work?

> I think that the code should live in the \modules\javamail\src\java,
> rather than \specs\javamail\src\java, because it's an Apache
> implementation.

OK, will do.

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?

Cheers

Simon

-- 
simon@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/
	;; Our modern industrial economy takes a mountain covered with trees,
	;; lakes, running streams and transforms it into a mountain of junk,
	;; garbage, slime pits, and debris. 		      -- Edward Abbey


Re: Newbie stuff - implementing SMTPTransport in mail

Posted by Jason Dillon <ja...@coredevelopers.net>.
> In simple terms, are we seeking to implement a system in which someone 
> can
> just run
>
> sed 's/javax/org.apache.geronimo'
>
> over their code which extends (e.g.) the JavaMail classes and have it 
> all
> guaranteed to work?

Yes and no ;-)  I would hope that someone using JavaMail would use 
factory methods to gain access to the underlying implementation.

The point is to provide an impl which can be used as a drop-in 
replacement for the Sun version under the Apache license.  So if I 
wrote a mail client which used the JavaMail API (following the spec) 
then I should be able to replace Sun's JavaMail jars with the Geronimo 
JavaMail jars and it should still work.


> 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?

I do not believe there is a final resolution on this yet.  We will be 
moving towards i18n but right now not much (or any) of the system does.

--jason


Re: Newbie stuff - implementing SMTPTransport in mail

Posted by Alex Blewitt <Al...@ioshq.com>.
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.