geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <>
Subject Re: Geronimo standard Sun-API jars (JavaMail)
Date Sat, 09 Aug 2003 12:38:54 GMT

On Friday, August 8, 2003, at 01:45  pm, Alex Blewitt wrote:

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

I always wondered why more protocols didn't extend the Servlet spec. 
e.g. I wrote a JMS extended Servlet API (the 'messagelet API' ) as part 
of the Messenger project in Jakarta Commons and it worked out quite 
nicely. Processing email or SOAP requests would work out quite 
similarly too I suppose.

Having said that - I think there's a common OO gotcha where we think we 
should reuse things because they're there & reuse is good. Its often 
better to use an API that accurately reflects what your actual 
application requires - rather than reusing an API just because its 
there. Otherwise you might find you end up with a leaky abstraction.

I guess the James folks considered reusing the Servlet API right?


View raw message