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? Rick McGuire
-
