[jira] Resolved: (CXF-2167) WS-Addressing handler should not drop messages when the RelatesTo property is explicitly set by client code

["Daniel Kulp (JIRA)" <ji...@apache.org>]

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

Daniel Kulp resolved CXF-2167.
------------------------------

       Resolution: Fixed
    Fix Version/s: 2.2.1
                   2.1.5

> WS-Addressing handler should not drop messages when the RelatesTo property is explicitly set by client code
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: CXF-2167
>                 URL: https://issues.apache.org/jira/browse/CXF-2167
>             Project: CXF
>          Issue Type: Improvement
>    Affects Versions: 2.1.4
>         Environment: Found in JBossWS/CXF 2.1.4.
>            Reporter: Andrew Dinn
>             Fix For: 2.1.5, 2.2.1
>
>
> The WS Addressing (WSA) class MAPCodec checks the RelatesTo field of an incoming Message Addressing Properties to see if it equals a previously cached outgoing MessageId field. This allows it to re-establish the exchange associated with an outgoing message in a request-reply (RPC) style exchange. If a RelatesTo value is found which does nto correspond to a cached MessageId the message is dropped.
> The problem with this is that it breaks use of the RelatesTo field by application code. Specifically, an application may wish to correlate sequences of 1-way messages by installing the MessageId from one message into the RelatesTo field of its successor. Since these messages employ different channels MPACodec will not find a cached MessageId for a successor message and so stop delivery of the messages.
> A proposed fix is to change MAPCodec so that it only disables delivery if the RelatesTo field has a null value for its RelationshipType or if the RelationshipType is set to http://www.w3.org/2005/08/addressing/reply (this is the default value implied by a null setting). A patch for this fix which has been tested in JBossWS/CXF is given below
> [adinn@toby cxf-2.1.4]$ svn diff rt/ws/addr/src/main/java/org/apache/cxf/ws/addressing/soap/MAPCodec.java
> Index: rt/ws/addr/src/main/java/org/apache/cxf/ws/addressing/soap/MAPCodec.java
> ===================================================================
> --- rt/ws/addr/src/main/java/org/apache/cxf/ws/addressing/soap/MAPCodec.java	(revision 761707)
> +++ rt/ws/addr/src/main/java/org/apache/cxf/ws/addressing/soap/MAPCodec.java	(working copy)
> @@ -53,6 +53,8 @@
>  import org.apache.cxf.message.Exchange;
>  import org.apache.cxf.message.Message;
>  import org.apache.cxf.phase.Phase;
> +import org.apache.cxf.ws.addressing.AddressingBuilder;
> +import org.apache.cxf.ws.addressing.AddressingConstants;
>  import org.apache.cxf.ws.addressing.AddressingProperties;
>  import org.apache.cxf.ws.addressing.AddressingPropertiesImpl;
>  import org.apache.cxf.ws.addressing.AttributedURIType;
> @@ -73,6 +75,8 @@
>  
>      private static final Logger LOG = LogUtils.getL7dLogger(MAPCodec.class);
>      private static final String IS_REFERENCE_PARAM_ATTR_NAME = "IsReferenceParameter";
> +    private static final AddressingConstants ADDRESSING_CONSTANTS
> +        = AddressingBuilder.getAddressingBuilder().newAddressingConstants();
>  
>      /**
>       * REVISIT: map usage that the *same* interceptor instance 
> @@ -83,7 +87,7 @@
>  
>      private VersionTransformer transformer;
>      private HeaderFactory headerFactory;
> -    
> +
>      /**
>       * Constructor.
>       */
> @@ -463,6 +467,12 @@
>                                                         AttributedURIType.class,
>                                                         headerElement, 
>                                                         unmarshaller));
> +                            } else if (Names.WSA_FROM_NAME.equals(localName)) {
> +                                maps.setFrom(decodeAsNative(
> +                                                       headerURI,
> +                                                       EndpointReferenceType.class,
> +                                                       headerElement,
> +                                                       unmarshaller));
>                              } else if (Names.WSA_TO_NAME.equals(localName)) {
>                                  AttributedURIType addr = decodeAsNative(
>                                                         headerURI,
> @@ -721,7 +731,7 @@
>       * @param maps the addressing properties
>       */
>      private void restoreExchange(SoapMessage message, AddressingProperties maps) {
> -        if (maps != null && maps.getRelatesTo() != null) {
> +        if (maps != null && maps.getRelatesTo() != null && isRelationshipReply(maps.getRelatesTo())) {
>              Exchange correlatedExchange =
>                  uncorrelatedExchanges.remove(maps.getRelatesTo().getValue());
>              if (correlatedExchange != null) {
> @@ -755,6 +765,11 @@
>          
>      }
>  
> +    private boolean isRelationshipReply(RelatesToType relatesTo) {
> +        return relatesTo.getRelationshipType() == null
> +                || relatesTo.getRelationshipType().equals(ADDRESSING_CONSTANTS.getRelationshipReply());
> +    }
> +
>      /**
>       * Marks a message as partial response
>       * 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.