geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danny Angus" <>
Subject RE: Geronimo standard Sun-API jars
Date Fri, 08 Aug 2003 10:36:21 GMT
Henri wrote:

> The first thing I'm looking for from Geronimo is not a working J2EE
> server, but a redistributable version of:
> javamail.jar

I belive that it has been determined that JavaMail is redistributable when
packaged with it's licence, and whatever else.

It is not a simple matter, for JavaMail, of typing interfaces in from the
Unfortunately the inheritance root of most of JavaMail are abstract classes,
not interfaces, and in addition to this there are some key classes which are
concrete, such as MimeMessage.

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.

Just for instance javaMail supports outgoing SMTP and incoming POP and IMAP
but not the converse of each, and infact the API refers to incoming
collection protocol handlers as "Stores", and outgoing protocol handlers as
"Transports", a freudian distinction which clearly marks this down, in my
mind at least, as an out-and-out client product.

It is also the case that a single global mail "session" exists in a vm,
again underlining the assumption by Sun that any vm running javaMail will
most likely be doing so as a single user mail client, not as a multi user

None of these things stop James from making good use of javaMail, and we are
vaguely planning to do more, Sun distributes an RI for several protocol
handlers (Transports and Stores) and James would like to have greater
control over some and some completely new ones, so there _is_ scope, will
and expertise available for implementing javaMail in geronimo but IMO there
are serious caveats surrounding the value of re-implementing javaMail in
it's entirety just for licencing convenience.

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


View raw message