commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Germuska <...@Germuska.com>
Subject [email] batch sending (was Re: [email] Exceptions)
Date Tue, 30 Nov 2004 14:35:13 GMT
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 <melowe@gmail.com> 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 
>><corey.scott@gmail.com> 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 <epugh@upstate.com> 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:melowe@gmail.com]
>>  > > > Sent: Monday, November 29, 2004 5:25 PM
>>  > > > To: Corey Scott
>>  > > > Cc: Jakarta Commons Developers List; epugh@upstate.com
>>  > > > 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
>  > > > > <corey.scott@gmail.com> 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 
>><epugh@upstate.com> 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:melowe@gmail.com]
>>  > > > > > > 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
>>  > > > > > > <corey.scott@gmail.com> 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
>>  > > > <melowe@gmail.com> 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
>>  > > > > > > <melowe@gmail.com> 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
>>  > > > > > > <epugh@upstate.com> 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:melowe@gmail.com]
>>  > > > > > > > > > > > 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:
>>  > > > > > > commons-dev-unsubscribe@jakarta.apache.org
>>  > > > > > > > > > > > For additional commands,
e-mail:
>>  > > > > > > commons-dev-help@jakarta.apache.org
>>  > > > > > > > > > >
>>  > > > > > > > > > >
>>  > > > > > > > > >
>>  > > > > > > > >
>>  > > > > > > > >
>>  > > > ---------------------------------------------------------------------
>>  > > > > > > > > To unsubscribe, e-mail:
>>  > > > commons-dev-unsubscribe@jakarta.apache.org
>>  > > > > > > > > For additional commands, e-mail:
>>  > > > commons-dev-help@jakarta.apache.org
>>  > > > > > > > >
>>  > > > > > > > >
>>  > > > > > > >
>>  > > > > > >
>>  > > > > > >
>>  > > > ---------------------------------------------------------------------
>>  > > > > >
>>  > > > > >
>>  > > > > > > To unsubscribe, e-mail: 
>>commons-dev-unsubscribe@jakarta.apache.org
>>  > > > > > > For additional commands, e-mail: 
>>commons-dev-help@jakarta.apache.org
>>  > > > > >
>>  > > > > > 
>>---------------------------------------------------------------------
>>  > > > >
>>  > > > >
>>  > > > > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>  > > > > > For additional commands, e-mail: 
>>commons-dev-help@jakarta.apache.org
>>  > > > > >
>>  > > > > >
>>  > > > >
>>  > >
>>  > >
>>  > > ---------------------------------------------------------------------
>>  > >
>>  > >
>>  > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>  > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>  > >
>>  > >
>>  >
>>  > ---------------------------------------------------------------------
>>  > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>  > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>  > >
>>  >
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org


-- 
Joe Germuska            
Joe@Germuska.com  
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction"  -The Ex
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message