[jbossws-issues] [JBoss JIRA] Updated: (JBWS-3027) Throw RuntimeExceptions not Protocol exceptions in Addressing Handler

[Richard Opalka (JIRA)]

     [ https://jira.jboss.org/browse/JBWS-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka updated JBWS-3027:
---------------------------------

        Summary: Throw RuntimeExceptions not Protocol exceptions in Addressing Handler  (was: TODO - better description)
    Description: 
In order to make addressing work properly it's necessary to throw
RuntimeExceptions instead of ProtocolExceptions in addressing handler.
This is because if exception is thrown in inbound part of the addressing
handler then handleFault isn't called at all on this addressing handler.
JAX-WS specification defines different behaviour for protocol exceptions
and for runtime exceptions thrown in handlers. Here's the copy/paste from the specification:

Throw ProtocolException or a subclass This indicates that normal message processing should cease.
     Subsequent actions depend on whether the MEP in use requires a response to the message currently
     being processed or not:
     Response Normal message processing stops, fault message processing starts. The message direction
          is reversed, if the message is not already a fault message then it is replaced with a fault message4 ,
          and the runtime invokes handleFault on the next4 handler or dispatches the message (see
          section 9.1.2.2) if there are no further handlers.
     No response Normal message processing stops, close is called on each previously invoked handler
          in the chain, the exception is dispatched (see section 9.1.2.3).

Throw any other runtime exception This indicates that normal message processing should cease. Subse-
     quent actions depend on whether the MEP in use includes a response to the message currently being
     processed or not:
     Response Normal message processing stops, close is called on each previously invoked handler in
          the chain, the message direction is reversed, and the exception is dispatched (see section 9.1.2.3).
     No response Normal message processing stops, close is called on each previously invoked handler
          in the chain, the exception is dispatched (see section 9.1.2.3).




> Throw RuntimeExceptions not Protocol exceptions in Addressing Handler
> ---------------------------------------------------------------------
>
>                 Key: JBWS-3027
>                 URL: https://jira.jboss.org/browse/JBWS-3027
>             Project: JBoss Web Services
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: jbossws-native
>            Reporter: Richard Opalka
>            Assignee: Richard Opalka
>             Fix For: jbossws-native-3.3.0
>
>
> In order to make addressing work properly it's necessary to throw
> RuntimeExceptions instead of ProtocolExceptions in addressing handler.
> This is because if exception is thrown in inbound part of the addressing
> handler then handleFault isn't called at all on this addressing handler.
> JAX-WS specification defines different behaviour for protocol exceptions
> and for runtime exceptions thrown in handlers. Here's the copy/paste from the specification:
> Throw ProtocolException or a subclass This indicates that normal message processing should cease.
>      Subsequent actions depend on whether the MEP in use requires a response to the message currently
>      being processed or not:
>      Response Normal message processing stops, fault message processing starts. The message direction
>           is reversed, if the message is not already a fault message then it is replaced with a fault message4 ,
>           and the runtime invokes handleFault on the next4 handler or dispatches the message (see
>           section 9.1.2.2) if there are no further handlers.
>      No response Normal message processing stops, close is called on each previously invoked handler
>           in the chain, the exception is dispatched (see section 9.1.2.3).
> Throw any other runtime exception This indicates that normal message processing should cease. Subse-
>      quent actions depend on whether the MEP in use includes a response to the message currently being
>      processed or not:
>      Response Normal message processing stops, close is called on each previously invoked handler in
>           the chain, the message direction is reversed, and the exception is dispatched (see section 9.1.2.3).
>      No response Normal message processing stops, close is called on each previously invoked handler
>           in the chain, the exception is dispatched (see section 9.1.2.3).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira