commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Stanley <mstan...@mstanley.net>
Subject Re: [email] Please add new build to ibiblio
Date Mon, 04 Oct 2004 13:28:43 GMT
On Fri, 2004-10-01 at 08:21, Martin van den Bemt wrote:

> Maybe this has a better home at velocity ?


Maybe, but this does seem like common practice with the email.  

But lets talk about this for a second.  (and revisit - the plug-in
adapter idea that I gracefully spoke up against earlier).  

For my project, I developed an alternative way to use email in the
Spring Framework.  I don't terribly care for the approach taken by the
Spring Framework (discussed in this blog entry -
http://www.jroller.com/page/raible?anchor=sending_velocity_based_e_mail)

In fact, I prefer the commons-email component.  I believe it has a
straight forward, OO design for creating and sending mail in Java.  

To centralize my SMTP configuration, and utilize Spring IOC, I created a
Factory for generating Email objects.    This is very basic, but offers
a clean way to both integrate commons-email into IOC containers, and
provide TemplateEmail apdapters.  The factory interface looks something
like:

public interface EmailFactory
{
    public TemplateEmail createEmail();
    // other convenience methods such as the following
    public TemplateEmail createEmail(Collection toList, Collection
ccList);

    public void setHost(String host)
    public void setPort(int port)
    public void setUsername(String username);
    public void setPassword(String username);

    public void setFromEmail(String fromEmail);
    public void setFromName(String fromName);
}
   
Then in my Spring config file.  I have the following.

<bean id="beanThatSendsEmail" class="some.bean.that.sends.Email">
    	<constructor-arg><ref local="emailFactory"/></constructor-arg>
</bean>
    
<bean id="emailFactory" class="net.mstanley.email.VelocityEmailFactory">
		<constructor-arg><ref local="velocityEngine"/></constructor-arg>
  <property name="host">localhost</property>
  <property name="fromEmail">myApp@mstanley.net</property>
</bean>

<bean id="velocityEngine"
class="org.springframework.ui.velocity.VelocityEngineFactoryBean">
  <property name="velocityProperties">
  			 <props>
  				  <prop key="resource.loader">class</prop>
  				  <prop key="class.resource.loader.class">
  					  
org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader
  				  </prop>
  			</props>
  </property>
</bean>


My client code simply becomes:

TemplateEmail email = emailFactory.createEmail(toList, ccList);
email.setSubject("Some meaningful subject");
email.setPlainTextTemplate("velocity/mail/SampleEmail.vm");
email.send();

I'll send the interface, abstract implementation, and Velocity
implementation of TemplateEmail and email factory.  

With this approach VelocityEmailFactory and VelocityEmail can become
"template mail adapters".  These adapters can be additional modules.

Thoughts?

- Mike



> 
> Mvgr,
> Martin
> 
> On Fri, 2004-10-01 at 01:58, Joe Germuska wrote:
> > At 12:54 PM -0700 9/30/04, Martin Cooper wrote:
> > >  > Hmmm..  Personally, I don't think putting it in a different package is
> > >>  overkill.  Adding velocity requires the addition of Velocity.jar to
> > >>  build, but not to run (unless of course, you use the class ;-).
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message