You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Martin Murphy (JIRA)" <ji...@apache.org> on 2010/01/05 11:59:54 UTC
[jira] Created: (CXF-2601) Faults generated with XMLBeans binding
are not wrapped correctly
Faults generated with XMLBeans binding are not wrapped correctly
----------------------------------------------------------------
Key: CXF-2601
URL: https://issues.apache.org/jira/browse/CXF-2601
Project: CXF
Issue Type: Bug
Affects Versions: 2.2.5
Environment: Tested on windows with JDK jdk1.5.0_18
Reporter: Martin Murphy
Attachments: exceptiontest.zip
When Fault in WSDL is defined as simple String and XMLBeans binding is used, then the fault is marshaled in a way, that doesn't allow proper unmarshalling of the Exception on the client side. Example fault looks like
{code:xml}
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<soap:Fault>
<faultcode>soap:Server</faultcode>
<faultstring>message</faultstring>
<detail>detail</detail>
</soap:Fault>
</soap:Body>
</soap:Envelope>
{code}
As you can see detail doesn't have any information about fault type. This means that the exception cannot be mapped to the appropriate type
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CXF-2601) Faults generated with XMLBeans binding
are not wrapped correctly
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Kulp reassigned CXF-2601:
--------------------------------
Assignee: Daniel Kulp
> Faults generated with XMLBeans binding are not wrapped correctly
> ----------------------------------------------------------------
>
> Key: CXF-2601
> URL: https://issues.apache.org/jira/browse/CXF-2601
> Project: CXF
> Issue Type: Bug
> Affects Versions: 2.2.5
> Environment: Tested on windows with JDK jdk1.5.0_18
> Reporter: Martin Murphy
> Assignee: Daniel Kulp
> Attachments: exceptiontest.zip
>
>
> When Fault in WSDL is defined as simple String and XMLBeans binding is used, then the fault is marshaled in a way, that doesn't allow proper unmarshalling of the Exception on the client side. Example fault looks like
> {code:xml}
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
> <soap:Body>
> <soap:Fault>
> <faultcode>soap:Server</faultcode>
> <faultstring>message</faultstring>
> <detail>detail</detail>
> </soap:Fault>
> </soap:Body>
> </soap:Envelope>
> {code}
> As you can see detail doesn't have any information about fault type. This means that the exception cannot be mapped to the appropriate type
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-2601) Faults generated with XMLBeans binding
are not wrapped correctly
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Kulp resolved CXF-2601.
------------------------------
Resolution: Fixed
Fix Version/s: 2.2.6
2.1.9
> Faults generated with XMLBeans binding are not wrapped correctly
> ----------------------------------------------------------------
>
> Key: CXF-2601
> URL: https://issues.apache.org/jira/browse/CXF-2601
> Project: CXF
> Issue Type: Bug
> Affects Versions: 2.2.5
> Environment: Tested on windows with JDK jdk1.5.0_18
> Reporter: Martin Murphy
> Assignee: Daniel Kulp
> Fix For: 2.1.9, 2.2.6
>
> Attachments: exceptiontest.zip
>
>
> When Fault in WSDL is defined as simple String and XMLBeans binding is used, then the fault is marshaled in a way, that doesn't allow proper unmarshalling of the Exception on the client side. Example fault looks like
> {code:xml}
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
> <soap:Body>
> <soap:Fault>
> <faultcode>soap:Server</faultcode>
> <faultstring>message</faultstring>
> <detail>detail</detail>
> </soap:Fault>
> </soap:Body>
> </soap:Envelope>
> {code}
> As you can see detail doesn't have any information about fault type. This means that the exception cannot be mapped to the appropriate type
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-2601) Faults generated with XMLBeans binding
are not wrapped correctly
Posted by "Martin Murphy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Murphy updated CXF-2601:
-------------------------------
Attachment: exceptiontest.zip
Here is a simple example that has two projects to highlight the problem. The XMLBeans project has a test that fails due to the exception being of an unexpected type. The JAXB test is the same, except it uses the JAXB binding, this test passes thus highlighting the problem is only in the XMLBeans mapping.
> Faults generated with XMLBeans binding are not wrapped correctly
> ----------------------------------------------------------------
>
> Key: CXF-2601
> URL: https://issues.apache.org/jira/browse/CXF-2601
> Project: CXF
> Issue Type: Bug
> Affects Versions: 2.2.5
> Environment: Tested on windows with JDK jdk1.5.0_18
> Reporter: Martin Murphy
> Attachments: exceptiontest.zip
>
>
> When Fault in WSDL is defined as simple String and XMLBeans binding is used, then the fault is marshaled in a way, that doesn't allow proper unmarshalling of the Exception on the client side. Example fault looks like
> {code:xml}
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
> <soap:Body>
> <soap:Fault>
> <faultcode>soap:Server</faultcode>
> <faultstring>message</faultstring>
> <detail>detail</detail>
> </soap:Fault>
> </soap:Body>
> </soap:Envelope>
> {code}
> As you can see detail doesn't have any information about fault type. This means that the exception cannot be mapped to the appropriate type
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.