If setting 200 in case of a Hessian fault is a must, why don't we do it in
the HessianMessageFormatter? My be I'm missing something :)
Thanks,
Supun.
On Sun, Mar 15, 2009 at 4:05 PM, Andreas Veithen
<andreas.veit...@gmail.com>wrote:
> Just throwing an idea into the discussion: What about an Axis2 module?
>
> Andreas
>
> On Sun, Mar 15, 2009 at 00:11, Hubert, Eric <eric.hub...@foxmobile.com>
> wrote:
> > 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
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
> > For additional commands, e-mail: dev-h...@synapse.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
> For additional commands, e-mail: dev-h...@synapse.apache.org
>
>
--
Software Engineer, WSO2 Inc
http://wso2.org
supunk.blogspot.com
