You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Rick McGuire <ri...@gmail.com> on 2006/05/01 23:04:09 UTC
Should javamail be reorganized?
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.
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.
Rick
Re: Should javamail be reorganized?
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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 <da...@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
>>> >>
>>> >>
>>> >>
>>> >>
>>>
>>>
>
Re: Should javamail be reorganized?
Posted by Dain Sundstrom <da...@iq80.com>.
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 <da...@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
>> >>
>> >>
>> >>
>> >>
>>
>>
Re: Should javamail be reorganized?
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
I agree w/ this. Move to its own release cycle and its own
geronimo/mail-transports SVN dir; this will facilitate integration w/
Harmony. The spec jars should still remain separate. Create an
uber-jar to those who are jar dysfunctional.
Regards,
Alan
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 <da...@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
>> >>
>> >>
>> >>
>> >>
>>
>>
Re: Should javamail be reorganized?
Posted by Bruce Snyder <br...@gmail.com>.
On 5/2/06, Aaron Mulder <am...@alumni.princeton.edu> 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.
+1 on both suggestions. Also, I think that the best way to include the
mail-transports module in a Geronimo build is through the use of the
svn:externals property to pull from
https://svn.apache.org/repos/asf/geronimo/mail-transports into the
modules/mail-transports directory for Geronimo builds.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache Geronimo - http://geronimo.apache.org/
Apache ActiveMQ - http://incubator.apache.org/activemq/
Apache ServiceMix - http://incubator.apache.org/servicemix/
Castor - http://castor.org/
Re: Should javamail be reorganized?
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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 <da...@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
> >>
> >>
> >>
> >>
>
>
Re: Should javamail be reorganized?
Posted by Dain Sundstrom <da...@iq80.com>.
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
>>
>>
>>
>>
Re: Should javamail be reorganized?
Posted by Rick McGuire <ri...@gmail.com>.
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
>
>
>
>
Re: Should javamail be reorganized?
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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.
Regards,
Alan