Re: [Fwd: [commons-email] RFC about improving the code ....]

[Joe Germuska <Jo...@Germuska.com>]

This is interesting; I've just recently been thinking about asking 
the community if there would be interest in adjusting commons-email 
so that there was a "Sender" API.  I'm not quite sure how we would 
re-engineer it in a backwards compatible way, but I'm interested in 
an architecture which prevents my development team from accidentally 
thinking that it's OK to send a message directly in an app; instead, 
they'd have to use the Sender Implementation.

This would then enable dropping in an implementation which didn't 
actually send the message, as in for example a test or development 
environment.

If there's interest in this, does anyone have a strategy for doing 
it?  It is a little late to remove the "send()" method, although I 
suppose it could be deprecated.

Joe


At 7:13 PM +0200 5/19/05, Siegfried Goeschl wrote:
>FYI
>
>Siegfried Goeschl
>
>-------- Original Message --------
>Subject: [commons-email] RFC about improving the code .... Date: 
>Thu, 19 May 2005 19:10:17 +0200 From: Siegfried Goeschl 
><ma...@it20one.at> 
>Reply-To: 
><ma...@it20one.at>siegfried.goeschl@it20one.at 
>Organization: IT20one GmbH To: Eric Pugh 
><ma...@upstate.com>
>
>
>Hi Eric,
>
>long story - since I'm in the middle of migrating my old Turbine
>application to CVS HEAD I stumbled across commons-email and I'm
>currently migrating a very old Turbine service for sending emails to use
>commons-email to a Fulcrum service and having a few problems, and .....
>
>Since the mailing list does not respond to my subscription and you are
>the main committer .... I need to patch the existing code to fulfill
>some basic requirements
>
>1) having a few getters for basic properties of EMail would be nice
>(subject, fromAddress) to enable some diagnostic ouptut if anything goes
>wrong while creating the MimeMessage. Having said that a toString()
>implementation would not be bad either.
>
>2) more significant I need to seperate the creation of the underlying
>MimeMessage from actually sending it, e.g. I do a lot of stuff with
>SMIME signature where you build the MimeMessage and then sign it.
>Building the MimeMessage (the hard part) is already done by
>commons-email but it would be useful to intercept the actual sending to
>provide more flexibility. I think of
>
>public final MimeMessage getMimeMessage();
>public void buildMimeMessage() throws EmailException;
>public void sendMimeMessage() throws EmailException;
>
>public void send() throws EmailException
>{
>    this.buildMimeMessage();
>    // now it is possible to call getMimeMessage()
>    this.sendMimeMessage();
>}
>
>3) access to the MimeMessage allows to retrieve the message id - the
>only way to keep track of message sent by the SMPT server
>
>I hope my comments make sense - could you forward the message to the
>mailing list  ... as always I have little time to wait for the outcome
>of lenghty discussion so I start doing the work tommorrow ... :-)
>
>Cheers,
>
>Siegfried Goeschl


-- 
Joe Germuska            
Joe@Germuska.com  
http://blog.germuska.com    
"Narrow minds are weapons made for mass destruction"  -The Ex