[
http://jira.codehaus.org/browse/XFIRE-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96065
]
Reshat Sabiq commented on XFIRE-990:
------------------------------------
The patch i attached yesterday is probably useful for custom type serialization
in general, but to accommodate accurate serialization of soap:Fault in a
soap:Body child, i think the patch i attached to
http://jira.codehaus.org/browse/XFIRE-995
is what's needed: it allows re-use of Soap12FaultSerializer w/o
setWriteOuter(false); accommodated in the patch attached here, along w/
addressing validity of produced serialization.
But i think the patch attached here is still valid for custom types, as
Type.isWriteOuter() currently is not honored. Should i log a separate bug and
attach the patch attached here under that new one, specifically for
Type.isWriteOuter()?
> XFireFault is not serialized correctly when it is a descendant of a child
> element of SOAP Body
> ----------------------------------------------------------------------------------------------
>
> Key: XFIRE-990
> URL: http://jira.codehaus.org/browse/XFIRE-990
> Project: XFire
> Issue Type: Bug
> Environment: 1.2.5
> Reporter: Reshat Sabiq
> Assignee: Dan Diephouse
> Attachments: custom-type-serialization.patch
>
>
> SOAP 1.2 says: "A SOAP Fault element information item MAY appear within a
> SOAP header block, or as a descendant of a child element information item of
> the SOAP Body ; in such cases, the element has no SOAP-defined semantics."
> Given that the spec allows it, i think xfire should handle.
> Given that we have regular faults, and we don't completely stop processing
> after an exception pertaining to an individual subrequest, i'm trying to
> indicate the status of an individual subrequest using a soap:Fault as well.
> However, when representing that fault w/ XFireFault, it is not serialized as
> a soap:Fault, e.g. shown below. It is instead serialized like a regular java
> object.
> One thought i have is to represent this as a String field, and serialize it
> manually into soap:Fault, so that client can peruse individual status codes
> similarly to complete failures indicated by soap:Fault (this would involve
> JAXB and such outside of xfire, because we are not using java 5, and can't do
> schema-to-java). Another way could involve a handler, and replacing content
> in OutMessage. But first is not declarative, and 2nd would be a potential
> performance drag. I think this should be handled by the framework itself.
> P.S. This is what i was hoping for as a field of a subrequest:
> <soap:Fault>
> <soap:Code>
> <soap:Value>soap:Sender</soap:Value>
> <soap:SubCode>
> <soap:Value
> xmlns:error="urn:some.urn">error:SomeError</soap:Value>
> </soap:SubCode>
> </soap:Code>
> <soap:Reason>
> <soap:Text>Some Error</soap:Text>
> </soap:Reason>
> <soap:Detail>
> <error:detail code="1001"
> xmlns:error="urn:some.urn">someField</error:detail>
> </soap:Detail>
> </soap:Fault>
> P.P.S. This is what is serialized by xfire as of now:
> <fault>
> <detail xmlns="http://fault.xfire.codehaus.org";>
> <soap:Detail>
> <error:detail code="1001"
> xmlns:error="urn:some.urn"/>
> </soap:Detail>
> </detail>
> <faultCode xmlns="http://fault.xfire.codehaus.org";>
> <localPart
> xmlns="http://namespace.xml.javax";>Sender</localPart>
> <namespaceURI
> xmlns="http://namespace.xml.javax";>http://www.w3.org/2003/05/soap-envelope</namespaceURI>
> <prefix xmlns="http://namespace.xml.javax"/>
> </faultCode>
> <message xmlns="http://fault.xfire.codehaus.org";>Some
> Error</message>
> <namespaces xmlns="http://fault.xfire.codehaus.org"/>
> <reason xmlns="http://fault.xfire.codehaus.org";>Some
> Error</reason>
> <role xsi:nil="true"
> xmlns="http://fault.xfire.codehaus.org"/>
> <subCode xmlns="http://fault.xfire.codehaus.org";>
> <localPart
> xmlns="http://namespace.xml.javax";>SomeError</localPart>
> <namespaceURI
> xmlns="http://namespace.xml.javax";>urn:some.urn</namespaceURI>
> <prefix
> xmlns="http://namespace.xml.javax";>error</prefix>
> </subCode>
> </fault>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
