ByteArrayDataSource needs a test or two.. Aside from that, maybe check over the docs and the javadocs. I am thinking we do an RC on thursday, give it a week, and roll next week? Eric
> -----Original Message----- > From: Mark Lowe [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 30, 2004 1:38 PM > To: Corey Scott > Cc: Jakarta Commons Developers List; [EMAIL PROTECTED] > Subject: Re: [email] Exceptions > > > What needs to be done for 1.0 then? Give me a list and i'll put some > time aside to pitch in. > > > > On Tue, 30 Nov 2004 20:35:48 +0800, Corey Scott > <[EMAIL PROTECTED]> 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]