[Fulcrum] RFC - Contributing fulcrum-commonsemail-service ...

[Siegfried Goeschl <si...@it20one.at>]

Hi folks,

due to a migration of an ancient Turbine application to CVS HEAD my 
implementation for creating and sending emails was completely broken. 
Therefore I migrated my code from my old Turbine service into a Fulcrum 
service which I would like to contribute. To make a meaningful 
implementation I patched the unreleased commons-email library. I already 
sent the diffs to Eric Pugh since he is committer there - I refer to 
commons-email-rc5.jar then ...

What does the service do

+) provides factory method for creating preconfigured SimpleEmail, 
MultiPartEmail and HtmlEmail. The created email is fully configured 
regarding mail server settings, authentication and email headers
+) provide diagnostic features such as TransportListeners, mail.debug 
and dumping of emails
+) support for multiple configurations and SMTP servers using a 
domain-based configuration

Current state

+) I did not do any field testing yet since I just finshed it ... :-)

The website can be found at 
http://people.apache.org/~sgoeschl/fulcrum/commonsemail/


Cheers,

Siegfried Goeschl

PS: Since Eric mentioned the original Turbine email service - there were 
a few classes but AFAIK they did not constitute a full-blown Turbine 
service. Did I miss something here?!



-------- Original Message --------
Subject: 	Re: [commons-email] RFC about improving the code ....
Date: 	Sat, 21 May 2005 14:43:17 -0700
From: 	Eric Pugh <ep...@upstate.com>
To: 	siegfried.goeschl@it20one.at
References: 	<42...@it20one.at> 
<42...@upstate.com> 
<42...@it20one.at>



Sounds great..   How close is it to the original Turbine email service? 
  It's a funny path..   Commons-email came from Turbine, and now, with 
a fulcrum component, goes back to Turbine land!

Eric
On May 20, 2005, at 1:39 AM, Siegfried Goeschl wrote:

> Hi Eric,
>
> I'm working on the trunk version of SVN and applied my changes 
> yesterday night. But I would like to finish my 
> fulcrum-commonsemail-service together with the code changes to see if 
> everything works. I send you the patches asap. If you think it is a 
> resonable addition to Fulcrum I contribute it .... :-)
>
> Eric Pugh wrote:
>
>> Siegfried,
>>
>> Are you talking about the latest commons-email, or the old one that 
>> is used in Turbine?  I've been trying to release the 1.0 version for 
>> the past couple months, but haven't due to a stack of different 
>> issues been able to do it.
>>
>> The changes you make seem reasonable, I just want you to make sure 
>> you are looking at CVS HEAD!   I am going to release 1.0 the way it 
>> is, but I'd be happy to take your patch and do a 1.0.1 or something 
>> pretty quickly..
>>
>> Eric
>>
>>
>> On May 19, 2005, at 10:10 AM, Siegfried Goeschl wrote:
>>
>>> 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
>>>
>>
>>
>