You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Hervé BARRAULT <he...@gmail.com> on 2012/04/17 15:55:55 UTC
WS-Addressing and One Way
Hi,
I'm trying to use CXF with both WS-Addressing and One Way.
My client send a message (not with CXF) with the following SOAP Header:
<soapenv:Header>
<wsa:Action soapenv:mustUnderstand="1">
http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Notify
</wsa:Action>
</soapenv:Header>
In my logs, I had :
14:10:31,210 | WARN | ault-workqueue-2 |
PhaseInterceptorChain |
org.apache.cxf.common.logging.LogUtils 369 | -
- | Interceptor for {
http://example.com/test1}StatusBrokerService#{http://docs.oasis-open.org/wsn/brw-2}Notifyhas
thrown exception, unwinding now
org.apache.cxf.binding.soap.SoapFault: MustUnderstand headers: [{
http://www.w3.org/2005/08/addressing}Action] are not understood.
at
org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$UltimateReceiverMustUnderstandInterceptor.handleMessage(MustUnderstandInterceptor.java:225)
at
org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$UltimateReceiverMustUnderstandInterceptor.handleMessage(MustUnderstandInterceptor.java:199)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
at
org.apache.cxf.phase.PhaseInterceptorChain.resume(PhaseInterceptorChain.java:218)
at
org.apache.cxf.interceptor.OneWayProcessorInterceptor$1.run(OneWayProcessorInterceptor.java:105)
at
org.apache.cxf.workqueue.AutomaticWorkQueueImpl$2.run(AutomaticWorkQueueImpl.java:332)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
And there was a classical 202/Accepted for a One Way message (fault not
returned as it is one way).
So, I found an interesting topics which says, enable the ws-addressing
feature (to avoid this fault) :
I added the feature
<cxf:features>
<wsa:addressing/>
</cxf:features>
Now when i receive a message, an answer is automatically sent (which i
guess is no more compliant with the One Way):
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<MessageID xmlns="http://www.w3.org/2005/08/addressing
">urn:uuid:67074ee9-455b-4488-b48d-e2a9b16a7c1b</MessageID>
<To xmlns="http://www.w3.org/2005/08/addressing">
http://www.w3.org/2005/08/addressing/anonymous</To>
<ReplyTo xmlns="http://www.w3.org/2005/08/addressing">
<Address>http://www.w3.org/2005/08/addressing/none</Address>
</ReplyTo>
</soap:Header>
<soap:Body/>
</soap:Envelope>
I know, i use an old version of CXF : 2.2.12-fuse-00-00 but i have not seen
a related JIRA (and a post said that 2.4.0 had the same behavior). (I am
using also the PAYLOAD mode)
I am doing it the right way ?
Is this behavior normal ?
Thanks for answers
Regards
Hervé
Re: WS-Addressing and One Way
Posted by Hervé BARRAULT <he...@gmail.com>.
Hi, FYI i also tried with 2.4.3-fuse-01-02, this version is returning also :
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<MessageID xmlns="http://www.w3.org/2005/08/addressing
">urn:uuid:70b74d26-4ab2-4b0a-8055-b3d961f95e9f</MessageID>
<To xmlns="http://www.w3.org/2005/08/addressing">
http://www.w3.org/2005/08/addressing/anonymous</To>
<ReplyTo xmlns="http://www.w3.org/2005/08/addressing">
<Address>http://www.w3.org/2005/08/addressing/none</Address>
</ReplyTo>
<RelatesTo xmlns="http://www.w3.org/2005/08/addressing">
http://www.w3.org/2005/08/addressing/unspecified</RelatesTo>
</soap:Header>
<soap:Body/>
</soap:Envelope>
On Wed, Apr 18, 2012 at 9:53 AM, Hervé BARRAULT <he...@gmail.com>wrote:
> Hi, i tried with CXF 2.5.2 and there is an empty 202 response.
>
> Regards
>
>
>
> On Tue, Apr 17, 2012 at 7:28 PM, Hervé BARRAULT <he...@gmail.com>wrote:
>
>> I forgot to precise that i am using directly the API (not spring).
>>
>>
>> On Tue, Apr 17, 2012 at 7:26 PM, Hervé BARRAULT <herve.barrault@gmail.com
>> > wrote:
>>
>>> Hi,
>>> thanks for the anwser.
>>>
>>> I will try with CXF 2.5.x (i was previously using camel/cxf but for this
>>> test i will try with only CXF)
>>>
>>> As i am offline i have some problems to enable ws-addressing using the
>>> example here: http://cxf.apache.org/docs/ws-addressing.html
>>> Caused by: javax.wsdl.WSDLException: WSDLException (at
>>> /wsdl:definitions/wsdl:import[1]/wsdl:definitions/wsdl:import[1]/wsdl:definitions/wsdl:types/xsd:schema/xsd:schema/xsd:schema):
>>> faultCode=PARSER_ERROR: Problem parsing '
>>> http://www.w3.org/2005/08/addressing/ws-addr.xsd'.:
>>> java.net.UnknownHostException: www.w3.org
>>>
>>> I added a jaxws-catalog to solve ws-addressing (in previous case) but it
>>> seems not working in this case.
>>>
>>> Regards
>>> Hervé
>>>
>>>
>>>
>>>
>>> On Tue, Apr 17, 2012 at 5:18 PM, Aki Yoshida <el...@googlemail.com>wrote:
>>>
>>>> Hi,
>>>> Can you try CXF 2.5.x? A bunch of issues around oneway-processing with
>>>> and without ws-addressing have been fixed in 2.4.x and 2.5.x.
>>>>
>>>> If you have a oneway service and the ws-addr feature is configured,
>>>> the service should be returning the http 202 empty response.
>>>>
>>>> regards, aki
>>>>
>>>> 2012/4/17 Hervé BARRAULT <he...@gmail.com>:
>>>> > Hi,
>>>> > I'm trying to use CXF with both WS-Addressing and One Way.
>>>> >
>>>> > My client send a message (not with CXF) with the following SOAP
>>>> Header:
>>>> > <soapenv:Header>
>>>> > <wsa:Action soapenv:mustUnderstand="1">
>>>> > http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Notify
>>>> > </wsa:Action>
>>>> > </soapenv:Header>
>>>> >
>>>> > In my logs, I had :
>>>> > 14:10:31,210 | WARN | ault-workqueue-2 |
>>>> > PhaseInterceptorChain |
>>>> > org.apache.cxf.common.logging.LogUtils 369
>>>> | -
>>>> > - | Interceptor for {
>>>> >
>>>> http://example.com/test1}StatusBrokerService#{http://docs.oasis-open.org/wsn/brw-2}Notifyhas
>>>> > thrown exception, unwinding now
>>>> > org.apache.cxf.binding.soap.SoapFault: MustUnderstand headers: [{
>>>> > http://www.w3.org/2005/08/addressing}Action] are not understood.
>>>> > at
>>>> >
>>>> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$UltimateReceiverMustUnderstandInterceptor.handleMessage(MustUnderstandInterceptor.java:225)
>>>> > at
>>>> >
>>>> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$UltimateReceiverMustUnderstandInterceptor.handleMessage(MustUnderstandInterceptor.java:199)
>>>> > at
>>>> >
>>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
>>>> > at
>>>> >
>>>> org.apache.cxf.phase.PhaseInterceptorChain.resume(PhaseInterceptorChain.java:218)
>>>> > at
>>>> >
>>>> org.apache.cxf.interceptor.OneWayProcessorInterceptor$1.run(OneWayProcessorInterceptor.java:105)
>>>> > at
>>>> >
>>>> org.apache.cxf.workqueue.AutomaticWorkQueueImpl$2.run(AutomaticWorkQueueImpl.java:332)
>>>> > at
>>>> >
>>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>>>> > at
>>>> >
>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>>>> > at java.lang.Thread.run(Thread.java:662)
>>>> >
>>>> > And there was a classical 202/Accepted for a One Way message (fault
>>>> not
>>>> > returned as it is one way).
>>>> >
>>>> >
>>>> >
>>>> > So, I found an interesting topics which says, enable the ws-addressing
>>>> > feature (to avoid this fault) :
>>>> > I added the feature
>>>> > <cxf:features>
>>>> > <wsa:addressing/>
>>>> > </cxf:features>
>>>> >
>>>> > Now when i receive a message, an answer is automatically sent (which i
>>>> > guess is no more compliant with the One Way):
>>>> > <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/
>>>> ">
>>>> > <soap:Header>
>>>> > <MessageID xmlns="http://www.w3.org/2005/08/addressing
>>>> > ">urn:uuid:67074ee9-455b-4488-b48d-e2a9b16a7c1b</MessageID>
>>>> > <To xmlns="http://www.w3.org/2005/08/addressing">
>>>> > http://www.w3.org/2005/08/addressing/anonymous</To>
>>>> > <ReplyTo xmlns="http://www.w3.org/2005/08/addressing">
>>>> > <Address>http://www.w3.org/2005/08/addressing/none</Address>
>>>> > </ReplyTo>
>>>> > </soap:Header>
>>>> > <soap:Body/>
>>>> > </soap:Envelope>
>>>> >
>>>> > I know, i use an old version of CXF : 2.2.12-fuse-00-00 but i have
>>>> not seen
>>>> > a related JIRA (and a post said that 2.4.0 had the same behavior). (I
>>>> am
>>>> > using also the PAYLOAD mode)
>>>> >
>>>> > I am doing it the right way ?
>>>> > Is this behavior normal ?
>>>> >
>>>> > Thanks for answers
>>>> > Regards
>>>> > Hervé
>>>>
>>>
>>>
>>
>
Re: WS-Addressing and One Way
Posted by Hervé BARRAULT <he...@gmail.com>.
Hi, i tried with CXF 2.5.2 and there is an empty 202 response.
Regards
On Tue, Apr 17, 2012 at 7:28 PM, Hervé BARRAULT <he...@gmail.com>wrote:
> I forgot to precise that i am using directly the API (not spring).
>
>
> On Tue, Apr 17, 2012 at 7:26 PM, Hervé BARRAULT <he...@gmail.com>wrote:
>
>> Hi,
>> thanks for the anwser.
>>
>> I will try with CXF 2.5.x (i was previously using camel/cxf but for this
>> test i will try with only CXF)
>>
>> As i am offline i have some problems to enable ws-addressing using the
>> example here: http://cxf.apache.org/docs/ws-addressing.html
>> Caused by: javax.wsdl.WSDLException: WSDLException (at
>> /wsdl:definitions/wsdl:import[1]/wsdl:definitions/wsdl:import[1]/wsdl:definitions/wsdl:types/xsd:schema/xsd:schema/xsd:schema):
>> faultCode=PARSER_ERROR: Problem parsing '
>> http://www.w3.org/2005/08/addressing/ws-addr.xsd'.:
>> java.net.UnknownHostException: www.w3.org
>>
>> I added a jaxws-catalog to solve ws-addressing (in previous case) but it
>> seems not working in this case.
>>
>> Regards
>> Hervé
>>
>>
>>
>>
>> On Tue, Apr 17, 2012 at 5:18 PM, Aki Yoshida <el...@googlemail.com>wrote:
>>
>>> Hi,
>>> Can you try CXF 2.5.x? A bunch of issues around oneway-processing with
>>> and without ws-addressing have been fixed in 2.4.x and 2.5.x.
>>>
>>> If you have a oneway service and the ws-addr feature is configured,
>>> the service should be returning the http 202 empty response.
>>>
>>> regards, aki
>>>
>>> 2012/4/17 Hervé BARRAULT <he...@gmail.com>:
>>> > Hi,
>>> > I'm trying to use CXF with both WS-Addressing and One Way.
>>> >
>>> > My client send a message (not with CXF) with the following SOAP Header:
>>> > <soapenv:Header>
>>> > <wsa:Action soapenv:mustUnderstand="1">
>>> > http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Notify
>>> > </wsa:Action>
>>> > </soapenv:Header>
>>> >
>>> > In my logs, I had :
>>> > 14:10:31,210 | WARN | ault-workqueue-2 |
>>> > PhaseInterceptorChain |
>>> > org.apache.cxf.common.logging.LogUtils 369
>>> | -
>>> > - | Interceptor for {
>>> >
>>> http://example.com/test1}StatusBrokerService#{http://docs.oasis-open.org/wsn/brw-2}Notifyhas
>>> > thrown exception, unwinding now
>>> > org.apache.cxf.binding.soap.SoapFault: MustUnderstand headers: [{
>>> > http://www.w3.org/2005/08/addressing}Action] are not understood.
>>> > at
>>> >
>>> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$UltimateReceiverMustUnderstandInterceptor.handleMessage(MustUnderstandInterceptor.java:225)
>>> > at
>>> >
>>> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$UltimateReceiverMustUnderstandInterceptor.handleMessage(MustUnderstandInterceptor.java:199)
>>> > at
>>> >
>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
>>> > at
>>> >
>>> org.apache.cxf.phase.PhaseInterceptorChain.resume(PhaseInterceptorChain.java:218)
>>> > at
>>> >
>>> org.apache.cxf.interceptor.OneWayProcessorInterceptor$1.run(OneWayProcessorInterceptor.java:105)
>>> > at
>>> >
>>> org.apache.cxf.workqueue.AutomaticWorkQueueImpl$2.run(AutomaticWorkQueueImpl.java:332)
>>> > at
>>> >
>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>>> > at
>>> >
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>>> > at java.lang.Thread.run(Thread.java:662)
>>> >
>>> > And there was a classical 202/Accepted for a One Way message (fault not
>>> > returned as it is one way).
>>> >
>>> >
>>> >
>>> > So, I found an interesting topics which says, enable the ws-addressing
>>> > feature (to avoid this fault) :
>>> > I added the feature
>>> > <cxf:features>
>>> > <wsa:addressing/>
>>> > </cxf:features>
>>> >
>>> > Now when i receive a message, an answer is automatically sent (which i
>>> > guess is no more compliant with the One Way):
>>> > <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
>>> > <soap:Header>
>>> > <MessageID xmlns="http://www.w3.org/2005/08/addressing
>>> > ">urn:uuid:67074ee9-455b-4488-b48d-e2a9b16a7c1b</MessageID>
>>> > <To xmlns="http://www.w3.org/2005/08/addressing">
>>> > http://www.w3.org/2005/08/addressing/anonymous</To>
>>> > <ReplyTo xmlns="http://www.w3.org/2005/08/addressing">
>>> > <Address>http://www.w3.org/2005/08/addressing/none</Address>
>>> > </ReplyTo>
>>> > </soap:Header>
>>> > <soap:Body/>
>>> > </soap:Envelope>
>>> >
>>> > I know, i use an old version of CXF : 2.2.12-fuse-00-00 but i have not
>>> seen
>>> > a related JIRA (and a post said that 2.4.0 had the same behavior). (I
>>> am
>>> > using also the PAYLOAD mode)
>>> >
>>> > I am doing it the right way ?
>>> > Is this behavior normal ?
>>> >
>>> > Thanks for answers
>>> > Regards
>>> > Hervé
>>>
>>
>>
>
Re: WS-Addressing and One Way
Posted by Hervé BARRAULT <he...@gmail.com>.
I forgot to precise that i am using directly the API (not spring).
On Tue, Apr 17, 2012 at 7:26 PM, Hervé BARRAULT <he...@gmail.com>wrote:
> Hi,
> thanks for the anwser.
>
> I will try with CXF 2.5.x (i was previously using camel/cxf but for this
> test i will try with only CXF)
>
> As i am offline i have some problems to enable ws-addressing using the
> example here: http://cxf.apache.org/docs/ws-addressing.html
> Caused by: javax.wsdl.WSDLException: WSDLException (at
> /wsdl:definitions/wsdl:import[1]/wsdl:definitions/wsdl:import[1]/wsdl:definitions/wsdl:types/xsd:schema/xsd:schema/xsd:schema):
> faultCode=PARSER_ERROR: Problem parsing '
> http://www.w3.org/2005/08/addressing/ws-addr.xsd'.:
> java.net.UnknownHostException: www.w3.org
>
> I added a jaxws-catalog to solve ws-addressing (in previous case) but it
> seems not working in this case.
>
> Regards
> Hervé
>
>
>
>
> On Tue, Apr 17, 2012 at 5:18 PM, Aki Yoshida <el...@googlemail.com>wrote:
>
>> Hi,
>> Can you try CXF 2.5.x? A bunch of issues around oneway-processing with
>> and without ws-addressing have been fixed in 2.4.x and 2.5.x.
>>
>> If you have a oneway service and the ws-addr feature is configured,
>> the service should be returning the http 202 empty response.
>>
>> regards, aki
>>
>> 2012/4/17 Hervé BARRAULT <he...@gmail.com>:
>> > Hi,
>> > I'm trying to use CXF with both WS-Addressing and One Way.
>> >
>> > My client send a message (not with CXF) with the following SOAP Header:
>> > <soapenv:Header>
>> > <wsa:Action soapenv:mustUnderstand="1">
>> > http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Notify
>> > </wsa:Action>
>> > </soapenv:Header>
>> >
>> > In my logs, I had :
>> > 14:10:31,210 | WARN | ault-workqueue-2 |
>> > PhaseInterceptorChain |
>> > org.apache.cxf.common.logging.LogUtils 369 |
>> -
>> > - | Interceptor for {
>> >
>> http://example.com/test1}StatusBrokerService#{http://docs.oasis-open.org/wsn/brw-2}Notifyhas
>> > thrown exception, unwinding now
>> > org.apache.cxf.binding.soap.SoapFault: MustUnderstand headers: [{
>> > http://www.w3.org/2005/08/addressing}Action] are not understood.
>> > at
>> >
>> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$UltimateReceiverMustUnderstandInterceptor.handleMessage(MustUnderstandInterceptor.java:225)
>> > at
>> >
>> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$UltimateReceiverMustUnderstandInterceptor.handleMessage(MustUnderstandInterceptor.java:199)
>> > at
>> >
>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
>> > at
>> >
>> org.apache.cxf.phase.PhaseInterceptorChain.resume(PhaseInterceptorChain.java:218)
>> > at
>> >
>> org.apache.cxf.interceptor.OneWayProcessorInterceptor$1.run(OneWayProcessorInterceptor.java:105)
>> > at
>> >
>> org.apache.cxf.workqueue.AutomaticWorkQueueImpl$2.run(AutomaticWorkQueueImpl.java:332)
>> > at
>> >
>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>> > at
>> >
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>> > at java.lang.Thread.run(Thread.java:662)
>> >
>> > And there was a classical 202/Accepted for a One Way message (fault not
>> > returned as it is one way).
>> >
>> >
>> >
>> > So, I found an interesting topics which says, enable the ws-addressing
>> > feature (to avoid this fault) :
>> > I added the feature
>> > <cxf:features>
>> > <wsa:addressing/>
>> > </cxf:features>
>> >
>> > Now when i receive a message, an answer is automatically sent (which i
>> > guess is no more compliant with the One Way):
>> > <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
>> > <soap:Header>
>> > <MessageID xmlns="http://www.w3.org/2005/08/addressing
>> > ">urn:uuid:67074ee9-455b-4488-b48d-e2a9b16a7c1b</MessageID>
>> > <To xmlns="http://www.w3.org/2005/08/addressing">
>> > http://www.w3.org/2005/08/addressing/anonymous</To>
>> > <ReplyTo xmlns="http://www.w3.org/2005/08/addressing">
>> > <Address>http://www.w3.org/2005/08/addressing/none</Address>
>> > </ReplyTo>
>> > </soap:Header>
>> > <soap:Body/>
>> > </soap:Envelope>
>> >
>> > I know, i use an old version of CXF : 2.2.12-fuse-00-00 but i have not
>> seen
>> > a related JIRA (and a post said that 2.4.0 had the same behavior). (I am
>> > using also the PAYLOAD mode)
>> >
>> > I am doing it the right way ?
>> > Is this behavior normal ?
>> >
>> > Thanks for answers
>> > Regards
>> > Hervé
>>
>
>
Re: WS-Addressing and One Way
Posted by Hervé BARRAULT <he...@gmail.com>.
Hi,
thanks for the anwser.
I will try with CXF 2.5.x (i was previously using camel/cxf but for this
test i will try with only CXF)
As i am offline i have some problems to enable ws-addressing using the
example here: http://cxf.apache.org/docs/ws-addressing.html
Caused by: javax.wsdl.WSDLException: WSDLException (at
/wsdl:definitions/wsdl:import[1]/wsdl:definitions/wsdl:import[1]/wsdl:definitions/wsdl:types/xsd:schema/xsd:schema/xsd:schema):
faultCode=PARSER_ERROR: Problem parsing '
http://www.w3.org/2005/08/addressing/ws-addr.xsd'.:
java.net.UnknownHostException: www.w3.org
I added a jaxws-catalog to solve ws-addressing (in previous case) but it
seems not working in this case.
Regards
Hervé
On Tue, Apr 17, 2012 at 5:18 PM, Aki Yoshida <el...@googlemail.com> wrote:
> Hi,
> Can you try CXF 2.5.x? A bunch of issues around oneway-processing with
> and without ws-addressing have been fixed in 2.4.x and 2.5.x.
>
> If you have a oneway service and the ws-addr feature is configured,
> the service should be returning the http 202 empty response.
>
> regards, aki
>
> 2012/4/17 Hervé BARRAULT <he...@gmail.com>:
> > Hi,
> > I'm trying to use CXF with both WS-Addressing and One Way.
> >
> > My client send a message (not with CXF) with the following SOAP Header:
> > <soapenv:Header>
> > <wsa:Action soapenv:mustUnderstand="1">
> > http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Notify
> > </wsa:Action>
> > </soapenv:Header>
> >
> > In my logs, I had :
> > 14:10:31,210 | WARN | ault-workqueue-2 |
> > PhaseInterceptorChain |
> > org.apache.cxf.common.logging.LogUtils 369 |
> -
> > - | Interceptor for {
> >
> http://example.com/test1}StatusBrokerService#{http://docs.oasis-open.org/wsn/brw-2}Notifyhas
> > thrown exception, unwinding now
> > org.apache.cxf.binding.soap.SoapFault: MustUnderstand headers: [{
> > http://www.w3.org/2005/08/addressing}Action] are not understood.
> > at
> >
> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$UltimateReceiverMustUnderstandInterceptor.handleMessage(MustUnderstandInterceptor.java:225)
> > at
> >
> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$UltimateReceiverMustUnderstandInterceptor.handleMessage(MustUnderstandInterceptor.java:199)
> > at
> >
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
> > at
> >
> org.apache.cxf.phase.PhaseInterceptorChain.resume(PhaseInterceptorChain.java:218)
> > at
> >
> org.apache.cxf.interceptor.OneWayProcessorInterceptor$1.run(OneWayProcessorInterceptor.java:105)
> > at
> >
> org.apache.cxf.workqueue.AutomaticWorkQueueImpl$2.run(AutomaticWorkQueueImpl.java:332)
> > at
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> > at
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> > at java.lang.Thread.run(Thread.java:662)
> >
> > And there was a classical 202/Accepted for a One Way message (fault not
> > returned as it is one way).
> >
> >
> >
> > So, I found an interesting topics which says, enable the ws-addressing
> > feature (to avoid this fault) :
> > I added the feature
> > <cxf:features>
> > <wsa:addressing/>
> > </cxf:features>
> >
> > Now when i receive a message, an answer is automatically sent (which i
> > guess is no more compliant with the One Way):
> > <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
> > <soap:Header>
> > <MessageID xmlns="http://www.w3.org/2005/08/addressing
> > ">urn:uuid:67074ee9-455b-4488-b48d-e2a9b16a7c1b</MessageID>
> > <To xmlns="http://www.w3.org/2005/08/addressing">
> > http://www.w3.org/2005/08/addressing/anonymous</To>
> > <ReplyTo xmlns="http://www.w3.org/2005/08/addressing">
> > <Address>http://www.w3.org/2005/08/addressing/none</Address>
> > </ReplyTo>
> > </soap:Header>
> > <soap:Body/>
> > </soap:Envelope>
> >
> > I know, i use an old version of CXF : 2.2.12-fuse-00-00 but i have not
> seen
> > a related JIRA (and a post said that 2.4.0 had the same behavior). (I am
> > using also the PAYLOAD mode)
> >
> > I am doing it the right way ?
> > Is this behavior normal ?
> >
> > Thanks for answers
> > Regards
> > Hervé
>
Re: WS-Addressing and One Way
Posted by Aki Yoshida <el...@googlemail.com>.
Hi,
Can you try CXF 2.5.x? A bunch of issues around oneway-processing with
and without ws-addressing have been fixed in 2.4.x and 2.5.x.
If you have a oneway service and the ws-addr feature is configured,
the service should be returning the http 202 empty response.
regards, aki
2012/4/17 Hervé BARRAULT <he...@gmail.com>:
> Hi,
> I'm trying to use CXF with both WS-Addressing and One Way.
>
> My client send a message (not with CXF) with the following SOAP Header:
> <soapenv:Header>
> <wsa:Action soapenv:mustUnderstand="1">
> http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Notify
> </wsa:Action>
> </soapenv:Header>
>
> In my logs, I had :
> 14:10:31,210 | WARN | ault-workqueue-2 |
> PhaseInterceptorChain |
> org.apache.cxf.common.logging.LogUtils 369 | -
> - | Interceptor for {
> http://example.com/test1}StatusBrokerService#{http://docs.oasis-open.org/wsn/brw-2}Notifyhas
> thrown exception, unwinding now
> org.apache.cxf.binding.soap.SoapFault: MustUnderstand headers: [{
> http://www.w3.org/2005/08/addressing}Action] are not understood.
> at
> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$UltimateReceiverMustUnderstandInterceptor.handleMessage(MustUnderstandInterceptor.java:225)
> at
> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$UltimateReceiverMustUnderstandInterceptor.handleMessage(MustUnderstandInterceptor.java:199)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.resume(PhaseInterceptorChain.java:218)
> at
> org.apache.cxf.interceptor.OneWayProcessorInterceptor$1.run(OneWayProcessorInterceptor.java:105)
> at
> org.apache.cxf.workqueue.AutomaticWorkQueueImpl$2.run(AutomaticWorkQueueImpl.java:332)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
>
> And there was a classical 202/Accepted for a One Way message (fault not
> returned as it is one way).
>
>
>
> So, I found an interesting topics which says, enable the ws-addressing
> feature (to avoid this fault) :
> I added the feature
> <cxf:features>
> <wsa:addressing/>
> </cxf:features>
>
> Now when i receive a message, an answer is automatically sent (which i
> guess is no more compliant with the One Way):
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
> <soap:Header>
> <MessageID xmlns="http://www.w3.org/2005/08/addressing
> ">urn:uuid:67074ee9-455b-4488-b48d-e2a9b16a7c1b</MessageID>
> <To xmlns="http://www.w3.org/2005/08/addressing">
> http://www.w3.org/2005/08/addressing/anonymous</To>
> <ReplyTo xmlns="http://www.w3.org/2005/08/addressing">
> <Address>http://www.w3.org/2005/08/addressing/none</Address>
> </ReplyTo>
> </soap:Header>
> <soap:Body/>
> </soap:Envelope>
>
> I know, i use an old version of CXF : 2.2.12-fuse-00-00 but i have not seen
> a related JIRA (and a post said that 2.4.0 had the same behavior). (I am
> using also the PAYLOAD mode)
>
> I am doing it the right way ?
> Is this behavior normal ?
>
> Thanks for answers
> Regards
> Hervé
Re: WS-Addressing and One Way
Posted by Freeman Fang <fr...@gmail.com>.
Hi,
To configure transformation feature per each cxf endpoint, you can do something like
<jaxws:endpoint ...>
<jaxws:features>
<bean class="org.apache.cxf.feature.StaxTransformFeature"/>
</jaxws:features>
</jaxws:endpoint>
Also, if you want to use CXF 2.5.x in OSGi container, you can start from Karaf easily, add cxf features.xml to Karaf and install cxf feature there.
Another option is use FUSE ESB 7.x which support CXF 2.5.x OOTB.
Freeman
－－－－－－－－－－－－－
Freeman Fang
FuseSource
Email:ffang@fusesource.com
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
weibo: http://weibo.com/u/1473905042
On 2012-8-29, at 上午6:05, ychawla wrote:
> Hello All,
> I am currently using cxf 2.4.x and locked into ServiceMix 4.4.1. I am
> having issues with .NET integration because a one way operation is sending
> back a WS-Addressing message. I realize that an upgrade to CXF 2.5.x will
> solve this problem. However I don't have this option now.
>
> Can I somehow handle this in an interceptor? I would like to change the
> HTTP status to 202 and remove the soap message.
>
> I tried something like this, but I don't think I quite know how to modify
> the message:
>
>
> public class RemoveSoapMessageForOneWayResponse extends
> AbstractSoapInterceptor {
>
> public RemoveSoapMessageForOneWayResponse() {
> super(Phase.PRE_STREAM);
> addBefore(Arrays.asList(StaxOutInterceptor.class.getName(),
> AttachmentOutInterceptor.class.getName()));
> }
>
> @Override
> public void handleMessage(SoapMessage message) throws Fault {
>
> message.setContent(String.class, "");
> }
>
> protected <T> T createSoapMessage(Class<T> messageType) {
> // create your message
> return null;
> }
>
> }
>
> I was also thinking of using the transformation capabilities:
> http://cxf.apache.org/docs/transformationfeature.html
>
> However, I couldn't see how to limit this to a single CXF endpoint. My
> application currently has many CXF endpoints.
>
> Any ideas on what to try next?
>
> Thanks,
> Yogesh
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/WS-Addressing-and-One-Way-tp5646635p5713278.html
> Sent from the cxf-user mailing list archive at Nabble.com.
Re: WS-Addressing and One Way
Posted by siddharthrajjain <si...@yahoo.com>.
How do we support the scenario where client are expecting 200 in
response(basically the old behavior) and service has moved to 2.5 and above
version ?
--
View this message in context: http://cxf.547215.n5.nabble.com/WS-Addressing-and-One-Way-tp5646635p5738633.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: WS-Addressing and One Way
Posted by ychawla <pr...@yahoo.com>.
Hi Aki and Freeman,
Thanks for the help. The transform didn't work out for me. It would remove
elements but still leave empty elements like <>. I don't think it was
designed to strip out an entire response message. However, I am glad I got
to learn about the transformer. It is a really great addition to CXF.
I updated my customer interceptor to set a 202 and empty outputstream (this
is based on the TransformOutInterceptor). In case anyone is interested,
here it is:
public class RemoveSoapMessageForOneWayResponse extends
AbstractSoapInterceptor {
private static final String OUTPUT_STREAM_HOLDER =
TransformOutInterceptor.class.getName() + ".outputstream";
public RemoveSoapMessageForOneWayResponse() {
super(Phase.PRE_STREAM);
addBefore(Arrays.asList(StaxOutInterceptor.class.getName(),
AttachmentOutInterceptor.class.getName()));
}
@Override
public void handleMessage(SoapMessage message) throws Fault {
if (null != message.getContent(Exception.class)) {
return;
}
OutputStream os = (OutputStream)message.get(OUTPUT_STREAM_HOLDER);
os = convertStringtoStream("");
if (os != null) {
message.setContent(OutputStream.class, os);
}
message.put(Message.RESPONSE_CODE, 202);
}
private static OutputStream convertStringtoStream(String string) {
byte[] stringByte = string.getBytes();
ByteArrayOutputStream bos = new
ByteArrayOutputStream(string.length());
try {
bos.write(stringByte);
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
return bos;
}
--
View this message in context: http://cxf.547215.n5.nabble.com/WS-Addressing-and-One-Way-tp5646635p5713326.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: WS-Addressing and One Way
Posted by Aki Yoshida <el...@gmail.com>.
Hi,
I don't think the transform feature will help you here because it
can't be used to empty the content or set the status code.
What might work in CXF 2.4 is to set the http status code in the
message through your interceptor that is invoked for the partial
response (the empty response to your oneway request) that is sent back
to the servlet entry during the oneway processing.
you can set the status of this message
message.put(Message.RESPONSE_CODE, 202);
regards, aki
2012/8/29 ychawla <pr...@yahoo.com>:
> Hello All,
> I am currently using cxf 2.4.x and locked into ServiceMix 4.4.1. I am
> having issues with .NET integration because a one way operation is sending
> back a WS-Addressing message. I realize that an upgrade to CXF 2.5.x will
> solve this problem. However I don't have this option now.
>
> Can I somehow handle this in an interceptor? I would like to change the
> HTTP status to 202 and remove the soap message.
>
> I tried something like this, but I don't think I quite know how to modify
> the message:
>
>
> public class RemoveSoapMessageForOneWayResponse extends
> AbstractSoapInterceptor {
>
> public RemoveSoapMessageForOneWayResponse() {
> super(Phase.PRE_STREAM);
> addBefore(Arrays.asList(StaxOutInterceptor.class.getName(),
> AttachmentOutInterceptor.class.getName()));
> }
>
> @Override
> public void handleMessage(SoapMessage message) throws Fault {
>
> message.setContent(String.class, "");
> }
>
> protected <T> T createSoapMessage(Class<T> messageType) {
> // create your message
> return null;
> }
>
> }
>
> I was also thinking of using the transformation capabilities:
> http://cxf.apache.org/docs/transformationfeature.html
>
> However, I couldn't see how to limit this to a single CXF endpoint. My
> application currently has many CXF endpoints.
>
> Any ideas on what to try next?
>
> Thanks,
> Yogesh
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/WS-Addressing-and-One-Way-tp5646635p5713278.html
> Sent from the cxf-user mailing list archive at Nabble.com.
Re: WS-Addressing and One Way
Posted by ychawla <pr...@yahoo.com>.
Hello All,
I am currently using cxf 2.4.x and locked into ServiceMix 4.4.1. I am
having issues with .NET integration because a one way operation is sending
back a WS-Addressing message. I realize that an upgrade to CXF 2.5.x will
solve this problem. However I don't have this option now.
Can I somehow handle this in an interceptor? I would like to change the
HTTP status to 202 and remove the soap message.
I tried something like this, but I don't think I quite know how to modify
the message:
public class RemoveSoapMessageForOneWayResponse extends
AbstractSoapInterceptor {
public RemoveSoapMessageForOneWayResponse() {
super(Phase.PRE_STREAM);
addBefore(Arrays.asList(StaxOutInterceptor.class.getName(),
AttachmentOutInterceptor.class.getName()));
}
@Override
public void handleMessage(SoapMessage message) throws Fault {
message.setContent(String.class, "");
}
protected <T> T createSoapMessage(Class<T> messageType) {
// create your message
return null;
}
}
I was also thinking of using the transformation capabilities:
http://cxf.apache.org/docs/transformationfeature.html
However, I couldn't see how to limit this to a single CXF endpoint. My
application currently has many CXF endpoints.
Any ideas on what to try next?
Thanks,
Yogesh
--
View this message in context: http://cxf.547215.n5.nabble.com/WS-Addressing-and-One-Way-tp5646635p5713278.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: WS-Addressing and One Way
Posted by Daniel Kulp <dk...@apache.org>.
On Wednesday, April 25, 2012 04:38:12 PM Aki Yoshida wrote:
> Hi Dan,
>
> I think the robust property makes sense for the server side but not
> for the client side. The problem of the HTTP transport with oneway is
> that the client doesn't know if the message reaches the target service
> and that no component is taking the responsibility of making the
> service receiving the message behind that oneway asynchronous
> boundary.
>
> In the robust mode, the HTTP client will not get an HTTP 202 response
> if something goes wrong at the server side. So if it does not receive
> an HTTP 202 response, it can at least choose to resend the message
> until it receives an HTTP202 response (this resend could potentially
> lead to a duplicate invocation of the service but this can be filtered
> out if each message carries a unique identifier).
>
> In contrast, in the JMS case, the server (or the queue) is taking the
> responsibility of making the service receives the message once the
> message is placed in the queue. So, if the client can send out a
> message to the queue, it can assume that he doesn't need to worry
> about the message (or there is nothing he can do).
For kicks, I did check the SOAP/JMS spec... It's actually a bit more
"interesting" when it comes to One-Way operations. It specifically states
that " For JMS messages sent to a Queue destination this MEP results in a
SOAP message which will be received by zero or one receiver". Note the
"Zero" in there. This is slight different than with HTTP in that with
HTTP, you at least get the 202 to state the service did get a message.
Something to keep in mind when using JMS clients. :-)
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: WS-Addressing and One Way
Posted by Daniel Kulp <dk...@apache.org>.
On Tuesday, April 24, 2012 11:24:43 AM Hervé BARRAULT wrote:
> Hi,
>
> Sorry if my question was a bit confuse.
>
> When i had the log it was on the server side [i forgot to precise it] (I
> never received the error on the client) which is one of the wanted
> behavior.
>
> I only want the 202 HTTP code with NO content (which is for me the
> principle of inOnly but I am perhaps wrong).
> I don't know how other client implementations will react if my server
> reply some unexpected content (and it adds some useless data on network).
>
> So for me, the 2.5.2 implementation is the one I expect (not
> 2.4.3-fuse-01-02 and previous) .
>
> 2.5.2 : only 202 HTTP code with no content.<= IMHO : OK
Well, there is the solution: upgrade to 2.5.3 or 2.6.0.
For some information about this, see:
http://cxf.547215.n5.nabble.com/Adjusting-WS-RM-systests-for-http-202-tt4756114.html
and:
https://issues.apache.org/jira/browse/CXF-3768
We had a bunch of discussions around the behavior change and decided it really could only go to 2.5.x at the time due to it potentially breaking existing applications.
Dan
> 2.4.3-fuse-01-02 and previous versions : (soap Header with WS-Addressing
> data in any case) <= IMHO : NOT OK
>
> I am not familiar with WS-Addressing so I could be wrong and the message
> used for my testing was given to me.
>
> If you say me that I should not use soapenv:mustUnderstand="1" with inOnly
> (or even WS addressing), I will see if the client can avoid sending it.
> But it seems that the behavior is the same without the mustUnderstand.
>
> For Information, my WSDL contains both inOnly and Request/Response
> operation in the same port.
>
> I hope, it will be less confuse for you.
>
> The question of robust InOnly is also an interesting question (we are
> using a request/response for a wanted robust inOnly) but I think it can
> be a dedicated debate.
>
> Regards
> Hervé
>
> On Mon, Apr 23, 2012 at 11:01 PM, Daniel Kulp <dk...@apache.org> wrote:
> > On Monday, April 23, 2012 10:50:05 PM Aki Yoshida wrote:
> > > 2012/4/23 Daniel Kulp <dk...@apache.org>:
> > > > This is "proper" behavior as per spec. In a one way, the client
> > > > just
> > > > knows that the message was posted, that's it. As an example, if
> > > > using
> > > > JMS, the client just posts the message to the queue and returns.
> > > > There
> > > > is absolutely no way to get any information about whether the
> > > > request
> > > > was able to be parsed or processed back from the server.
> > > >
> > > > In 2.6.0, Aki did add a "robust in-only" mode (set the
> > > > "org.apache.cxf.oneway.robust" property on the endpoint to true)
> > > > which
> > > > would allow returning faults to the client. This is against spec
> > > > and
> > > > transports like JMS I don't think can handle it (not really sure,
> > > > Aki?), but but it may work for you.
> > >
> > > A good question. I don't know. Is the JMS endpoint using the fault
> > > observer? If it uses the fault observer, it could react to this
> > > situation.
> >
> > Well, I assume there is a fault observer on the server side, the issue
> > is
> > on
> > the client side. For a one way, the client would send the message to
> > the JMS queue and then continue on it's merry way. There wouldn't be
> > anything setup to listen for a fault. Honestly, I'm not really sure
> > what would be a
> > proper thing to do in this case. If the client treats the "robust
> > oneway" calls as a two way and sets up a listener, then the server
> > would have to send back a response of some sort. I guess a "jms fake
> > 202" could be sent or something. But it's really getting into
> > proprietary things at this point. I guess I should go back to the
> > SOAP/JMS spec and see if it addresses the WSDL 2 robust cases at all.
> >
> > > But I am now confused with what Hervé wants. Should the soap fault be
> > > returned or suppressed? I thought he wanted it to be suppressed. If he
> > > wanted it to be returned, yes, he could use the robust property.
> >
> > I thought it WAS suppressed (and only the 202 is heading back) but he
> > wanted
> > the mustunderstand fault to go back to the client. I could likely be
> > confused as well.
> >
> > Dan
> >
> > > regards, aki
> > >
> > > > Dan
> > > >
> > > > On Tuesday, April 17, 2012 03:55:55 PM Hervé BARRAULT wrote:
> > > >> Hi,
> > > >> I'm trying to use CXF with both WS-Addressing and One Way.
> > > >>
> > > >> My client send a message (not with CXF) with the following SOAP
> >
> > Header:
> > > >> <soapenv:Header>
> > > >>
> > > >> <wsa:Action soapenv:mustUnderstand="1">
> > > >>
> > > >> http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Noti
> > > >> fy
> > > >>
> > > >> </wsa:Action>
> > > >>
> > > >> </soapenv:Header>
> > > >>
> > > >> In my logs, I had :
> > > >> 14:10:31,210 | WARN | ault-workqueue-2 |
> > > >> PhaseInterceptorChain |
> > > >> org.apache.cxf.common.logging.LogUtils
> > > >> 369
> > > >>
> > > >> - - | Interceptor for {
> >
> > http://example.com/test1}StatusBrokerService#{http://docs.oasis-open.or
> >
> > > >> g/w sn/brw-2}Notifyhas thrown exception, unwinding now
> > > >> org.apache.cxf.binding.soap.SoapFault: MustUnderstand headers: [{
> > > >> http://www.w3.org/2005/08/addressing}Action] are not understood.
> > > >>
> > > >> at
> >
> > org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$Ultim
> >
> > > >> ate
> > > >> ReceiverMustUnderstandInterceptor.handleMessage(MustUnderstandInter
> > > >> cep
> > > >> tor. java:225) at
> >
> > org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$Ultim
> >
> > > >> ate
> > > >> ReceiverMustUnderstandInterceptor.handleMessage(MustUnderstandInter
> > > >> cep
> > > >> tor. java:199) at
> >
> > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptor
> >
> > > >> Cha in.java:243) at
> >
> > org.apache.cxf.phase.PhaseInterceptorChain.resume(PhaseInterceptorChain
> >
> > > >> .ja va:218) at
> >
> > org.apache.cxf.interceptor.OneWayProcessorInterceptor$1.run(OneWayProce
> >
> > > >> sso rInterceptor.java:105) at
> >
> > org.apache.cxf.workqueue.AutomaticWorkQueueImpl$2.run(AutomaticWorkQueu
> >
> > > >> eIm pl.java:332) at
> >
> > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecut
> >
> > > >> or. java:886) at
> >
> > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.j
> >
> > > >> ava>>
> > > >>
> > > >> :908) at java.lang.Thread.run(Thread.java:662)
> > > >>
> > > >> And there was a classical 202/Accepted for a One Way message (fault
> >
> > not
> >
> > > >> returned as it is one way).
> > > >>
> > > >>
> > > >>
> > > >> So, I found an interesting topics which says, enable the
> > > >> ws-addressing
> > > >> feature (to avoid this fault) :
> > > >> I added the feature
> > > >> <cxf:features>
> > > >>
> > > >> <wsa:addressing/>
> > > >>
> > > >> </cxf:features>
> > > >>
> > > >> Now when i receive a message, an answer is automatically sent
> > > >> (which i
> > > >> guess is no more compliant with the One Way):
> > > >> <soap:Envelope
> > > >> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/
> >
> > ">
> >
> > > >> <soap:Header>
> > > >>
> > > >> <MessageID xmlns="http://www.w3.org/2005/08/addressing
> > > >>
> > > >> ">urn:uuid:67074ee9-455b-4488-b48d-e2a9b16a7c1b</MessageID>
> > > >>
> > > >> <To xmlns="http://www.w3.org/2005/08/addressing">
> > > >>
> > > >> http://www.w3.org/2005/08/addressing/anonymous</To>
> > > >>
> > > >> <ReplyTo xmlns="http://www.w3.org/2005/08/addressing">
> > > >>
> > > >> <Address>http://www.w3.org/2005/08/addressing/none</Addres
> > > >> s>
> > > >>
> > > >> </ReplyTo>
> > > >>
> > > >> </soap:Header>
> > > >> <soap:Body/>
> > > >>
> > > >> </soap:Envelope>
> > > >>
> > > >> I know, i use an old version of CXF : 2.2.12-fuse-00-00 but i have
> > > >> not
> > > >> seen a related JIRA (and a post said that 2.4.0 had the same
> >
> > behavior).
> >
> > > >> (I am using also the PAYLOAD mode)
> > > >>
> > > >> I am doing it the right way ?
> > > >> Is this behavior normal ?
> > > >>
> > > >> Thanks for answers
> > > >> Regards
> > > >> Hervé
> > > >
> > > > --
> > > > Daniel Kulp
> > > > dkulp@apache.org - http://dankulp.com/blog
> > > > Talend Community Coder - http://coders.talend.com
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org - http://dankulp.com/blog
> > Talend Community Coder - http://coders.talend.com
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: WS-Addressing and One Way
Posted by Hervé BARRAULT <he...@gmail.com>.
Hi,
Sorry if my question was a bit confuse.
When i had the log it was on the server side [i forgot to precise it] (I
never received the error on the client) which is one of the wanted behavior.
I only want the 202 HTTP code with NO content (which is for me the
principle of inOnly but I am perhaps wrong).
I don't know how other client implementations will react if my server reply
some unexpected content (and it adds some useless data on network).
So for me, the 2.5.2 implementation is the one I expect (not
2.4.3-fuse-01-02 and previous) .
2.5.2 : only 202 HTTP code with no content.<= IMHO : OK
2.4.3-fuse-01-02 and previous versions : (soap Header with WS-Addressing
data in any case) <= IMHO : NOT OK
I am not familiar with WS-Addressing so I could be wrong and the message
used for my testing was given to me.
If you say me that I should not use soapenv:mustUnderstand="1" with inOnly
(or even WS addressing), I will see if the client can avoid sending it. But
it seems that the behavior is the same without the mustUnderstand.
For Information, my WSDL contains both inOnly and Request/Response
operation in the same port.
I hope, it will be less confuse for you.
The question of robust InOnly is also an interesting question (we are using
a request/response for a wanted robust inOnly) but I think it can be a
dedicated debate.
Regards
Hervé
On Mon, Apr 23, 2012 at 11:01 PM, Daniel Kulp <dk...@apache.org> wrote:
> On Monday, April 23, 2012 10:50:05 PM Aki Yoshida wrote:
> > 2012/4/23 Daniel Kulp <dk...@apache.org>:
> > > This is "proper" behavior as per spec. In a one way, the client just
> > > knows that the message was posted, that's it. As an example, if using
> > > JMS, the client just posts the message to the queue and returns. There
> > > is absolutely no way to get any information about whether the request
> > > was able to be parsed or processed back from the server.
> > >
> > > In 2.6.0, Aki did add a "robust in-only" mode (set the
> > > "org.apache.cxf.oneway.robust" property on the endpoint to true) which
> > > would allow returning faults to the client. This is against spec and
> > > transports like JMS I don't think can handle it (not really sure,
> > > Aki?), but but it may work for you.
> >
> > A good question. I don't know. Is the JMS endpoint using the fault
> > observer? If it uses the fault observer, it could react to this
> > situation.
>
> Well, I assume there is a fault observer on the server side, the issue is
> on
> the client side. For a one way, the client would send the message to the
> JMS queue and then continue on it's merry way. There wouldn't be anything
> setup to listen for a fault. Honestly, I'm not really sure what would be
> a
> proper thing to do in this case. If the client treats the "robust oneway"
> calls as a two way and sets up a listener, then the server would have to
> send back a response of some sort. I guess a "jms fake 202" could be sent
> or something. But it's really getting into proprietary things at this
> point. I guess I should go back to the SOAP/JMS spec and see if it
> addresses the WSDL 2 robust cases at all.
>
> > But I am now confused with what Hervé wants. Should the soap fault be
> > returned or suppressed? I thought he wanted it to be suppressed. If he
> > wanted it to be returned, yes, he could use the robust property.
>
> I thought it WAS suppressed (and only the 202 is heading back) but he
> wanted
> the mustunderstand fault to go back to the client. I could likely be
> confused as well.
>
> Dan
>
>
>
> >
> > regards, aki
> >
> > > Dan
> > >
> > > On Tuesday, April 17, 2012 03:55:55 PM Hervé BARRAULT wrote:
> > >> Hi,
> > >> I'm trying to use CXF with both WS-Addressing and One Way.
> > >>
> > >> My client send a message (not with CXF) with the following SOAP
> Header:
> > >> <soapenv:Header>
> > >> <wsa:Action soapenv:mustUnderstand="1">
> > >> http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Notify
> > >> </wsa:Action>
> > >> </soapenv:Header>
> > >>
> > >> In my logs, I had :
> > >> 14:10:31,210 | WARN | ault-workqueue-2 |
> > >> PhaseInterceptorChain |
> > >> org.apache.cxf.common.logging.LogUtils 369
> |
> > >> - - | Interceptor for {
> > >>
> http://example.com/test1}StatusBrokerService#{http://docs.oasis-open.or
> > >> g/w sn/brw-2}Notifyhas thrown exception, unwinding now
> > >> org.apache.cxf.binding.soap.SoapFault: MustUnderstand headers: [{
> > >> http://www.w3.org/2005/08/addressing}Action] are not understood.
> > >> at
> > >>
> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$Ultim
> > >> ate
> > >> ReceiverMustUnderstandInterceptor.handleMessage(MustUnderstandIntercep
> > >> tor. java:225) at
> > >>
> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$Ultim
> > >> ate
> > >> ReceiverMustUnderstandInterceptor.handleMessage(MustUnderstandIntercep
> > >> tor. java:199) at
> > >>
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptor
> > >> Cha in.java:243) at
> > >>
> org.apache.cxf.phase.PhaseInterceptorChain.resume(PhaseInterceptorChain
> > >> .ja va:218) at
> > >>
> org.apache.cxf.interceptor.OneWayProcessorInterceptor$1.run(OneWayProce
> > >> sso rInterceptor.java:105) at
> > >>
> org.apache.cxf.workqueue.AutomaticWorkQueueImpl$2.run(AutomaticWorkQueu
> > >> eIm pl.java:332) at
> > >>
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecut
> > >> or. java:886) at
> > >>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.j
> > >> ava>>
> > >> :908) at java.lang.Thread.run(Thread.java:662)
> > >>
> > >> And there was a classical 202/Accepted for a One Way message (fault
> not
> > >> returned as it is one way).
> > >>
> > >>
> > >>
> > >> So, I found an interesting topics which says, enable the ws-addressing
> > >> feature (to avoid this fault) :
> > >> I added the feature
> > >> <cxf:features>
> > >> <wsa:addressing/>
> > >> </cxf:features>
> > >>
> > >> Now when i receive a message, an answer is automatically sent (which i
> > >> guess is no more compliant with the One Way):
> > >> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/
> ">
> > >> <soap:Header>
> > >> <MessageID xmlns="http://www.w3.org/2005/08/addressing
> > >> ">urn:uuid:67074ee9-455b-4488-b48d-e2a9b16a7c1b</MessageID>
> > >> <To xmlns="http://www.w3.org/2005/08/addressing">
> > >> http://www.w3.org/2005/08/addressing/anonymous</To>
> > >> <ReplyTo xmlns="http://www.w3.org/2005/08/addressing">
> > >> <Address>http://www.w3.org/2005/08/addressing/none</Address>
> > >> </ReplyTo>
> > >> </soap:Header>
> > >> <soap:Body/>
> > >> </soap:Envelope>
> > >>
> > >> I know, i use an old version of CXF : 2.2.12-fuse-00-00 but i have not
> > >> seen a related JIRA (and a post said that 2.4.0 had the same
> behavior).
> > >> (I am using also the PAYLOAD mode)
> > >>
> > >> I am doing it the right way ?
> > >> Is this behavior normal ?
> > >>
> > >> Thanks for answers
> > >> Regards
> > >> Hervé
> > >
> > > --
> > > Daniel Kulp
> > > dkulp@apache.org - http://dankulp.com/blog
> > > Talend Community Coder - http://coders.talend.com
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
Re: WS-Addressing and One Way
Posted by Aki Yoshida <el...@googlemail.com>.
2012/4/23 Daniel Kulp <dk...@apache.org>:
> On Monday, April 23, 2012 10:50:05 PM Aki Yoshida wrote:
>> 2012/4/23 Daniel Kulp <dk...@apache.org>:
>> > This is "proper" behavior as per spec. In a one way, the client just
>> > knows that the message was posted, that's it. As an example, if using
>> > JMS, the client just posts the message to the queue and returns. There
>> > is absolutely no way to get any information about whether the request
>> > was able to be parsed or processed back from the server.
>> >
>> > In 2.6.0, Aki did add a "robust in-only" mode (set the
>> > "org.apache.cxf.oneway.robust" property on the endpoint to true) which
>> > would allow returning faults to the client. This is against spec and
>> > transports like JMS I don't think can handle it (not really sure,
>> > Aki?), but but it may work for you.
>>
>> A good question. I don't know. Is the JMS endpoint using the fault
>> observer? If it uses the fault observer, it could react to this
>> situation.
>
> Well, I assume there is a fault observer on the server side, the issue is on
> the client side. For a one way, the client would send the message to the
> JMS queue and then continue on it's merry way. There wouldn't be anything
> setup to listen for a fault. Honestly, I'm not really sure what would be a
> proper thing to do in this case. If the client treats the "robust oneway"
> calls as a two way and sets up a listener, then the server would have to
> send back a response of some sort. I guess a "jms fake 202" could be sent
> or something. But it's really getting into proprietary things at this
> point. I guess I should go back to the SOAP/JMS spec and see if it
> addresses the WSDL 2 robust cases at all.
Hi Dan,
I think the robust property makes sense for the server side but not
for the client side. The problem of the HTTP transport with oneway is
that the client doesn't know if the message reaches the target service
and that no component is taking the responsibility of making the
service receiving the message behind that oneway asynchronous
boundary.
In the robust mode, the HTTP client will not get an HTTP 202 response
if something goes wrong at the server side. So if it does not receive
an HTTP 202 response, it can at least choose to resend the message
until it receives an HTTP202 response (this resend could potentially
lead to a duplicate invocation of the service but this can be filtered
out if each message carries a unique identifier).
In contrast, in the JMS case, the server (or the queue) is taking the
responsibility of making the service receives the message once the
message is placed in the queue. So, if the client can send out a
message to the queue, it can assume that he doesn't need to worry
about the message (or there is nothing he can do).
regards, aki
>
>> But I am now confused with what Hervé wants. Should the soap fault be
>> returned or suppressed? I thought he wanted it to be suppressed. If he
>> wanted it to be returned, yes, he could use the robust property.
>
> I thought it WAS suppressed (and only the 202 is heading back) but he wanted
> the mustunderstand fault to go back to the client. I could likely be
> confused as well.
>
> Dan
>
>
>
>>
>> regards, aki
>>
>> > Dan
>> >
>> > On Tuesday, April 17, 2012 03:55:55 PM Hervé BARRAULT wrote:
>> >> Hi,
>> >> I'm trying to use CXF with both WS-Addressing and One Way.
>> >>
>> >> My client send a message (not with CXF) with the following SOAP Header:
>> >> <soapenv:Header>
>> >> <wsa:Action soapenv:mustUnderstand="1">
>> >> http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Notify
>> >> </wsa:Action>
>> >> </soapenv:Header>
>> >>
>> >> In my logs, I had :
>> >> 14:10:31,210 | WARN | ault-workqueue-2 |
>> >> PhaseInterceptorChain |
>> >> org.apache.cxf.common.logging.LogUtils 369 |
>> >> - - | Interceptor for {
>> >> http://example.com/test1}StatusBrokerService#{http://docs.oasis-open.or
>> >> g/w sn/brw-2}Notifyhas thrown exception, unwinding now
>> >> org.apache.cxf.binding.soap.SoapFault: MustUnderstand headers: [{
>> >> http://www.w3.org/2005/08/addressing}Action] are not understood.
>> >> at
>> >> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$Ultim
>> >> ate
>> >> ReceiverMustUnderstandInterceptor.handleMessage(MustUnderstandIntercep
>> >> tor. java:225) at
>> >> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$Ultim
>> >> ate
>> >> ReceiverMustUnderstandInterceptor.handleMessage(MustUnderstandIntercep
>> >> tor. java:199) at
>> >> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptor
>> >> Cha in.java:243) at
>> >> org.apache.cxf.phase.PhaseInterceptorChain.resume(PhaseInterceptorChain
>> >> .ja va:218) at
>> >> org.apache.cxf.interceptor.OneWayProcessorInterceptor$1.run(OneWayProce
>> >> sso rInterceptor.java:105) at
>> >> org.apache.cxf.workqueue.AutomaticWorkQueueImpl$2.run(AutomaticWorkQueu
>> >> eIm pl.java:332) at
>> >> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecut
>> >> or. java:886) at
>> >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.j
>> >> ava>>
>> >> :908) at java.lang.Thread.run(Thread.java:662)
>> >>
>> >> And there was a classical 202/Accepted for a One Way message (fault not
>> >> returned as it is one way).
>> >>
>> >>
>> >>
>> >> So, I found an interesting topics which says, enable the ws-addressing
>> >> feature (to avoid this fault) :
>> >> I added the feature
>> >> <cxf:features>
>> >> <wsa:addressing/>
>> >> </cxf:features>
>> >>
>> >> Now when i receive a message, an answer is automatically sent (which i
>> >> guess is no more compliant with the One Way):
>> >> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
>> >> <soap:Header>
>> >> <MessageID xmlns="http://www.w3.org/2005/08/addressing
>> >> ">urn:uuid:67074ee9-455b-4488-b48d-e2a9b16a7c1b</MessageID>
>> >> <To xmlns="http://www.w3.org/2005/08/addressing">
>> >> http://www.w3.org/2005/08/addressing/anonymous</To>
>> >> <ReplyTo xmlns="http://www.w3.org/2005/08/addressing">
>> >> <Address>http://www.w3.org/2005/08/addressing/none</Address>
>> >> </ReplyTo>
>> >> </soap:Header>
>> >> <soap:Body/>
>> >> </soap:Envelope>
>> >>
>> >> I know, i use an old version of CXF : 2.2.12-fuse-00-00 but i have not
>> >> seen a related JIRA (and a post said that 2.4.0 had the same behavior).
>> >> (I am using also the PAYLOAD mode)
>> >>
>> >> I am doing it the right way ?
>> >> Is this behavior normal ?
>> >>
>> >> Thanks for answers
>> >> Regards
>> >> Hervé
>> >
>> > --
>> > Daniel Kulp
>> > dkulp@apache.org - http://dankulp.com/blog
>> > Talend Community Coder - http://coders.talend.com
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
Re: WS-Addressing and One Way
Posted by Daniel Kulp <dk...@apache.org>.
On Monday, April 23, 2012 10:50:05 PM Aki Yoshida wrote:
> 2012/4/23 Daniel Kulp <dk...@apache.org>:
> > This is "proper" behavior as per spec. In a one way, the client just
> > knows that the message was posted, that's it. As an example, if using
> > JMS, the client just posts the message to the queue and returns. There
> > is absolutely no way to get any information about whether the request
> > was able to be parsed or processed back from the server.
> >
> > In 2.6.0, Aki did add a "robust in-only" mode (set the
> > "org.apache.cxf.oneway.robust" property on the endpoint to true) which
> > would allow returning faults to the client. This is against spec and
> > transports like JMS I don't think can handle it (not really sure,
> > Aki?), but but it may work for you.
>
> A good question. I don't know. Is the JMS endpoint using the fault
> observer? If it uses the fault observer, it could react to this
> situation.
Well, I assume there is a fault observer on the server side, the issue is on
the client side. For a one way, the client would send the message to the
JMS queue and then continue on it's merry way. There wouldn't be anything
setup to listen for a fault. Honestly, I'm not really sure what would be a
proper thing to do in this case. If the client treats the "robust oneway"
calls as a two way and sets up a listener, then the server would have to
send back a response of some sort. I guess a "jms fake 202" could be sent
or something. But it's really getting into proprietary things at this
point. I guess I should go back to the SOAP/JMS spec and see if it
addresses the WSDL 2 robust cases at all.
> But I am now confused with what Hervé wants. Should the soap fault be
> returned or suppressed? I thought he wanted it to be suppressed. If he
> wanted it to be returned, yes, he could use the robust property.
I thought it WAS suppressed (and only the 202 is heading back) but he wanted
the mustunderstand fault to go back to the client. I could likely be
confused as well.
Dan
>
> regards, aki
>
> > Dan
> >
> > On Tuesday, April 17, 2012 03:55:55 PM Hervé BARRAULT wrote:
> >> Hi,
> >> I'm trying to use CXF with both WS-Addressing and One Way.
> >>
> >> My client send a message (not with CXF) with the following SOAP Header:
> >> <soapenv:Header>
> >> <wsa:Action soapenv:mustUnderstand="1">
> >> http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Notify
> >> </wsa:Action>
> >> </soapenv:Header>
> >>
> >> In my logs, I had :
> >> 14:10:31,210 | WARN | ault-workqueue-2 |
> >> PhaseInterceptorChain |
> >> org.apache.cxf.common.logging.LogUtils 369 |
> >> - - | Interceptor for {
> >> http://example.com/test1}StatusBrokerService#{http://docs.oasis-open.or
> >> g/w sn/brw-2}Notifyhas thrown exception, unwinding now
> >> org.apache.cxf.binding.soap.SoapFault: MustUnderstand headers: [{
> >> http://www.w3.org/2005/08/addressing}Action] are not understood.
> >> at
> >> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$Ultim
> >> ate
> >> ReceiverMustUnderstandInterceptor.handleMessage(MustUnderstandIntercep
> >> tor. java:225) at
> >> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$Ultim
> >> ate
> >> ReceiverMustUnderstandInterceptor.handleMessage(MustUnderstandIntercep
> >> tor. java:199) at
> >> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptor
> >> Cha in.java:243) at
> >> org.apache.cxf.phase.PhaseInterceptorChain.resume(PhaseInterceptorChain
> >> .ja va:218) at
> >> org.apache.cxf.interceptor.OneWayProcessorInterceptor$1.run(OneWayProce
> >> sso rInterceptor.java:105) at
> >> org.apache.cxf.workqueue.AutomaticWorkQueueImpl$2.run(AutomaticWorkQueu
> >> eIm pl.java:332) at
> >> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecut
> >> or. java:886) at
> >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.j
> >> ava>>
> >> :908) at java.lang.Thread.run(Thread.java:662)
> >>
> >> And there was a classical 202/Accepted for a One Way message (fault not
> >> returned as it is one way).
> >>
> >>
> >>
> >> So, I found an interesting topics which says, enable the ws-addressing
> >> feature (to avoid this fault) :
> >> I added the feature
> >> <cxf:features>
> >> <wsa:addressing/>
> >> </cxf:features>
> >>
> >> Now when i receive a message, an answer is automatically sent (which i
> >> guess is no more compliant with the One Way):
> >> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
> >> <soap:Header>
> >> <MessageID xmlns="http://www.w3.org/2005/08/addressing
> >> ">urn:uuid:67074ee9-455b-4488-b48d-e2a9b16a7c1b</MessageID>
> >> <To xmlns="http://www.w3.org/2005/08/addressing">
> >> http://www.w3.org/2005/08/addressing/anonymous</To>
> >> <ReplyTo xmlns="http://www.w3.org/2005/08/addressing">
> >> <Address>http://www.w3.org/2005/08/addressing/none</Address>
> >> </ReplyTo>
> >> </soap:Header>
> >> <soap:Body/>
> >> </soap:Envelope>
> >>
> >> I know, i use an old version of CXF : 2.2.12-fuse-00-00 but i have not
> >> seen a related JIRA (and a post said that 2.4.0 had the same behavior).
> >> (I am using also the PAYLOAD mode)
> >>
> >> I am doing it the right way ?
> >> Is this behavior normal ?
> >>
> >> Thanks for answers
> >> Regards
> >> Hervé
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org - http://dankulp.com/blog
> > Talend Community Coder - http://coders.talend.com
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: WS-Addressing and One Way
Posted by Aki Yoshida <el...@googlemail.com>.
2012/4/23 Daniel Kulp <dk...@apache.org>:
>
>
> This is "proper" behavior as per spec. In a one way, the client just knows
> that the message was posted, that's it. As an example, if using JMS, the
> client just posts the message to the queue and returns. There is absolutely
> no way to get any information about whether the request was able to be
> parsed or processed back from the server.
>
> In 2.6.0, Aki did add a "robust in-only" mode (set the
> "org.apache.cxf.oneway.robust" property on the endpoint to true) which would
> allow returning faults to the client. This is against spec and transports
> like JMS I don't think can handle it (not really sure, Aki?), but but it may
> work for you.
A good question. I don't know. Is the JMS endpoint using the fault
observer? If it uses the fault observer, it could react to this
situation.
But I am now confused with what Hervé wants. Should the soap fault be
returned or suppressed? I thought he wanted it to be suppressed. If he
wanted it to be returned, yes, he could use the robust property.
regards, aki
>
> Dan
>
>
>
> On Tuesday, April 17, 2012 03:55:55 PM Hervé BARRAULT wrote:
>> Hi,
>> I'm trying to use CXF with both WS-Addressing and One Way.
>>
>> My client send a message (not with CXF) with the following SOAP Header:
>> <soapenv:Header>
>> <wsa:Action soapenv:mustUnderstand="1">
>> http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Notify
>> </wsa:Action>
>> </soapenv:Header>
>>
>> In my logs, I had :
>> 14:10:31,210 | WARN | ault-workqueue-2 |
>> PhaseInterceptorChain |
>> org.apache.cxf.common.logging.LogUtils 369 | -
>> - | Interceptor for {
>> http://example.com/test1}StatusBrokerService#{http://docs.oasis-open.org/w
>> sn/brw-2}Notifyhas thrown exception, unwinding now
>> org.apache.cxf.binding.soap.SoapFault: MustUnderstand headers: [{
>> http://www.w3.org/2005/08/addressing}Action] are not understood.
>> at
>> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$Ultimate
>> ReceiverMustUnderstandInterceptor.handleMessage(MustUnderstandInterceptor.
>> java:225) at
>> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$Ultimate
>> ReceiverMustUnderstandInterceptor.handleMessage(MustUnderstandInterceptor.
>> java:199) at
>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorCha
>> in.java:243) at
>> org.apache.cxf.phase.PhaseInterceptorChain.resume(PhaseInterceptorChain.ja
>> va:218) at
>> org.apache.cxf.interceptor.OneWayProcessorInterceptor$1.run(OneWayProcesso
>> rInterceptor.java:105) at
>> org.apache.cxf.workqueue.AutomaticWorkQueueImpl$2.run(AutomaticWorkQueueIm
>> pl.java:332) at
>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.
>> java:886) at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java
>> :908) at java.lang.Thread.run(Thread.java:662)
>>
>> And there was a classical 202/Accepted for a One Way message (fault not
>> returned as it is one way).
>>
>>
>>
>> So, I found an interesting topics which says, enable the ws-addressing
>> feature (to avoid this fault) :
>> I added the feature
>> <cxf:features>
>> <wsa:addressing/>
>> </cxf:features>
>>
>> Now when i receive a message, an answer is automatically sent (which i
>> guess is no more compliant with the One Way):
>> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
>> <soap:Header>
>> <MessageID xmlns="http://www.w3.org/2005/08/addressing
>> ">urn:uuid:67074ee9-455b-4488-b48d-e2a9b16a7c1b</MessageID>
>> <To xmlns="http://www.w3.org/2005/08/addressing">
>> http://www.w3.org/2005/08/addressing/anonymous</To>
>> <ReplyTo xmlns="http://www.w3.org/2005/08/addressing">
>> <Address>http://www.w3.org/2005/08/addressing/none</Address>
>> </ReplyTo>
>> </soap:Header>
>> <soap:Body/>
>> </soap:Envelope>
>>
>> I know, i use an old version of CXF : 2.2.12-fuse-00-00 but i have not
>> seen a related JIRA (and a post said that 2.4.0 had the same behavior).
>> (I am using also the PAYLOAD mode)
>>
>> I am doing it the right way ?
>> Is this behavior normal ?
>>
>> Thanks for answers
>> Regards
>> Hervé
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
Re: WS-Addressing and One Way
Posted by Daniel Kulp <dk...@apache.org>.
This is "proper" behavior as per spec. In a one way, the client just knows
that the message was posted, that's it. As an example, if using JMS, the
client just posts the message to the queue and returns. There is absolutely
no way to get any information about whether the request was able to be
parsed or processed back from the server.
In 2.6.0, Aki did add a "robust in-only" mode (set the
"org.apache.cxf.oneway.robust" property on the endpoint to true) which would
allow returning faults to the client. This is against spec and transports
like JMS I don't think can handle it (not really sure, Aki?), but but it may
work for you.
Dan
On Tuesday, April 17, 2012 03:55:55 PM Hervé BARRAULT wrote:
> Hi,
> I'm trying to use CXF with both WS-Addressing and One Way.
>
> My client send a message (not with CXF) with the following SOAP Header:
> <soapenv:Header>
> <wsa:Action soapenv:mustUnderstand="1">
> http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Notify
> </wsa:Action>
> </soapenv:Header>
>
> In my logs, I had :
> 14:10:31,210 | WARN | ault-workqueue-2 |
> PhaseInterceptorChain |
> org.apache.cxf.common.logging.LogUtils 369 | -
> - | Interceptor for {
> http://example.com/test1}StatusBrokerService#{http://docs.oasis-open.org/w
> sn/brw-2}Notifyhas thrown exception, unwinding now
> org.apache.cxf.binding.soap.SoapFault: MustUnderstand headers: [{
> http://www.w3.org/2005/08/addressing}Action] are not understood.
> at
> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$Ultimate
> ReceiverMustUnderstandInterceptor.handleMessage(MustUnderstandInterceptor.
> java:225) at
> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$Ultimate
> ReceiverMustUnderstandInterceptor.handleMessage(MustUnderstandInterceptor.
> java:199) at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorCha
> in.java:243) at
> org.apache.cxf.phase.PhaseInterceptorChain.resume(PhaseInterceptorChain.ja
> va:218) at
> org.apache.cxf.interceptor.OneWayProcessorInterceptor$1.run(OneWayProcesso
> rInterceptor.java:105) at
> org.apache.cxf.workqueue.AutomaticWorkQueueImpl$2.run(AutomaticWorkQueueIm
> pl.java:332) at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.
> java:886) at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java
> :908) at java.lang.Thread.run(Thread.java:662)
>
> And there was a classical 202/Accepted for a One Way message (fault not
> returned as it is one way).
>
>
>
> So, I found an interesting topics which says, enable the ws-addressing
> feature (to avoid this fault) :
> I added the feature
> <cxf:features>
> <wsa:addressing/>
> </cxf:features>
>
> Now when i receive a message, an answer is automatically sent (which i
> guess is no more compliant with the One Way):
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
> <soap:Header>
> <MessageID xmlns="http://www.w3.org/2005/08/addressing
> ">urn:uuid:67074ee9-455b-4488-b48d-e2a9b16a7c1b</MessageID>
> <To xmlns="http://www.w3.org/2005/08/addressing">
> http://www.w3.org/2005/08/addressing/anonymous</To>
> <ReplyTo xmlns="http://www.w3.org/2005/08/addressing">
> <Address>http://www.w3.org/2005/08/addressing/none</Address>
> </ReplyTo>
> </soap:Header>
> <soap:Body/>
> </soap:Envelope>
>
> I know, i use an old version of CXF : 2.2.12-fuse-00-00 but i have not
> seen a related JIRA (and a post said that 2.4.0 had the same behavior).
> (I am using also the PAYLOAD mode)
>
> I am doing it the right way ?
> Is this behavior normal ?
>
> Thanks for answers
> Regards
> Hervé
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com