[
https://issues.apache.org/jira/browse/CAMEL-5330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang reassigned CAMEL-5330:
-----------------------------------
Assignee: Willem Jiang
> Supporting Camel-CXFs Provider's null response handling (a way to dynamically
> indicate no response should be sent back)
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-5330
> URL: https://issues.apache.org/jira/browse/CAMEL-5330
> Project: Camel
> Issue Type: Improvement
> Components: camel-cxf
> Affects Versions: 2.9.2
> Reporter: Aki Yoshida
> Assignee: Willem Jiang
> Fix For: 2.9.3, 2.10.1
>
> Attachments: trunk-camel-cxf-patch.diff
>
>
> A Camel-CXF's provider endpoint returns an HTTP 200 with an empty SOAP
> message when it should be returning an HTTP 202 with no content.
> This is analogue to the jaxws's Provider behavior implemented in:
> CXF-3926 Supporting JAXWS Provider's null response handling (the provider's
> invoke may return a null to indicate no response should be sent back)
> where property jaxws.provider.interpretNullAsOneway at the endpoint
> determines whether a null is interpreted as a oneway call (i.e. no response).
> Concretely, Jaxws 2.2 section 5.1.1 states:
> "When an invoke method returns null, it is considered that no response needs
> to be sent by service."
> This use case assumes there is no information about the operation's MEP (no
> wsdl, no java annotation).
> This offers an option of using a provider endpoint to dynamically change its
> response behavior based on the retern value.
> Namely, if the service returns a non-null value, the response is a normal
> HTTP 200 with the corresponding payload. In contrast, if the service returns
> a null, the response becomes an HTTP 202 with no content.
> I think it makes sense to align the Camel-CXF Provider's endpoint to support
> this behavior.
> I am proposing a fix in DefaultCxfBinding to provide this behavior.
> Additionally, to simplify the configuration of a provider endpoint, I think
> it is practical to introduce a default payload provider SEI so that the
> provider SEI does not explicitly configured in the endpoint configuration.
> I am attaching a patch file including these changes and test cases to
> illustrate these points.
> Could you have a look at this?
> Thanks
> regards, aki
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
