Hi Eric,
While fixing the HTTP status code issue which we found earlier, I have
thought of many ways of fixing this, but all of that ended up with making
the synapse core aware of hessian behaviors which is sort of not good.
There fore I only see the option (a) as the possible approach that we can
take, may be we could add this bit of logic to the Fault mediator because
that is a mediator but not the core of synapse, so the fault mediator is
aware of the hessian protocol.
Thanks,
Ruwan
On Sat, Mar 14, 2009 at 11:43 PM, Hubert, Eric <eric.hub...@foxmobile.com>wrote:
> 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
>
--
Ruwan Linton
Senior Software Engineer & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ru...@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com
