The muse-wsa-action module just ensures that the WS-A Action header in
SOAP response messages is different than that of the request. See this bug
report for details:
http://issues.apache.org/jira/browse/MUSE-41
Anyway, this wouldn't have any effect on the use of a proxy. Right now,
Muse sits on top of an Axis2 service that takes/returns OMElements - kind
of like the simple example that ships with Axis2. We just return the
response data to Axis2, and it packages the SOAP response and sends it off
- I don't recall doing anything that would affect the underlying
transport... is there anything from the Axis2 docs that explains what
application behavior might break the proxy usage?
Dan
<[EMAIL PROTECTED]> wrote on 03/29/2007 12:07:29 PM:
> Hi guys,
>
>
>
> I have developed a simple web service that implements WSRF in muse and
> deployed it successfully within an axis2 environment. The service comes
> with a simple website that allows to create two resources and then call
> the second from the first. I am making the call with the standard proxy
> that is generated by the framework. So far so good.
>
>
>
> Now I started to adjust the underlying axis2 configuration, in
> particular I added a (http) proxy parameter to the HTTPTransport sender
> in axis2.xml in order to make between the resources go through a proxy.
> For my sample axis2 service this works as expected (ie call is sent via
> the proxy) but for the muse service the option seems to have no effect.
> I have double checked the axis2.xml in both scenarios and they are
> identical apart from the muse-wsa-action module. Can someone clarify,
> could it be that this module impacts the way messages are sent out?
>
>
>
> Cheers
>
> andi
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
