+1
Regards,
Peter
Scott Eade wrote:
Siegfried,
+1 for sure.
Scott
Siegfried Goeschl wrote:
Hi folks,
regarding the contribution
+) shall I take no answers at all as -1, +0, -0 or +1 ... :-)
+) I added the stuff from the old Turbine implementation to setup the
email using a Hashtable (but not Criteria since it derives from
Hashtable anyway). This allows to create a ready-to-be-sent email
using a Hashtable by invoking one factory method on the service.
Beware - this is a functionality of the service and not being part of
commons-email any longer. So any migration from an older Turbine
implementation should be a breeze.
Cheers,
Siegfried Goeschl
-------- Original Message --------
Subject: [Fulcrum] RFC - Contributing fulcrum-commonsemail-service
...
Date: Thu, 26 May 2005 15:54:49 +0200
From: Siegfried Goeschl <[EMAIL PROTECTED]>
Reply-To: Turbine Developers List
<[email protected]>, [EMAIL PROTECTED]
Organization: IT20one GmbH
To: Turbine Developers List <[email protected]>,
Turbine Users List <[email protected]>
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 <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
------------------------------
Peter Courcoux
Telephone : +44 (0)1923 661488
Mobile : 07880 605626
email : [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
