Matt Hogstrom wrote:
Starting it is fine but it does require some customization as Aaron
pointed out. Will the start be graceful enough that users will know
that they need to customize it? Perhaps a WARNING message issues at
startup if it hasn't been configured would be nice.
Rick McGuire wrote:
Aaron Mulder wrote:
I don't see a great reason that we're not starting the JavaMail module
by default. Granted, the user may need to change the SMTP server, but
it's going to be easier if they don't need to enable the module too
(e.g. the console usually doesn't see disabled GBeans, and the
load=false is easy enough to miss in config.xml).
I think this is probably a good idea. Most of the problems I've seen
with users attempting to use javamail have been caused by the fact
the javamail module has not been started. This usually manifests as
a provider resolution failure because the transport jars are not
showing up in the classpath. Because the spec jars ARE there by
default, this error doesn't show up until it is used.
Well, it sort of requires customization. One way to use it is to
request the javamail resource, then request a transport object from the
resource. In that mode, yes, customization is required. However, most
of the questions I've been seeing from the user list involved people who
just wish to use the javamail APIs directly. They don't require the
configured javamail resource, just a full set of javamail jars. Since
the provider jars don't get pulled in unless the javamail config is
loaded, the smtp provider can't be located. These users are required to
make a config change just to get the jar files loaded. We could satisfy
the needs of these users by redoing the dependencies a bit and
decoupling the providers from the mail config.
What do you think?
Thanks,
Aaron
