Hi
On 22/02/12 10:34, Malisetti, Ramanjaneyulu wrote:
Our Header is encrypted as per WS-Security. Will this workaround work for us?
You should be able to register the 'in' part of Transform Feature only
and experiment with setting the phase on the interceptor, ex, make it
work only after the payload has been decrypted, Oliver has done
something similar with signed payloads,
<bean id="inTransformInterceptor"
class="org.apache.cxf.interceptor.transform.TransformInInterceptor">
<!--
pass the phase to TransformInInterceptor constructor, for the
interceptor to run after WSS4J code executes
-->
<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>
HTH, Sergey
Regards
Raman
-----Original Message-----
From: Aki Yoshida [mailto:[email protected]]
Sent: Wednesday, February 22, 2012 3:54 PM
To: [email protected]
Subject: Re: Isn't WS-Addressing MessageID optional?
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<[email protected]>:
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:[email protected]]
Sent: Tuesday, February 21, 2012 6:55 PM
To: [email protected]
Subject: Re: Isn't WS-Addressing MessageID optional?
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
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
