Just throwing an idea into the discussion: What about an Axis2 module?
Andreas
On Sun, Mar 15, 2009 at 00:11, Hubert, Eric <eric.hub...@foxmobile.com> wrote:
> I thought it might be useful for discussion to also have some sample code to
> illustrate b).
>
> Please find attached a quick implementation showing the idea.
>
> Regards,
> Eric
>
>
>> Hi all,
>>
>> if someone wants to use the FaultMediator in conjunction with Hessian
>> messages he has to know that he to set the HTTP status code to 200, after
>> using the FaultMediator and before using the SendMediator.
>>
>> Normally (for SOAP messages) the HTTP status code is 500, but Ruwan once
>> created a possibility to override this value using a property of scope
>> Axis2.
>>
>> So declaratively this is possible in synapse.xml via adding the following
>> configuration block:
>>
>> <syn:switch source="get-property('transport', 'Content-Type')">
>> <syn:case regex="x-application/hessian">
>> <syn:property name="HTTP_SC" value="200" scope="axis2"/>
>> </syn:case>
>> </syn:switch>
>>
>> The HessianFormatter transforms the SOAPFault to a Hessian fault and
>> writes a valid Hessian fault message to the client, which deserializes the
>> fault message to a HessianServiceException with the proper message.
>> This only works if the HTTP status code is 200. Any other messages will
>> not be deserialized by the Hessian Client libraries.
>>
>> I guess most people trying out the Hessian support would stumple over this
>> issue. I see two possibilities and would like to here your opinion.
>>
>> a) Document this behaviour and the needed configuration online.
>> b) Extend the FaultMediator to set this property programmatically
>> depending on the content-type header.
>>
>> I see advantages and disadvantages with both approaches. Currently the
>> FaultMediator is already handling the differences between SOAP 1.1, SOAP
>> 1.2 and POX. This would need three of four more lines as well as the
>> duplication or a move of a content-type constant for "x-
>> application/hessian" as for sure a dependency from the core to the
>> extensions module must not exist.
>>
>> Anyone having a clever option c in mind? Comments are welcome!
>>
>> Regards,
>> Eric
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
> For additional commands, e-mail: dev-h...@synapse.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org
