For two reasons:
1. Message formatters should be protocol independent (even if they
have access to the full MessageContext).
2. Probably when the message formatter is invoked, it is already too
late to set the HTTP status code.
Andreas
On Sun, Mar 15, 2009 at 16:17, Supun Kamburugamuva <supu...@gmail.com> wrote:
> 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
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org
