2012/2/21 Blue Diamond <[email protected]>: > 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 <[email protected]>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 <[email protected]>: >> > 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 <[email protected]> >> 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 <[email protected]>: >> >> > 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 >> >> >>
