[
https://issues.apache.org/jira/browse/AXIS2-5374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13422281#comment-13422281
]
Sagara Gunathunga edited comment on AXIS2-5374 at 7/25/12 2:07 PM:
--------------------------------------------------------------------
Once the following setting available on axis2.xml above doingREST is set to
true and provide desired functionalities too.
<parameter name="enableREST">true</parameter>
But still I don't think above solution is a widely acceptable solution.
1.) Above doingREST flag is checked and set within the HTTP module under
HTTPTransportUtils#initializeMessageContext() method. I haven't check other
transports yet but IMO this check should not belong to a specific transport
implementation. In my POV when writing a new transport it should not expect to
anticipate REST and SOAP messages by the transport implementation.
2.) "enableREST" is a kind of a hidden setting and "disableREST" setting also
there, having two settings for same or slightly different features is not a
good design. For the moment it's required to have following two settings.
<parameter name="disableREST" >false</parameter>
<parameter name="enableREST">true</parameter>
3.) HTTPTransportUtils#initializeMessageContext() method facilitate for REST
invocation by changing "text/xml" content type into "application/xml" content
type when the conditions are met. But the better approach would be perform REST
invocation while keeping "text/xml" content type as it is.
4.) As a side effect of 3.) REST invocation always returns response messages
with "application/xml" content type ignoring original content type of the
request message.
was (Author: sagara):
Once the following setting available on axis2.xml above doingREST is set to
true and provide desired functionalities too.
<parameter name="enableREST">true</parameter>
But still I don't think above solution is a widely acceptable solution.
1.) Above doingREST flag is checked and set within the HTTP module under
HTTPTransportUtils#initializeMessageContext() method. I haven't check other
transports yet but IMO this check should not belong to a specific transport
implementation. In my POV when writing a new transport it should not expect to
anticipate REST and SOAP messages by the transport implementation.
2.) "enableREST" is a kind of a hidden setting and "disableREST" setting also
there, having two settings for same or slightly different features are not a
good design. For the moment it's required to have following two settings.
<parameter name="disableREST" >false</parameter>
<parameter name="enableREST">true</parameter>
3.) HTTPTransportUtils#initializeMessageContext() method facilitate for REST
invocation by changing "text/xml" content type into "application/xml" content
type when the conditions are met. But the better approach would be perform REST
invocation while keeping "text/xml" content type as it is.
4.) As a side effect of 3.) REST invocation always returns response messages
with "application/xml" content type ignoring original content type of the
request message.
> Axis2 always assume "text/xml" as SOAP 1.1 content
> ----------------------------------------------------
>
> Key: AXIS2-5374
> URL: https://issues.apache.org/jira/browse/AXIS2-5374
> Project: Axis2
> Issue Type: Bug
> Components: kernel
> Affects Versions: 1.5.6, 1.6.2
> Reporter: Sagara Gunathunga
> Assignee: Sagara Gunathunga
> Priority: Critical
>
> Axis2 REST guide contains following text
> "if the content type is text/xml and if the SOAPAction Header is missing,
> then the message is treated as a RESTful Message, if not it is treated as a
> usual SOAP Message."
> In summery
> content type - text/xml + SOAPAction present => SOAP 1.1
> content type - text/xml + NO SOAPAction present => POX (REST)
> In contrast Axis2 never implemented above logic and always consider text/xml
> as SOAP 1.1. This issue can be solved by adding a condition to
> TransportUtils#getMessageFormatter() so that it will check "SOAPAction"
> header in addition to "text/xml" content type.
> Before I implement above solution I like see any objection from users and
> developers.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
