Hi Ruwan,


yes I certainly understand this concern and am also looking for a clean approach. You are right it is basically the question whether the fault mediator is allowed to contain application protocol specific logic besides the already existing SOAP-logic (which is actually also application protocol specific logic).

It is not really the core which would be aware of the hessian protocol, but a mediator being part of the current synapse core Maven module. I think subclassing the FaultMediator to create a Hessian-aware mediator in the extensions-module would be possible, but would not be worth the code overhead. I will continue to think about it…






From: Ruwan Linton [mailto:ruwan.linton@gmail.com]
Sent: Saturday, March 14, 2009 7:44 PM
To: dev@synapse.apache.org
Subject: Re: Creating HessianFaults using FaultMediator/HessianMessageFormatter


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.


On Sat, Mar 14, 2009 at 11:43 PM, Hubert, Eric <Eric.Hubert@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"/>

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!


Ruwan Linton
Senior Software Engineer & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ruwan@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com