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
Sent: Saturday, March 14, 2009
Subject: Re: Creating
HessianFaults using FaultMediator/HessianMessageFormatter
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
On Sat, Mar 14, 2009 at 11:43 PM, Hubert,
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
<syn:switch source="get-property('transport', 'Content-Type')">
<syn:property name="HTTP_SC" value="200"
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!
Senior Software Engineer & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: email@example.com; cell: +94 77 341