geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: Should javamail be reorganized?
Date Tue, 02 May 2006 16:16:39 GMT
Maybe we should move all of the javamail related code to a repos/asf/ 
geronimo/javamail.  That way they can move as a single unit  
independently of main line Geronimo or the specs.

-dain

On May 2, 2006, at 8:56 AM, Aaron Mulder wrote:

> I'd certainly support moving the transports out of the Geronimo server
> SVN tree and into a separate repos/asf/geronimo/mail-transports tree
> or something.  That way they could be independently versioned along
> with the spec JARs and you wouldn't ever have to pull something out of
> a server snapshot to get a working set of JARs.  (I don't much like
> putting transports into the spec module.)
>
> I also think Dain's suggestion is a good one to offer a mail uberjar
> with activation, mail, and transports.
>
> Aaron
>
> On 5/2/06, Dain Sundstrom <dain@iq80.com> wrote:
>> Why not create an additional geronimo-javamail-nodep-x.x.jar artifact
>> that has all the jars merged together?
>>
>> -dain
>>
>> 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
>> >>
>> >>
>> >>
>> >>
>>
>>


Mime
View raw message