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 19:32:20 GMT
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...

 

Thanks,

   Eric

 

 

________________________________

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.

Thanks,
Ruwan

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"/>
 </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: ruwan@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com 


Mime
View raw message