[RESULT][VOTE] Release CXF 2.0.8
We have 13 +1 votes, 11 PMC binding: +1 PMC: dkulp, ffang, bmargulies, wjiang, apaibir, eglynn, ubhole, jgawor, pjones, gnodet, gmazza +1 Committer: bganesh +1 Other: ekanu Thus, this vote passes. I'll try to get the artifacts published over the next day or so. Dan On Jul 22, 2008, at 9:36 PM, Daniel Kulp wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is a vote to release CXF 2.0.8 Once again, there have been a bunch of bug fixes and enhancements that have been done compared to the 2.0.8 release. Over 28 JIRA issues are resolved for 2.0.8. Most importantly, this contains a critical fix that was preventing Geronimo from being able to upgrade to our recent releases. They need this so they can release Geronimo 2.1.2 which they would like to do next week. List of issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12313269&styleName=Html&projectId=12310511&Create=Create The staging area is at: http://people.apache.org/~dkulp/stage_cxf/2.0.8 The distributions are in the "dist" directory. The "maven" directory contains the stuff that will by pushed to the central repository. This release is tagged at: http://svn.apache.org/repos/asf/incubator/cxf/tags/cxf-2.0.8 Here is my +1. The vote will be open here for at least 72 hours. - --- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (Darwin) iD8DBQFIhos1q8juObtVB0YRAu+GAJ9wlLmUL603COMNIv52xwvB2+XMgACaA8K2 0OImzd5F9+EtcKeWx+Rf7i0= =kqY9 -END PGP SIGNATURE- --- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
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: http://schemas.xmlsoap.org/soap/envelope/";> soap:Client WSSECURITY_EX 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-2508/#_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.
