Aaron Mulder wrote:
I'm fine if we include mail as a separate plan. Maybe I
misinterpreted the commit, but it looked like it was removed entirely. On
the other hand, if we don't have a working SMTP provider, then parhaps
that's for the best. I haven't yet figured out the actual status of our
mail implementation.
There are no reasonable defaults for the server and it's configuration
(localhost only works on /some/ Unix-like distros) so I don't think it
should be included in the default server plan.
I think we should provide an example that shows people how to configure
mail in both of two ways:
1) as part of their application
2) as a separate plan that can be customized as needed along with info
on how to reference it from an application plan. This is what we do
in the CTS setup.
The SMTP provider does work when configured correctly. Part of that
setup includes getting the provider jar into a suitable classloader (so
that the properties files in META-INF get resolved correctly). It's just
messy due to some aspects of the mail API.
Anyway, generally speaking, I don't really fancy properties for
manageable attributes. Particularly not for those we know will be
interesting. I think we should have a set of manageable attributes like
"SMTP Server", "SMTP Username", "SMTP Password", "SMTP SSL Enabled", "SMTP
Port", etc. -- the stuff you configure when you configure a mail client.
I don't like giving just a big text area and figuring the user needs to
know what magic property names to put in there.
SMTPTransportGBean does this. However, it does it by setting the
applicable values into a Properties passed to the mail provider. This
works but I can't help but wonder if there is a better way.
--
Jeremy
