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] http://java.sun.com/j2ee/1.4/docs/api/javax/mail/Store.html > [2] http://java.sun.com/j2ee/1.4/docs/api/javax/mail/Transport.html > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- 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) http://www.Monson-Haefel.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
