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.

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
> >>
>

Reply via email to