synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hubert, Eric" <Eric.Hub...@foxmobile.com>
Subject RE: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Date Sat, 14 Mar 2009 23:11:00 GMT
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
Mime
View raw message