Okay not in the Email classes themselves. And what i proposed was a
tad quick n dirty. I don't think I'm getting into framework territory,
I think the likes of spring have most of that covered except they opt
just to have a helper class for bells and whistles emails.
But only having a send method in the email class could fall short of
making the mail api easier to use. As the requirement for bulk emails
is a common one, shouldn't there be a way to do this under commons
email?
I don't think it would need to deal with responses, logging is surely
down to what you're running the code in, such as a container.
Customization would be down to have admin email address the user would
want to have the report sent to.
The scope would merely be to have a means of batch of mails without
waiting for the confirmation, thus in the case of webapplications not
timeout.
I agree this could slide out of control and start a commons email
framework, but I don't think it would need to. But providing an
accessible means of using Transport.send(Message,Address[]) would seem
within the scope.
Mark
On Tue, 30 Nov 2004 08:35:13 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote:
> It could be fun to discuss, but I think it wouldn't take long before
> you are designing an application or at least a framework, and that
> would be outside the scope of a commons project. In most cases,
> batch email includes transaction logging and customization, and
> often-times response tracking which would require more than what you
> sketched out.
>
> So, on the fun-to-discuss side, I usually avoid extending Thread when
> I could implement Runnable instead -- why blow your one use of
> inheritance in such a dull way? Furthermore, I don't think you'd
> want to do any of this stuff in the hierarchy of classes descending
> from o.a.c.mail.Email because you'd need a fair amount of
> configuration information (who's going to receive these messages, for
> example) that are better kept separate from the classes which are
> used more simply.
>
> Joe
>
> At 8:35 PM +0800 11/30/04, Corey Scott wrote:
> >Definately something we should add to our discussion list once 1.0 is
> >out of the way.
> >
> >-Corey
> >
> >
> >On Tue, 30 Nov 2004 10:32:28 +0100, Mark Lowe <[EMAIL PROTECTED]> wrote:
> >> I'll put the exception tests in with the the others, when its all in.
> >> I left most the tests untouched anyhow just testing for EmailException
> >> rather than MessagingException. Once EmailException is in the head
> >> version I'll start thinking about AddressException.
> >>
> >> Has the issue of bulk mailing comeup before? I'm thinking of a class
> >> that extends thread and then sends a email report to a specified email
> >> address reporting which have been sent and those that haven't. Does
> >> this fall within the scope of commons email? Email could even extend
> >> thread and then just use the run method when needing to mail to lots
> >> of folk.. This would be handy for webapps where the time it takes to
> >> send mail exceeds the time for the request-reponse cycle.
> >>
> >> HtmlEmail email = ..
> >> ..
> >> email.batchMail();
> >>
> >> public void batchMail() {
> >> this.run();
> >> }
> >>
> >> public void run() {
> >> try {
> >> send();
> >> } catch (SomeExceptionn e) {
> >>
> >> }
> >> }
> >>
> >> Or would something else be a better idea? Perhaps a separate class
> >> EmailSender or something?
> >>
> >>
> >>
> >> Mark
> >>
> >> On Tue, 30 Nov 2004 11:38:30 +0800, Corey Scott
> >><[EMAIL PROTECTED]> wrote:
> >> > Sounds good to me, I have a stack of things waiting for the next
> >> version.
> >> > Also I think most of the bugs have been cleared off by your recent
> >> > commits so there shouldnt be any reason to stop us from a RC1
> >> >
> >> >
> >> >
> >> > -Corey
> >> >
> >> > On Mon, 29 Nov 2004 19:01:00 +0100, Eric Pugh <[EMAIL PROTECTED]> wrote:
> >> > > I've applied a stack of changes, including Mark's EmailException, to
> >> the
> >> > > codebase. I don't really care much about how the unit tests
> >>look, as long
> >> > > as the jcoverage keeps going up!
> >> > >
> >> > > At this point, I think all the API changes are done, and my
> >>gut feeling is
> >> > > that we should look to final testing, cut a Release Candidate
> >>and then roll
> >> > > 1.0. We should also start thinking about what the next
> >>version will entail.
> >> > >
> >> > >
> >> > >
> >> > > Eric
> >> > >
> >> > > > -----Original Message-----
> >> > > > From: Mark Lowe [mailto:[EMAIL PROTECTED]
> >> > > > Sent: Monday, November 29, 2004 5:25 PM
> >> > > > To: Corey Scott
> >> > > > Cc: Jakarta Commons Developers List; [EMAIL PROTECTED]
> >> > > > Subject: Re: [email] Exceptions
> >> > > >
> >> > > >
> >> > > > Okay I'll take a look tommorrow and sumbit my patch with the test
> >> > > > cases in with the Other test methods.
> >> > > >
> >> > > > Judging from you example, you agree that unexpected exceptions
> >> should
> >> > > > just get thrown and that exceptions should be tested independently
> >> to
> >> > > > normal tests, which all sounds good to me. Or am i wrong? If the
> >> > > > method isn't there to invoke an exception then if one happens then
> >> > > > surely just throw it, the fact that its unexpected will be evident
> >> by
> >> > > > virtue of the test failing due to errors.
> >> > > >
> >> > > > Mark
> >> > > >
> >> > > > On Tue, 30 Nov 2004 00:04:16 +0800, Corey Scott
> > > > > > <[EMAIL PROTECTED]> wrote:
> >> > > > > This is exactly what I was trying to say, just not so elegantly
> >> :-)
> >> > > > >
> >> > > > > Eg. Tests for the HtmlEmail class should be in teh
> >>HtmlEmailTest class
> >> > > > > or is this becomes too big and you want to separate the
> >> exceptions,
> >> > > > > then there should be two classes HtmlEmailTest (for normal
> >>test cases)
> >> > > > > and HtmlEmailExceptionTest
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > > -Corey
> >> > > > >
> >> > > > > On Mon, 29 Nov 2004 16:59:29 +0100, Eric Pugh
> >><[EMAIL PROTECTED]> wrote:
> >> > > > > > Humm... I typically make all my unit tests throw Exception.
> >> > > > It reduces
> >> > > > > > the length of each test, especially when all you are doing is
> >> > > > logging that
> >> > > > > > it failed with a fail(ex.getMessage).
> >> > > > > >
> > > > > > > > However, if you are actually TESTING that an exception
> >gets thrown:
> >> > > > > >
> >> > > > > > try {
> >> > > > > > email.doSomething();
> >> > > > > > fail("should have thrown ee");
> >> > > > > > }
> >> > > > > > catch (EmailException ee){
> >> > > > > > assertTrue(ee.getMessage().indexOf("myerror")>-1)
> >> > > > > > }
> >> > > > > >
> >> > > > > > then I argue they should go in with whatever class we are
> >> > > > testing, because
> >> > > > > > when someone adds a new method to the class, it will
> >> > > > encourage them to add
> >> > > > > > the corresponding test case for any exeption. Or, put the
> >> > > > exception test
> >> > > > > > into the test.
> >> > > > > >
> >> > > > > > public void testSomething() throws Exception{
> >> > > > > > email.doSomethign();
> >> > > > > > <snip/>
> >> > > > > > try {
> >> > > > > > email.doSomething();
> >> > > > > > fail("should have thrown ee");
> >> > > > > > }
> >> > > > > > catch (EmailException ee){
> >> > > > > > assertTrue(ee.getMessage().indexOf("myerror")>-1)
> >> > > > > >
> >> > > > > > }
> >> > > > > >
> >> > > > > > }
> >> > > > > >
> >> > > > > > That way everything stays together. If we aren't actually
> >> > > > asserting the
> >> > > > > > exception, then we shouldn't bother testing it..
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > > Eric
> >> > > > > >
> >> > > > > > > -----Original Message-----
> >> > > > > > > From: Mark Lowe [mailto:[EMAIL PROTECTED]
> >> > > > > > > Sent: Monday, November 29, 2004 3:19 PM
> >> > > > > > > To: Corey Scott
> >> > > > > > > Cc: Jakarta Commons Developers List
> >> > > > > > > Subject: Re: [email] Exceptions
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > My thoughts on the test cases are that they should
> >>throw exception,
> >> > > > > > > and then have the exception testing separate. This
> >>would make the
> >> > > > > > > cases shorter also, perhaps this is what you mean.
> >> > > > > > >
> >> > > > > > > public void testFoo() throws Exception
> >> > > > > > > {
> >> > > > > > > Foo foo = new Foo();
> >> > > > > > > foo.setBar("testvar");
> >> > > > > > > }
> >> > > > > > >
> >> > > > > > > For example, if for some reason the exception for
> >>setBar() was ever
> >> > > > > > > changed the case could remain the same as before, and the
> >> > > > only change
> >> > > > > > > would need to be in the exception test case.
> >> > > > > > >
> >> > > > > > > Mark
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > On Mon, 29 Nov 2004 21:59:44 +0800, Corey Scott
> >> > > > > > > <[EMAIL PROTECTED]> wrote:
> >> > > > > > > > I would prefer an Exception Test case per base class,
> >> > > > especially for
> >> > > > > > > > the larger files. I know most of the tests I wrote, but
> >> > > > I think that
> >> > > > > > > > if anything the files are too long and would be much more
> >> > > > usable if
> >> > > > > > > > they were shorter and more focused. Does anyone have any
> >> > > > objections
> >> > > > > > > > to gave more (but shorter) files?
> >> > > > > > > >
> >> > > > > > > > -Corey
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > > > > On Mon, 29 Nov 2004 14:17:30 +0100, Mark Lowe
> >> > > > <[EMAIL PROTECTED]> wrote:
> >> > > > > > > > > I've created the exceptions and I'm now working through
> >> the
> >> > > > > > > test cases.
> >> > > > > > > > >
> >> > > > > > > > > If I summit a patch with the exception testing in a
> >> > > > ExceptionTestCase
> >> > > > > > > > > what's the likelyhood of this being patched? This isn't
> > > > > > a question of
> >> > > > > > > > > style its a question of maintainabilty and now, I'm
> >> > > > faced with the
> >> > > > > > > > > task of weeding out all these try catch statements.
> >> > > > > > > > >
> >> > > > > > > > > Any objection to a patch with these exception
> >>tests moved into a
> >> > > > > > > > > specialised test case?
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > > Mark
> >> > > > > > > > >
> >> > > > > > > > > On Mon, 29 Nov 2004 11:23:50 +0100, Mark Lowe
> >> > > > > > > <[EMAIL PROTECTED]> wrote:
> >> > > > > > > > > > Okay 2 commons.mail exceptions sounds like an
> >> improvement.
> >> > > > > > > So the goal
> >> > > > > > > > > > is to minimise the catch statements the user needs to
> >> > > > use, sound
> >> > > > > > > > > > reasonable. Throwing everything would mean 2 catches,
> >> so I
> > > > > > > > > can see the
> >> > > > > > > > > > value in catching once.
> >> > > > > > > > > >
> >> > > > > > > > > > I'll look into a way of having a 1.4+ build option in
> >> the
> >> > > > > > > build files
> >> > > > > > > > > > for folk that don't give a gnat's winnit about 1.3 et
> >> al.
> >> > > > > > > > > >
> >> > > > > > > > > > Anyone know the default behaviour for the
> >> > > > > > > InternetAddress(email,name)
> >> > > > > > > > > > constructor? Does it adopt the charset from the
> >>parent email?
> >> > > > > > > > > >
> >> > > > > > > > > > Mark
> >> > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > > > On Mon, 29 Nov 2004 11:11:06 +0100, Eric Pugh
> >> > > > > > > <[EMAIL PROTECTED]> wrote:
> >> > > > > > > > > > > My take on this is that users of [email] are looking
> >> for
> >> > > > > > > a package that
> >> > > > > > > > > > > simplifies the JavaMail api. And one of the big
> >> > > > > > > simplifing aspects is that
> >> > > > > > > > > > > the Exceptions that they have to catch are minimized.
> >> > > > > > > Most users will
> >> > > > > > > > > > > probably not care *what* the exception was, only that
> >> > > > > > > there *was* an
> >> > > > > > > > > > > exception, and just pass it up the chain. For folks
> >> who
> >> > > > > > > actually have code
> >> > > > > > > > > > > to deal with the specific exception, then they
> >>are either
> >> > > > > > > going to use the
> >> > > > > > > > > > > JavaMail api directly without the extra layer
> >>of [email],
> >> > > > > > > or we should
> >> > > > > > > > > > > provide a way for them to retrieve the
> >>specific Exception.
> >> > > > > > > > > > >
> >> > > > > > > > > > > Hence that is why I propose that we have two types
> >> > > > of exceptions:
> >> > > > > > > > > > > EmailException and RuntimeEmailException. For common
> >> > > > > > > exceptions, we throw
> >> > > > > > > > > > > an EmailException which is an extension of
> >> > > > > > > NestableException and wraps
> >> > > > > > > > > > > whatever the underlying JavaMail exception was. This
> >> > > > > > > provides a nice facade
> >> > > > > > > > > > > for people who don't care what the exception was, but
> >> > > > > > > allows folks who do to
> >> > > > > > > > > > > get the underlying exception.
> >> > > > > > > > > > >
> >> > > > > > > > > > > The other RuntimeEmailException will extend
> >> > > > > > > NestableRuntimeException and can
> >> > > > > > > > > > > be used for any runtime exceptions in the same manner
> >> as
> >> > > > > > > EmailException.
> >> > > > > > > > > > >
> >> > > > > > > > > > > For the case of the UEE, that would be another
> >> exception
> >> > > > > > > in the API to
> >> > > > > > > > > > > throw, which goes against the charter that:
> >> > > > > > > > > > > "contains a set of Java classes providing a thin
> >> > > > > > > convenience layer over
> >> > > > > > > > > > > JavaMail". So, in that case, throw the approapriate
> >> > > > > > > EmailException and
> >> > > > > > > > > > > that will wrap the UEE.
> >> > > > > > > > > > >
> >> > > > > > > > > > > Mark, is it possible to use the 1.4 io stuff
> >> > > > > > > conditionally? I guess not,
> >> > > > > > > > > > > but we could think about maybe how we compile the jar?
> >> > > > > > > Our primary target
> >> > > > > > > > > > > is definitly 1.3 for now though.
> >> > > > > > > > > > >
> >> > > > > > > > > > > Eric
> >> > > > > > > > > > >
> >> > > > > > > > > > >
> >> > > > > > > > > > >
> >> > > > > > > > > > > > -----Original Message-----
> > > > > > > > > > > > > > From: Mark Lowe [mailto:[EMAIL PROTECTED]
> >> > > > > > > > > > > > Sent: Sunday, November 28, 2004 4:04 PM
> >> > > > > > > > > > > > To: Commons dev list; Corey Scott
> >> > > > > > > > > > > > Subject: [email] Exceptions
> >> > > > > > > > > > > >
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > The issue of exceptions has come up a few times, and
> >> > > > > > > heres a summary
> >> > > > > > > > > > > > of my understanding of whats been said and agreed
> >> and
> >> > > > > > > disagreed about.
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > The idea of throwing AddressException is favourable,
> >> > > > > > > but not at the
> >> > > > > > > > > > > > cost of needing to throw
> >>UnsupportingEncodingException.
> >> > > > > > > When setting
> >> > > > > > > > > > > > InternetAddress() this throws a UEE and
> >>AddressException.
> > > > > > > > > > > > > >
> >> > > > > > > > > > > > My position is that without 1.4's new io package
> >> > > > > > > there's no means of
> >> > > > > > > > > > > > checking supported charsets on a given JVM.
> >>If the user
> >> > > > > > > enters a shady
> >> > > > > > > > > > > > charset for a email address or name is there
> >> anything
> >> > > > > > > wrong with them
> >> > > > > > > > > > > > having a UEE thrown?
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > The lightest means of doing this in my opinion is
> >> just
> >> > > > > > > throw both, its
> >> > > > > > > > > > > > consistent with the mailapi. It would work on all
> >> > > > target JVMs.
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > Of course you could just throw MessagingException
> >> for
> >> > > > > > > everything , "oh
> >> > > > > > > > > > > > thats what it does". But is this a useful
> >>and therefore
> >> > > > > > > good thing?
> >> > > > > > > > > > > > Having a commons.mail.EmailException was suggested,
> >> > > > > > > but does that
> >> > > > > > > > > > > > have any advantage over throwing AddressException
> >> and
> >> > > > > > > UEE? I'm not
> >> > > > > > > > > > > > sure.
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > I don't mind summitting the patches, i need to do
> >> this
> >> > > > > > > for a project
> >> > > > > > > > > > > > I'm working on at present, so I need to do the work
> >> > > > > > > anyway. It makes
> >> > > > > > > > > > > > sense to submit this to the effort but I don't
> >> > > > mind either way.
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > Mark
> >> > > > > > > > > > > >
> >> > > > > > > > > > > >
> >> > > > > > >
> >> > > >
> >> ---------------------------------------------------------------------
> >> > > > > > > > > > > > To unsubscribe, e-mail:
> >> > > > > > > [EMAIL PROTECTED]
> >> > > > > > > > > > > > For additional commands, e-mail:
> >> > > > > > > [EMAIL PROTECTED]
> >> > > > > > > > > > >
> >> > > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > >
> >> ---------------------------------------------------------------------
> >> > > > > > > > > To unsubscribe, e-mail:
> >> > > > [EMAIL PROTECTED]
> >> > > > > > > > > For additional commands, e-mail:
> >> > > > [EMAIL PROTECTED]
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > >
> >> ---------------------------------------------------------------------
> >> > > > > >
> >> > > > > >
> >> > > > > > > To unsubscribe, e-mail:
> >>[EMAIL PROTECTED]
> >> > > > > > > For additional commands, e-mail:
> >>[EMAIL PROTECTED]
> >> > > > > >
> >> > > > > >
> >>---------------------------------------------------------------------
> >> > > > >
> >> > > > >
> >> > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> > > > > > For additional commands, e-mail:
> >>[EMAIL PROTECTED]
> >> > > > > >
> >> > > > > >
> >> > > > >
> >> > >
> >> > >
> >> > > ---------------------------------------------------------------------
> >> > >
> >> > >
> >> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> > > For additional commands, e-mail: [EMAIL PROTECTED]
> >> > >
> >> > >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> >> >
> >>
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
>
> --
> 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]
