Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: domain of rickmcg@gmail.com designates
 64.233.184.232 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:user-agent:mime-version:to:subject:content-type:content-transfer-encoding;
        b=JavRlGkBD2xSOAuX5ubvBCD2GAptcTOO7ewzlUxAPVt/WUXqM7vTM3fxAHUtzRwf/ygCuRXxvs7nyWZNNktfReGHvqAbD7RkXxWBih4wumzozwfu+b6Jb/VDywCHo4jcLcWbHKXKq/M4bPNViDnFoPURdVlYjRXW1KueSbgBvyM=
Message-ID: <445677C9.7050203@gmail.com>
Date: Mon, 01 May 2006 17:04:09 -0400
From: Rick McGuire <rickmcg@gmail.com>
Reply-To: rickmcg@gmail.com
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Geronimo Dev <dev@geronimo.apache.org>
Subject: Should javamail be reorganized?
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

The more the geronimo javamail support is starting to get used, the more 
uncomfortable I'm getting with the current structure of the javamail 
code.  Let me level-set the situation first, so everybody understands 
the issues.

To start with, the Sun impl of javamail is not really like other jar 
files we consider "spec" code.  This jar files contains lots of classes 
in the javax.mail.* package tree, but it also contains a number of 
backing classes in a com.sun.mail.* tree that help implement certain 
features.  For example, there are various encoders/decoders used by the 
MimeUtility class.  These classes are undocumented, and are separate 
from the public javamail api classes.

In addition to those classes, the Sun javamail jar file contains the Sun 
implementations of the protocol transports and stores (smtp, pop3, and 
imap are supported).  In order to use the Sun version of javamail, you 
only need to javamail jar and the jaf (activation jar).

For the Geronimo implementation, things are split up a little more.  The 
geronimo-spec-javamail jar file contains all of the javax.mail.* 
classes, plus whatever backing utility classes are needed to implement 
some of the features (with org.apache.geronimo.* package structure).  
The jar does NOT however, contain any of the protocol implementations.

The Geronimo protocol implementations are contained in the 
javamail-transport module of the main Geronimo code tree.  This jar 
contains only the protocol implementations, plus some utility classes 
shared between the protocols.  In order to use the Geronimo javamail 
support, you need 3 jar files:  1)  the activation jar, 2) the javamail 
jar, and 3) the javamail-transport jar.  1) and 2) are available 
separately, but 3) IIUC, is only available within a Geronimo snapshot jar. 

And just to confuse matters even more, there is another Geronimo mail 
module.  This module contains GBeans for configuring various mail 
resources.  These GBeans are independent of which javamail 
implementation is being used, so we can keep these out of the discussion.

There is a major problem with the current Geronimo structure.  The 
implementation of the protocol handlers (transports and stores) is 
highly dependent on the version of the api they are written to.  I ran 
into this problem just today. Jira GERONIMO-1957 addressed the fact that 
changes in the geronimo 1.1 javamail spec jar broke the 1.0 version of 
the SMTP transport.  However, the current 1.1 codebase was running with 
this obsolete code, so I had to back port the trunk version of the SMTP 
transport into the 1.1 code tree.  This also raised the question of 
whether we should pull back the other transport/store implementations 
into 1.1.

Now this is an issue that never arises with the Sun implementation.  
Since the protocol handlers are contained within the API jar, you can 
never get these packages out of sync.  They travel around together by 
definition.  In order for somebody to make use of the Geronimo javamail 
stack, you'd need to pull down the javamail and activation spec jars, 
then extract a javamail-transport jar from a Geronimo snapshot that was 
using a matching spec level.  Lots of opportunity for error here, and it 
makes it difficult for other projects to use the javamail support.  Axis 
is already doing this, but fortunately, they are only using the 
javax.mail.* stuff for Mime encoding support and are not dependent on 
transport or store implementations.

It seems, at a minimum, that the javamail-transport code should be moved 
from being a Geronimo module to a spec component.  Ideally, it really 
should be merged into the javamail spec module to mirror how the Sun 
implementation works. 

Am I missing something?  Is there some compelling reason why this should 
be structured this way?  I really suspect we ended up at this point 
through a combination of ignorance and historical accident.  Originally, 
the smtp transport code was just a sandbox component.  It was upgraded 
into working code because the console wanted to implement a portlet for 
configuring mail resouces configurations.  When this code was promoted 
out of the sandbox, a new javamail-transport module was created because 
we weren't really sure where it really belonged....and we named it badly 
to boot.  It really should have been called javamail-protocol.  The 
transport portion of the name starting looking silly when we add the 
pop3 STORE protocol handler.

Rick