-- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. http://www.edgetechservices.net/ 678.910.8017 AIM: jmitchtx Yahoo: jmitchtx MSN: [EMAIL PROTECTED]
----- Original Message ----- From: Joe Germuska
To: Jakarta Commons Developers List
Sent: Thursday, May 19, 2005 2:56 PM
Subject: Re: [Fwd: [commons-email] RFC about improving the code ....]
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 <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] Organization: IT20one GmbH To: Eric Pugh <[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
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
