geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Should javamail be reorganized?
Date Tue, 02 May 2006 15:51:22 GMT
Why not create an additional geronimo-javamail-nodep-x.x.jar artifact  
that has all the jars merged together?


On May 2, 2006, at 1:57 AM, Rick McGuire wrote:

> Alan D. Cabrera wrote:
>> 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.
> I think part of my concern with javamail  is the growing desire to  
> use it decoupled from Geronimo.  Axis is already doing this, but  
> only using the base API classes (which are more implementation than  
> "spec".  There's a lot of executable code in the base API  
> classes).  Axis is already doing this for their attachment  
> support.  I hear rumblings that Harmony would like to use this  
> package as well.  As currently bundled, there is no one place you  
> can go to obtain just the complete Geronimo javamail  
> implementation.  Right now, you need to download 2 spec jars +  
> extract the javamail-transport jar from a Geronimo snapshot in  
> order to do this. The code in javamail-transport has no  
> dependencies on any other part of Geronimo, so that coupling is a  
> bit artificial.
> The other reason is just one of pragmatics.  Users seem to be  
> tripping over this all the time, getting errors about unable to  
> load the smtp protocol because the javamail-transport is missing  
> from there configuration.  If the protocol handlers and the API  
> classes are together, as with the Sun jars, these errors will no  
> longer occur.
>> Regards,
>> Alan

View raw message