geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <ammul...@alumni.princeton.edu>
Subject Re: Should javamail be reorganized?
Date Tue, 02 May 2006 15:56:03 GMT
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