yup the cdi-dev is basically open to everyone. And especially for outstanding experts like you! ;)
LieGrue, strub --- On Wed, 5/25/11, David Blevins <[email protected]> wrote: > From: David Blevins <[email protected]> > Subject: Re: Exception handling idea > To: [email protected] > Date: Wednesday, May 25, 2011, 7:13 AM > > On May 24, 2011, at 11:58 PM, Mark Struberg wrote: > > > +1 how to start? > > We should try to get a list of the @SpecAssertions from the > various 'broken' tests. A little 'find|grep|sort|uniq' > action, perhaps. Then see if we can't squeeze out some > exception classes from them. Then start plumbing them > into the code. > > It's getting late here so if someone wants to compile that > list and post it, cool :) Otherwise I'll get to it > tomorrow. > > > We have lots of internal tests, but I think the > passivation example is really overly strict in the spec (as > you said on the CDI list). I'm not really convinced by petes > mail. Need to re-read his mail ot fully understand what he > meant. > > I had a reply, but it hit moderation as I wasn't > subscribed. I though it was a tad negative so I just > deleted it and sent a subscription request. Do you > know if that list is open? > > -David > > > --- On Wed, 5/25/11, David Blevins <[email protected]> > wrote: > > > >> From: David Blevins <[email protected]> > >> Subject: Exception handling idea > >> To: [email protected] > >> Date: Wednesday, May 25, 2011, 6:43 AM > >> Grinding through some of the "broken" > >> packages of the CDI TCK and many of them are > passing... some > >> of them for the wrong reason. Any deployment > issue > >> counts as a win with those tests, so it's > incredibly > >> difficult to verify if the test is passing for the > right > >> reason. > >> > >> One thing that is obvious is that if we had some > more > >> specific types to line up with some of the more > tested > >> sections of the TCK, we could probably incorporate > that into > >> our test runners to check if the tests pass for > the right > >> reason. So say a PassivationCapableException > subclass > >> of WebBeansConfigurationException for the various > tests that > >> check for passivation capability (section 6.6.4). > >> > >> A slightly more interesting spin would be to > annotate those > >> exceptions with the related section of the spec. > >> Basically something like the > @SpecAssertion(section = > >> "6.6.4", id = "bde") that the TCK uses. > Seems like we > >> could use this to line the exception up with the > test > >> assertion and give it the thumbs up or thumbs down > in our > >> harness. Users could also use it to figure > out what > >> part of the spec they need to read up on. > >> > >> > >> -David > >> > >> > > > >
