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 Tue, 21 Feb 2012 13:24:35 GMT
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