You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Siegfried Goeschl <si...@it20one.at> on 2005/05/31 18:36:47 UTC
[Fwd: [Fulcrum] RFC - Contributing fulcrum-commonsemail-service ...]
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 <si...@it20one.at>
Reply-To: Turbine Developers List <tu...@jakarta.apache.org>,
siegfried.goeschl@it20one.at
Organization: IT20one GmbH
To: Turbine Developers List <tu...@jakarta.apache.org>, Turbine
Users List <tu...@jakarta.apache.org>
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
>>>
>>
>>
>
Re: [Fwd: [Fulcrum] RFC - Contributing fulcrum-commonsemail-service
...]
Posted by Siegfried Goeschl <si...@it20one.at>.
Hi folks,
as it happens we are writing a small product using the
fulcrum-commons-email service - this gives me the chance to do field
testing before importing the project - I already found one minor bug
.... :-)
Cheers,
Siegfried Goeschl
Peter Courcoux wrote:
> +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 <si...@it20one.at>
>>> Reply-To: Turbine Developers List
>>> <tu...@jakarta.apache.org>, siegfried.goeschl@it20one.at
>>> Organization: IT20one GmbH
>>> To: Turbine Developers List <tu...@jakarta.apache.org>,
>>> Turbine Users List <tu...@jakarta.apache.org>
>>>
>>>
>>>
>>> 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
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [Fwd: [Fulcrum] RFC - Contributing fulcrum-commonsemail-service
...]
Posted by Peter Courcoux <pe...@courcoux.biz>.
+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 <si...@it20one.at>
>> Reply-To: Turbine Developers List
>> <tu...@jakarta.apache.org>, siegfried.goeschl@it20one.at
>> Organization: IT20one GmbH
>> To: Turbine Developers List <tu...@jakarta.apache.org>,
>> Turbine Users List <tu...@jakarta.apache.org>
>>
>>
>>
>> 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
>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
--
------------------------------
Peter Courcoux
Telephone : +44 (0)1923 661488
Mobile : 07880 605626
email : peter@courcoux.biz
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [Fwd: [Fulcrum] RFC - Contributing fulcrum-commonsemail-service
...]
Posted by Scott Eade <se...@backstagetech.com.au>.
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 <si...@it20one.at>
> Reply-To: Turbine Developers List
> <tu...@jakarta.apache.org>, siegfried.goeschl@it20one.at
> Organization: IT20one GmbH
> To: Turbine Developers List <tu...@jakarta.apache.org>,
> Turbine Users List <tu...@jakarta.apache.org>
>
>
>
> 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
>>>>
>>>
>>>
>>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org