incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Monson-Haefel <>
Subject Re: [geronimo] Me, James and javaMail
Date Wed, 06 Aug 2003 17:51:35 GMT
Obviously we will need a JavaMail implementation. Isn't there one out there
somewhere that is BSD like?  What I would like to see for a future release of
Geronimo is an E-Mail Message Bean container. That is, a Message Bean that can
process incoming e-mails.  One way to accomplish this is to implement the
messaging aspects of the J2EE connector architecture.  I would be happy to help
with that after we get the standard service working.

Danny Angus wrote:

> Hi,
> Probably biting off more than I can chew here, I'm currently as busy as the
> day is long :-(, but I'd be happy to look at implementing javaMail for
> Geronimo.
> For those who don't know who the hell I am (or what I'm taking about) I'm a
> James developer, and James is Apache's 100% Java mailserver.
> Its worth noting that the James developers have, from time to time, had
> "issues" with the design of Java mail, primarily that it is a client
> oriented API which makes life difficult for server developers, we're left
> with the choice of rolling our own or shoehorning round pegs into square
> holes.
> Notwithstanding this there are already moves afoot to create several
> alternative implementations of javaMail abstract classes, (particularly
> message "Store"s[1] where we see a market for implementations of MBOX and
> other popular text based systems), and we've also toyed with the idea of
> providing our own outgoing SMTP implementation (we currently use javaMail)
> in order to have greater control over outgoing mail behaviour (we'd like to
> optimse sending and implement connection re-use), and given that we're here
> discussing Geronimo perhaps this could be an implementation of
> "Transport"[2] to replace com.sun.mail.smtp.SMTPTransport
> >From the POV of creating another javaMail implementation you may not realise
> that Sun have already put a huge amount of implementation into javax.mail.*,
> and very much of the inheritance root of javax.mail classes is made up of
> abstract classes rather than interfaces. You only have to look at the
> javadocs for j2ee to see that there's a much greater ratio of classes
> (abstract and concrete) to interfaces in javax.mail than most other
> packages.
> Unfortunately this removes much of the scope we would like to have for
> "correcting" the client bias in the API, by creating a ground-up
> server-centric implementation.
> Anyway I guess I should wait 'till we get a geronimo list before discussing
> this much further.
> d.
> [1]
> [2]
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Richard Monson-Haefel
Author of J2EE Web Services (Addison-Wesley 2003)
Author of Enterprise JavaBeans, 3rd Edition  (O'Reilly 2001)
Co-Author of Java Message Service (O'Reilly 2000)

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message