geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <>
Subject Re: Geronimo standard Sun-API jars (JavaMail)
Date Fri, 08 Aug 2003 12:45:40 GMT

On Friday, Aug 8, 2003, at 11:36 Europe/London, Danny Angus wrote:

> Henri wrote:
>> The first thing I'm looking for from Geronimo is not a working J2EE
>> server, but a redistributable version of:
>> javamail.jar
> None of this is beyond the scope of a re-implementation, but it isn't
> trivial and questions would have to be answered about the value of this
> effort given that JavaMail is, by Sun's own admission a client-side 
> API not
> a server one, and that the James project have already uncovered a 
> number of
> gotchas for server development caused by this client focus.

One major gotcha, for example, is that the JavaMail API doesn't provide 
a JavaBean view of a message. That is, you can do ${message.subject} 
but not ${message.content} since the getContent and setContent methods 
take different argument types (which buggers up Introspection).

Object getContent()
void setContent(Part part)

It also has some decidedly odd interfaces, such as void setFrom() as 
well as void setFrom(Address address)

> The best thing we could do as a community in relation to mail, in my 
> very
> humble opinion,  would be to extend the API in geronimo to provide the
> framework for server functionality which we miss, and to include an
> implementation of the Apache Mailet API, but this would depend heavily 
> upon
> the direction the project takes with respect to whether geronimo is (or
> tries to be) the J2EE RI or just a top quality product.
> I believe that the Mailet API is, for mail, much more closely aligned 
> with
> the principles of J2EE than javaMail is, which probably really belongs 
> in
> J2SE.

I concur. JavaMail is fairly fundamentally broken (as described above) 
and what's needed is a better implementation. However, it doesn't 
preclude a set of JavaMail-esque wrappers to facilitate interfaces by 
those that are expecting it, but the preference would be to provide a 
cleaner implementation.

Maillet support would be great, and one thing I don't think any other 
J2EE server supports is a Mail-request based protocol, to allow (for 
example) JMS to be sent over the top of SMTP, or trigger incoming mails.

Anyone know why the Maillet API didn't subclass Servlet, BTW? I'd have 
thought that

public class Maillet extends GenericServlet {
   public void service(SMTPRequest request, SMTPResponse) throws 
ServletException, IOEXcception {

would have been a really good way to handle incoming SMTP messages 
(viewing the Request/Response pair as a 'channel' rather than a one-off 
HTTP input/output).


View raw message