[ 
https://issues.apache.org/jira/browse/TOMEE-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Gallimore resolved TOMEE-2149.
---------------------------------------
       Resolution: Fixed
    Fix Version/s: 1.7.6
                   7.0.5

> beforeDelivery/afterDelivery should allow zero messages to be delivered
> -----------------------------------------------------------------------
>
>                 Key: TOMEE-2149
>                 URL: https://issues.apache.org/jira/browse/TOMEE-2149
>             Project: TomEE
>          Issue Type: Bug
>    Affects Versions: 1.7.5, 7.0.4
>            Reporter: Jonathan Gallimore
>            Assignee: Jonathan Gallimore
>             Fix For: 7.0.5, 1.7.6
>
>
> At present we enforce that exactly one message is delivered between the 
> resource adapter calling beforeDelivery() and afterDelivery(). The spec 
> actually states that the application server should allow the resource adapter 
> to not deliver a message.
> From section 13.5.6 of JSR-322:
> "There must not be more than one message delivery in-between a single 
> beforeDelivery and afterDelivery method call pair. The application server 
> must reject beforeDelivery or afterDelivery calls that are out of sequence by 
> throwing an IllegalStateException.
> The application server must also allow a resource adapter not to perform any 
> message delivery in-between a single beforeDelivery and afterDelivery method 
> call pair. This scenario arises, for instance, when a resource adapter first 
> chooses to deliver a message and calls beforeDelivery, but later is unable to 
> deliver the message (for example in the case of JMS resource adapters, the 
> resource adapter may abort the message delivery and transfer the message to a 
> Dead Message Queue). The resource adapter must be able to call afterDelivery 
> and complete the delivery cycle. The application server must perform any 
> possible cleanup of actions that occurred in between the beforeDelivery and 
> afterDelivery method calls."



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to