geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Re: svn commit: r280240 - /geronimo/trunk/modules/assembly/src/plan/j2ee-server-plan.xml
Date Mon, 12 Sep 2005 04:28:29 GMT
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

Mime
View raw message