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
