cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Mazza <glen.ma...@gmail.com>
Subject Re: Creation of empty detail elements for SOAPFaults
Date Tue, 29 Jul 2008 00:25:17 GMT

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.


Mime
View raw message