Re: Geronimo standard Sun-API jars (JavaMail)

[Alex Blewitt <Al...@ioshq.com>]

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.

RE: Geronimo standard Sun-API jars (JavaMail)

["Noel J. Bergman" <no...@devtech.com>]

> Anyone know why the Maillet API didn't subclass Servlet, BTW?

<<sigh>> Someone brings this up at least every 6 months.

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

The mailet pipeline isn't request/response, nor is it coupled with SMTP.
Don't confuse the asynchronous mailet pipeline with the synchronous protocol
handler.  :-)

But please, if you want to discuss this, server-dev@james.apache.org is a
better place.

	--- Noel

RE: Geronimo standard Sun-API jars (JavaMail)

[Danny Angus <da...@apache.org>]

 Richard Monson-Haefel wrote,

> I think it would be a good idea to support Jame's current
> component model as
> well as providing an adapter that bridges the gap between Mailets and the
> Message Driven Bean model.  Both are useful.  For Geronimo the MDB adapter
> would be useful because it would allow James to plug directly into the
> message driven bean container system. There are some problems like
> transactional messaging (perhaps James addresses this I'm not
> sure yet), but
> overall providing Mailet support through the J2EE standard MDB component
> model, as well as the "native" James component is a good thing..


javaMail provides an interface for implementations of protocols.
James currently implements Mailet by passing every SMTP message, out going
or incoming, into a single message pipeline, this pipeline is the mailet
container and mailets are used to implement server functionality.
You know remote/local delivery, spam filtering, list serving etc.

This is partly achieved by allowing mailets to kill messages and insert new
ones at the top of the pipe, and partly by making the whole thing an
asynchronous spool, mail is put in at one rate and processed at another.

It should be equally possible to implement a J2EE compliant "mail service
provider" in the form of a "Transport" for SMTP which was itself a self
contained mailet pipeline, we'd have to look closely into the provider
lifecycles to see how feasable this is though.

In that way while javaMail is not well suited to building servers it would
still be possible to add Mailet to to our javaMail impl. for outgoing mail
in a compliant manner. :-)

d.

Re: Geronimo standard Sun-API jars (JavaMail)

[Richard Monson-Haefel <Ri...@Monson-Haefel.com>]

James Strachan wrote:

> >
> > 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 think it would be a good idea to support Jame's current component model as
well as providing an adapter that bridges the gap between Mailets and the
Message Driven Bean model.  Both are useful.  For Geronimo the MDB adapter
would be useful because it would allow James to plug directly into the
message driven bean container system. There are some problems like
transactional messaging (perhaps James addresses this I'm not sure yet), but
overall providing Mailet support through the J2EE standard MDB component
model, as well as the "native" James component is a good thing..

As far as modifying James: That was never my intention. My thoughts are to
write an adapter, perhaps a J2EE Connector, that bridges the gap between the
James Mailet and MDB component model.  Obviously, a lot more research has to
be done on the topic before we know if this would work.

Richard

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

RE: Geronimo standard Sun-API jars (JavaMail)

[Danny Angus <da...@apache.org>]

James wrote:

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

Right, although I wasn't involved then I know that it was part of the
original idea.
It has been recondered and rejected several times since as well, for reasons
I'm beginning to agree with. :-)

Re: Geronimo standard Sun-API jars (JavaMail)

[James Strachan <ja...@yahoo.co.uk>]

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?

James
-------
http://radio.weblogs.com/0112098/

RE: Geronimo standard Sun-API jars (JavaMail)

[Danny Angus <da...@apache.org>]

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

Mailet provides for asynchronous processing of mail messages not
request-response handling.
That aside Servlet now contains some parts which an asynchronous mail API
would not be easily able to implement.

d.