cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aki Yoshida <elak...@googlemail.com>
Subject Re: Isn't WS-Addressing MessageID optional?
Date Wed, 22 Feb 2012 10:23:57 GMT
This check came in with CXF-3062 that enforced the requirement
specified in the ws-addressing spec for request-respone calls. So, to
be compliant with the addressing spec, this check must be actually
performed.

As a workaround for your situation, you might want to use CXF's
transform feature to add the bogus messageID at the inbound processing
phase. In this way, the invalid request message that the client sends
will be transformed into a valid one that can be processed at the
server.

For this, you will just need to add the following transform feature to
your server  bus:

<bean id="transformFeature" class="org.apache.cxf.feature.StaxTransformFeature">
  <property name="inAppendElements">
    <map>
      <!-- insert a unspecified wsa:MessageID -->
      <entry key="{http://schemas.xmlsoap.org/soap/envelope/}Header/"
value="{http://www.w3.org/2005/08/addressing}MessageID=http://www.w3.org/2005/08/addressing/unspecified"/>
    </map>
  </property>
</bean>

<cxf:bus>
        <cxf:features>
            ...
            <ref bean="transformFeature"/>
            ...
        </cxf:features>
</cxf:bus>

regards, aki

2012/2/22 Malisetti, Ramanjaneyulu <Ramanjaneyulu.Malisetti@ca.com>:
> The following code snippet in org.apache.cxf.ws.addressing.MAPAggregator is causing the
problem. From this code, MessageID is mandatory for request/response operations.
>
> Is there any side effect of removing this code i.e reverting to CXF 2.3.0 code base?
>
>            AttributedURIType messageID = maps.getMessageID();
>
>            if (!message.getExchange().isOneWay()
>                    && (messageID == null || messageID.getValue() ==
null)
>                    && valid) {
>                String reason =
>                    BUNDLE.getString("MISSING_ACTION_MESSAGE");
>
>                ContextUtils.storeMAPFaultName(Names.HEADER_REQUIRED_NAME,
>                                               message);
>                ContextUtils.storeMAPFaultReason(reason, message);
>
>                valid = false;
>            }
>
> Regards
> Raman
>
> -----Original Message-----
> From: Aki Yoshida [mailto:elakito@googlemail.com]
> Sent: Tuesday, February 21, 2012 6:55 PM
> To: users@cxf.apache.org
> Subject: Re: Isn't WS-Addressing MessageID optional?
>
> 2012/2/21 Blue Diamond <gvnanils@gmail.com>:
>> tatz strange! :)
>>
>> are your services configured thru cxf.xml?
>> Our services are implementations of Provider interface driven by wsdl files
>> having WS-Security policy in it.
>
> It shouldn't matter whether it's a provider based endpoint or one
> using a specific service endpoint class.
> If the endpoint uses the addressing feature and the call expects a
> reply, we need the mesage id because the relatesTo header of the
> response message must refer to this original message id.
>
> And this behavior is in alignment with what the ws-addressing spec
> says about the MessageID and replyTo fields.
>
> /wsa:MessageID
> This OPTIONAL element (of type xs:anyURI) conveys the [message id]
> property. This element MUST be present if wsa:ReplyTo or wsa:FaultTo
> is present.
>
> /wsa:RelatesTo
> This OPTIONAL (repeating) element information item contributes one
> abstract [relationship] property value, in the form of a (URI, QName)
> pair. The [children] property of this element (which is of type
> xs:anyURI) conveys the [message id] of the related message. This
> element MUST be present if the message is a reply.
>
> /wsa:ReplyTo
> This OPTIONAL element (of type wsa:EndpointReferenceType) provides the
> value for the [reply endpoint] property. This element MUST be present
> if a reply is expected. If this element is present, wsa:MessageID MUST
> be present.
>
> Your scenario expects a reply, therefore the replyTo field must be
> present. And if the replyTo field is present, the MessageID field must
> be present.
>
> The same statement is also given in
> http://msdn.microsoft.com/en-us/library/ms996530.aspx#wsaddressd_topic4
>
> So, if something was working before without the MessageID field, I
> would rather suspect that there was no ws-addressing feature enabled
> or it was not for a request-response call.
>
> regards, aki
>
>>
>> Thanks & Regards,
>> Anil
>>
>>
>>
>> On Mon, Feb 20, 2012 at 11:05 PM, Aki Yoshida <elakito@googlemail.com>wrote:
>>
>>> Hi Anil,
>>>
>>> The problem with the missing MessageID is that this value is needed
>>> later in the response message for its relatesTo value.
>>>
>>> So, I was wondering how it was working before. I tried it (i.e., only
>>> setting Action and To) with 2.3.0 and 2.3.4, with the same result,
>>> the error with "A required header representing  ..."
>>>
>>> regards, aki
>>>
>>> 2012/2/20 Blue Diamond <gvnanils@gmail.com>:
>>> > yes its a request-response (sync) call in which replyTo is not required
&
>>> > even if its present it shud be anonymous uri.
>>> >
>>> > Thanks & Regards,
>>> > Anil
>>> >
>>> > On Mon, Feb 20, 2012 at 7:48 PM, Aki Yoshida <elakito@googlemail.com>
>>> wrote:
>>> >
>>> >> Could it be that your scenario is a request-response call and actually
>>> >> the replyTo header is expected but absent?
>>> >>
>>> >>
>>> >> 2012/2/20 Blue Diamond <gvnanils@gmail.com>:
>>> >> > Hello,
>>> >> >
>>> >> > We are using CXF 2.5.2 and after upgradation from 2.3.x, we are
>>> facing a
>>> >> > problem because of the missing WS-Addressing MessageID in our SOAP
>>> >> > messages. Earlier it used to work because we designed it based
on the
>>> >> spec
>>> >> > that says that "MessageID" is optional unless ReplyTo or FaultTo
are
>>> >> > present in a message which is not true in our scenarios.
>>> >> >
>>> >> > Initially, we see a warning in our logs but that throws back a
SOAP
>>> >> fault.
>>> >> >
>>> >> > Feb 20, 2012 5:48:05 PM org.apache.cxf.phase.PhaseInterceptorChain
>>> >> > doDefaultLogging
>>> >> >
>>> >> > WARNING: Interceptor for {
>>> >> >
>>> >>
>>> http://ns.ca.com/catalyst/node}NodeX509#{http://cxf.apache.org/jaxws/provider}invokehas
>>> >> > thrown exception, unwinding now
>>> >> >
>>> >> > org.apache.cxf.binding.soap.SoapFault: A required header representing
>>> a
>>> >> > Message Addressing Property is not present
>>> >> >
>>> >> >      at org.apache.cxf.ws.addressing.MAPAggregator.mediate(*
>>> >> > MAPAggregator.java:572*)
>>> >> >
>>> >> >      at org.apache.cxf.ws.addressing.MAPAggregator.handleMessage(*
>>> >> > MAPAggregator.java:227*)
>>> >> >
>>> >> >      at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(*
>>> >> > PhaseInterceptorChain.java:263*)
>>> >> >
>>> >> >      at org.apache.cxf.transport.ChainInitiationObserver.onMessage(*
>>> >> > ChainInitiationObserver.java:121*)
>>> >> >
>>> >> >      at
>>> >> >
>>> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(*
>>> >> > JettyHTTPDestination.java:319*)
>>> >> >
>>> >> >      at
>>> >> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(
>>> >> > *JettyHTTPDestination.java:287*)
>>> >> >
>>> >> >     at org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(*
>>> >> > JettyHTTPHandler.java:72*)
>>> >> >
>>> >> >      at org.eclipse.jetty.server.handler.ContextHandler.doHandle(*
>>> >> > ContextHandler.java:939*)
>>> >> >
>>> >> >      at org.eclipse.jetty.server.handler.ContextHandler.doScope(*
>>> >> > ContextHandler.java:875*)
>>> >> >
>>> >> >      at org.eclipse.jetty.server.handler.ScopedHandler.handle(*
>>> >> > ScopedHandler.java:117*)
>>> >> >
>>> >> >      at
>>> >> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(*
>>> >> > ContextHandlerCollection.java:247*)
>>> >> >
>>> >> >      at org.eclipse.jetty.server.handler.HandlerWrapper.handle(*
>>> >> > HandlerWrapper.java:110*)
>>> >> >
>>> >> >      at org.eclipse.jetty.server.Server.handle(*Server.java:342*)
>>> >> >
>>> >> >      at org.eclipse.jetty.server.HttpConnection.handleRequest(*
>>> >> > HttpConnection.java:589*)
>>> >> >
>>> >> >      at
>>> org.eclipse.jetty.server.HttpConnection$RequestHandler.content(*
>>> >> > HttpConnection.java:1065*)
>>> >> >
>>> >> >      at
>>> >> org.eclipse.jetty.http.HttpParser.parseNext(*HttpParser.java:915*)
>>> >> >
>>> >> >      at org.eclipse.jetty.http.HttpParser.parseAvailable(*
>>> >> > HttpParser.java:214*)
>>> >> >
>>> >> >      at org.eclipse.jetty.server.HttpConnection.handle(*
>>> >> > HttpConnection.java:411*)
>>> >> >
>>> >> >     at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(*
>>> >> > SelectChannelEndPoint.java:531*)
>>> >> >
>>> >> >      at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(*
>>> >> > SelectChannelEndPoint.java:40*)
>>> >> >
>>> >> >      at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(*
>>> >> > QueuedThreadPool.java:529*)
>>> >> >
>>> >> >      at java.lang.Thread.run(*Thread.java:619*)
>>> >> >
>>> >> > Feb 20, 2012 5:48:05 PM
>>> >> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor
>>> >> > handleMessage
>>> >> >
>>> >> > WARNING: Request does not contain Security header, but it's a fault.
>>> >> >
>>> >> >
>>> >> > [WSCallbackHandler] : Unable to send event to a non-durable
>>> subscriber @
>>> >> >
>>> http://localhost:9900/node/callback/e1622d1c-ea8e-4ff6-8e09-10ae8d20418a.A
>>> >> > required header representing a Message Addressing Property is not
>>> present
>>> >> >
>>> >> > *javax.xml.ws.soap.SOAPFaultException*: A required header
>>> representing a
>>> >> > Message Addressing Property is not present
>>> >> >
>>> >> >      at org.apache.cxf.jaxws.DispatchImpl.mapException(*
>>> >> > DispatchImpl.java:283*)
>>> >> >
>>> >> >      at
>>> org.apache.cxf.jaxws.DispatchImpl.invoke(*DispatchImpl.java:365*)
>>> >> >
>>> >> >      at
>>> org.apache.cxf.jaxws.DispatchImpl.invoke(*DispatchImpl.java:239*)
>>> >> >
>>> >> >
>>> >> >
>>> >> > The problem got rectified as soon as I added a wsa:MessageID in
our
>>> SOAP
>>> >> > header. I am assuming this is a problem in CXF or the libraries
that
>>> >> > internally it is using because, as per WS-Addressing spec MessageID
is
>>> >> > optional as in the case of our SOAP messages.
>>> >> >
>>> >> >
>>> >> > We cannot add this now because it will create a backward compatibility
>>> >> > issue with our previous releases which ran with CXF 2.3.x without
>>> >> MessageID
>>> >> > in our headers.
>>> >> >
>>> >> >
>>> >> > Any comments/suggestions/help? This looks like a bug to me.
>>> >> >
>>> >> >
>>> >> > Thanks & Regards,
>>> >> >
>>> >> > Anil
>>> >>
>>>

Mime
View raw message