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).
Alex.
