batchee-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Kurz (JIRA)" <>
Subject [jira] [Commented] (BATCHEE-4) Spec change on skip/retry exception matching coming in 1.1
Date Wed, 27 Nov 2013 21:38:35 GMT


Scott Kurz commented on BATCHEE-4:


I hadn't stopped to confirm that testChunkRetryMultipleExceptions would indeed fail if the
implementation were to apply the logic suggested for 1.1.   I just singled it out noting the
mix of include/exclude elements in the XML.

But I'm guessing you may have actually tried this and found that, no, it didn't fail.

That is, if we were to have the runtime perform a retry after MyGrandchildException, in spite
of the fact that the RI did not in 1.0, would this TCK test actually fail? 

If it actually doesn't fail then I think I could explain why.  I think it would point to a
further bug in the test.    This should then be fixed, in 1.1., along with the test re-added
back into the 1.1 TCK.

Is that what you're seeing?

> Spec change on skip/retry exception matching coming in 1.1
> ----------------------------------------------------------
>                 Key: BATCHEE-4
>                 URL:
>             Project: BatchEE
>          Issue Type: Bug
>            Reporter: Scott Kurz
>            Priority: Minor
> Again, I'm just assuming this hasn't been fixed without testing based on RI knowledge.
> As discussed here:
> We decided that the spec was vague with respect to a case like:
> <retryable-exception-classes>
> 	<include class="...MyParentException"/>
> 	<include class="...MyGrandchildException"/>
> 	<exclude class="....MyChildException"/>
> </retryable-exception-classes>
> where MyGrandchildException extends MyChildException which extends MyParentException
> ====
> Informally, we agreed that the future direction would be this: 
> We decided to get rid of the RI behavior, which would exclude an instance of MyGrandchildException
(under the rule that matching any 'exclude' results in exclusion).  Instead we plan to go
with a rule that says you go with the matching include/exclude closest to you in the exception
hierarchy, in which case MyGrandchildException  would be included.

This message was sent by Atlassian JIRA

View raw message