geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <>
Subject Re: Should javamail be reorganized?
Date Tue, 02 May 2006 00:34:49 GMT
Rick McGuire wrote:
> 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.
This is normal for just about all the spec implementations for 
Geronimo.  1) spec jar, 2) impl, 3) GBean-mumbo-jumbo.  Hopefully, w/ 
XBean, the GBean stuff will go away. 
> 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. 

I look at things from a different viewpoint.  I never really understood 
why any part of the implementation had to be bundled with the JavaMail 
spec jar.  Folklore has it that the specification implies that this must 
be the case.  This flies in the face of my experience w/ many of the 
Java JSR specs that I am familiar with; I have not read the spec for 
fear of being asked to support it.  :)  IMO, doing something because Sun 
does it that way is not a good argument.

Can you explain why *any* part of the implementation needs to be a part 
of the spec jar?  My personal preference is to keep the protocol 
handlers out of it.


View raw message