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

Joe Germuska Thu, 19 May 2005 15:20:29 -0700

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 <mailto:[EMAIL PROTECTED]><[EMAIL PROTECTED]> Reply-To: <mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED] Organization: IT20one GmbH To: Eric Pugh <mailto:[EMAIL PROTECTED]><[EMAIL PROTECTED]>


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 [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex

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

Reply via email to