You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Glen Mazza <gl...@gmail.com> on 2008/07/26 17:05:51 UTC
Creation of empty detail elements for SOAPFaults
Team,
I'm trying to get CXF to work with WSS4J for signature/encryption right now.
I got the following error message back from WSS4J:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<soap:Fault>
<faultcode>soap:Client</faultcode>
<faultstring>WSSECURITY_EX</faultstring>
</soap:Fault>
</soap:Body>
</soap:Envelope>
Partial error stack that produced that message:
[INFO] Exception in thread "main" javax.xml.ws.soap.SOAPFaultException:
WSSECURITY_EX
[INFO] at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:218)
[INFO] at $Proxy27.doubleIt(Unknown Source)
[INFO] at
com.mycompany.webservice.client.WSClient.doubleIt(WSClient.java:26)
[INFO] at com.mycompany.webservice.client.WSClient.main(WSClient.java:19)
[INFO] Caused by: org.apache.cxf.binding.soap.SoapFault: WSSECURITY_EX
[INFO] at
org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:70)
[INFO] at
org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:35)
[INFO] at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:221)
The error message I'm getting is not my concern right now--it is what CXF
appears to be doing to it. It seems(*) that CXF is placing an empty Detail
element within this SOAPFault response. This triggers the
SOAPFault.hasDetail() method to be true, which causes users to need to write
additional code to parse through the Detail's nonexistent
DetailElements--which is annoying once it turns out there's no DetailEntries
to parse.
The culprit seems to be org.apache.cxf.interceptor.Fault's
getOrCreateDetail() method, which is called by various other interceptors to
create Detail objects where there are actually no DetailEntries. Can we
avoid doing this? I would say either of two things should be done: (1) not
to create empty Detail objects if there are no DetailEntries (either when
parsing SOAP error messages coming in externally, or when a CXF web service
provider is sending back an error message), or (2) redefine
Fault.hasDetails() to mean that the SOAPFault has a Details object *and* has
DetailEntries under it. Currently, the above XML SOAP response should
return false for hasDetails(), but it's returning TRUE because of the empty
Detail element being created.
Another problem with artificial creation of SOAPFault Detail elements is
that their absence or presence has semantic value according to the SOAP
spec[2]:
"The detail element is intended for carrying application specific error
information related to the Body element. It MUST be present if the contents
of the Body element could not be successfully processed. It MUST NOT be used
to carry information about error information belonging to header entries.
Detailed error information belonging to header entries MUST be carried
within header entries.
The absence of the detail element in the Fault element indicates that the
fault is not related to processing of the Body element. This can be used to
distinguish whether the Body element was processed or not in case of a fault
situation."
Thoughts?
Thanks,
Glen
(*) I'm saying "seems" because I'm relying on the XML response I see in
Wireshark and the fact that hasDetails() is returning TRUE--indicating a
Details object was created.
[1] http://java.sun.com/javaee/5/docs/api/javax/xml/soap/SOAPFault.html
[2] http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383507
--
View this message in context: http://www.nabble.com/Creation-of-empty-detail-elements-for-SOAPFaults-tp18667733p18667733.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: Creation of empty detail elements for SOAPFaults
Posted by Glen Mazza <gl...@gmail.com>.
OK, I'll enter this as a JIRA for whenever somebody (including myself) has
time to look at it.
Thanks,
Glen
dkulp wrote:
>
>
> Honestly, I think both things should be done. We definitely
> shouldn't be creating details where one doesn't exist and isn't
> needed. And hasDetails should definitely not return true if there
> aren't details.
>
> Dan
>
>
> On Jul 26, 2008, at 11:05 AM, Glen Mazza wrote:
>
>>
>> Team,
>>
>> I'm trying to get CXF to work with WSS4J for signature/encryption
>> right now.
>> I got the following error message back from WSS4J:
>>
>> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
>> <soap:Body>
>> <soap:Fault>
>> <faultcode>soap:Client</faultcode>
>> <faultstring>WSSECURITY_EX</faultstring>
>> </soap:Fault>
>> </soap:Body>
>> </soap:Envelope>
>>
>> Partial error stack that produced that message:
>> [INFO] Exception in thread "main"
>> javax.xml.ws.soap.SOAPFaultException:
>> WSSECURITY_EX
>> [INFO] at
>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:
>> 218)
>> [INFO] at $Proxy27.doubleIt(Unknown Source)
>> [INFO] at
>> com.mycompany.webservice.client.WSClient.doubleIt(WSClient.java:26)
>> [INFO] at
>> com.mycompany.webservice.client.WSClient.main(WSClient.java:19)
>> [INFO] Caused by: org.apache.cxf.binding.soap.SoapFault: WSSECURITY_EX
>> [INFO] at
>> org
>> .apache
>> .cxf
>> .binding
>> .soap
>> .interceptor
>> .Soap11FaultInInterceptor
>> .handleMessage(Soap11FaultInInterceptor.java:70)
>> [INFO] at
>> org
>> .apache
>> .cxf
>> .binding
>> .soap
>> .interceptor
>> .Soap11FaultInInterceptor
>> .handleMessage(Soap11FaultInInterceptor.java:35)
>> [INFO] at
>> org
>> .apache
>> .cxf
>> .phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:
>> 221)
>>
>> The error message I'm getting is not my concern right now--it is
>> what CXF
>> appears to be doing to it. It seems(*) that CXF is placing an empty
>> Detail
>> element within this SOAPFault response. This triggers the
>> SOAPFault.hasDetail() method to be true, which causes users to need
>> to write
>> additional code to parse through the Detail's nonexistent
>> DetailElements--which is annoying once it turns out there's no
>> DetailEntries
>> to parse.
>>
>> The culprit seems to be org.apache.cxf.interceptor.Fault's
>> getOrCreateDetail() method, which is called by various other
>> interceptors to
>> create Detail objects where there are actually no DetailEntries. Can
>> we
>> avoid doing this? I would say either of two things should be done:
>> (1) not
>> to create empty Detail objects if there are no DetailEntries (either
>> when
>> parsing SOAP error messages coming in externally, or when a CXF web
>> service
>> provider is sending back an error message), or (2) redefine
>> Fault.hasDetails() to mean that the SOAPFault has a Details object
>> *and* has
>> DetailEntries under it. Currently, the above XML SOAP response should
>> return false for hasDetails(), but it's returning TRUE because of
>> the empty
>> Detail element being created.
>>
>> Another problem with artificial creation of SOAPFault Detail
>> elements is
>> that their absence or presence has semantic value according to the
>> SOAP
>> spec[2]:
>>
>> "The detail element is intended for carrying application specific
>> error
>> information related to the Body element. It MUST be present if the
>> contents
>> of the Body element could not be successfully processed. It MUST NOT
>> be used
>> to carry information about error information belonging to header
>> entries.
>> Detailed error information belonging to header entries MUST be carried
>> within header entries.
>>
>> The absence of the detail element in the Fault element indicates
>> that the
>> fault is not related to processing of the Body element. This can be
>> used to
>> distinguish whether the Body element was processed or not in case of
>> a fault
>> situation."
>>
>> Thoughts?
>>
>> Thanks,
>> Glen
>>
>> (*) I'm saying "seems" because I'm relying on the XML response I see
>> in
>> Wireshark and the fact that hasDetails() is returning TRUE--
>> indicating a
>> Details object was created.
>>
>> [1] http://java.sun.com/javaee/5/docs/api/javax/xml/soap/
>> SOAPFault.html
>> [2] http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383507
>> --
>> View this message in context:
>> http://www.nabble.com/Creation-of-empty-detail-elements-for-SOAPFaults-tp18667733p18667733.html
>> Sent from the cxf-dev mailing list archive at Nabble.com.
>>
>
> ---
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
>
>
>
>
>
--
View this message in context: http://www.nabble.com/Creation-of-empty-detail-elements-for-SOAPFaults-tp18667733p18702619.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: Creation of empty detail elements for SOAPFaults
Posted by Daniel Kulp <dk...@apache.org>.
Honestly, I think both things should be done. We definitely
shouldn't be creating details where one doesn't exist and isn't
needed. And hasDetails should definitely not return true if there
aren't details.
Dan
On Jul 26, 2008, at 11:05 AM, Glen Mazza wrote:
>
> Team,
>
> I'm trying to get CXF to work with WSS4J for signature/encryption
> right now.
> I got the following error message back from WSS4J:
>
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
> <soap:Body>
> <soap:Fault>
> <faultcode>soap:Client</faultcode>
> <faultstring>WSSECURITY_EX</faultstring>
> </soap:Fault>
> </soap:Body>
> </soap:Envelope>
>
> Partial error stack that produced that message:
> [INFO] Exception in thread "main"
> javax.xml.ws.soap.SOAPFaultException:
> WSSECURITY_EX
> [INFO] at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:
> 218)
> [INFO] at $Proxy27.doubleIt(Unknown Source)
> [INFO] at
> com.mycompany.webservice.client.WSClient.doubleIt(WSClient.java:26)
> [INFO] at
> com.mycompany.webservice.client.WSClient.main(WSClient.java:19)
> [INFO] Caused by: org.apache.cxf.binding.soap.SoapFault: WSSECURITY_EX
> [INFO] at
> org
> .apache
> .cxf
> .binding
> .soap
> .interceptor
> .Soap11FaultInInterceptor
> .handleMessage(Soap11FaultInInterceptor.java:70)
> [INFO] at
> org
> .apache
> .cxf
> .binding
> .soap
> .interceptor
> .Soap11FaultInInterceptor
> .handleMessage(Soap11FaultInInterceptor.java:35)
> [INFO] at
> org
> .apache
> .cxf
> .phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:
> 221)
>
> The error message I'm getting is not my concern right now--it is
> what CXF
> appears to be doing to it. It seems(*) that CXF is placing an empty
> Detail
> element within this SOAPFault response. This triggers the
> SOAPFault.hasDetail() method to be true, which causes users to need
> to write
> additional code to parse through the Detail's nonexistent
> DetailElements--which is annoying once it turns out there's no
> DetailEntries
> to parse.
>
> The culprit seems to be org.apache.cxf.interceptor.Fault's
> getOrCreateDetail() method, which is called by various other
> interceptors to
> create Detail objects where there are actually no DetailEntries. Can
> we
> avoid doing this? I would say either of two things should be done:
> (1) not
> to create empty Detail objects if there are no DetailEntries (either
> when
> parsing SOAP error messages coming in externally, or when a CXF web
> service
> provider is sending back an error message), or (2) redefine
> Fault.hasDetails() to mean that the SOAPFault has a Details object
> *and* has
> DetailEntries under it. Currently, the above XML SOAP response should
> return false for hasDetails(), but it's returning TRUE because of
> the empty
> Detail element being created.
>
> Another problem with artificial creation of SOAPFault Detail
> elements is
> that their absence or presence has semantic value according to the
> SOAP
> spec[2]:
>
> "The detail element is intended for carrying application specific
> error
> information related to the Body element. It MUST be present if the
> contents
> of the Body element could not be successfully processed. It MUST NOT
> be used
> to carry information about error information belonging to header
> entries.
> Detailed error information belonging to header entries MUST be carried
> within header entries.
>
> The absence of the detail element in the Fault element indicates
> that the
> fault is not related to processing of the Body element. This can be
> used to
> distinguish whether the Body element was processed or not in case of
> a fault
> situation."
>
> Thoughts?
>
> Thanks,
> Glen
>
> (*) I'm saying "seems" because I'm relying on the XML response I see
> in
> Wireshark and the fact that hasDetails() is returning TRUE--
> indicating a
> Details object was created.
>
> [1] http://java.sun.com/javaee/5/docs/api/javax/xml/soap/
> SOAPFault.html
> [2] http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383507
> --
> View this message in context: http://www.nabble.com/Creation-of-empty-detail-elements-for-SOAPFaults-tp18667733p18667733.html
> Sent from the cxf-dev mailing list archive at Nabble.com.
>
---
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog