I don't know exactly. It was just an idea that came to my mind. Let's
see what others on the list think about it.
Andreas
On Sun, Mar 15, 2009 at 16:47, Supun Kamburugamuva <supu...@gmail.com> wrote:
> If setting 200 in case of a hessian fault is not an option for the user,
> using a module will be a cleaner solution. BTW did you mean another handler
> for Synapse or a complete module?
>
> Supun
>
> On Sun, Mar 15, 2009 at 8:20 PM, Andreas Veithen <andreas.veit...@gmail.com>
> wrote:
>>
>> 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
>>
>
>
>
> --
> 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
