geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: Should javamail be reorganized?
Date Tue, 02 May 2006 16:26:56 GMT
I do not like the idea of moving the specs out.


Regards,
Alan

Dain Sundstrom wrote:
> 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