Hi, have a look at this URL
http://java.sun.com/j2se/1.4.2/docs/guide/net/properties.html either setting http.* those properties at the JVM level, via System.setProperty or for Tomcat in the conf/catalina.properties file. I also faced the fact that Muse sends their own Soap messages via http. I agree with you that due to the clear structure of the code it is rather easy to extend the code, but as Muse relies on Axis2 it would be nice to have the handler chain included in an external call. Anybody @muse-dev willing to accept this as a Jira entry? Best regards Matthias -----Ursprüngliche Nachricht----- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 29. März 2007 19:51 An: [email protected] Betreff: RE: axis2 deployment and configuration Thanks for the clarification. I don't see anything wrong with my deployment so I started digging into the muse code and I think I found what I was looking for. Because the code is very nicely structure it didn't take me long :) When I create my proxy which extends the WsResourceClient I ultimately use a SimpleSoapClient from the muse-wsa-soap package. This client has its own way of sending messages (see the send method), which doesn't take any configuration from the underlying axis2 deployment into account. I believe this is why my proxy settings are not picked up. For my current scenario I need the call to go through a proxy. For me it would be ideal if this configuration would be picked up from the underlying axis2 deployment. Are there any plans to incorporate that kind of functionality? -----Original Message----- From: Daniel Jemiolo [mailto:[EMAIL PROTECTED] Sent: 29 March 2007 17:25 To: [email protected] Subject: Re: axis2 deployment and configuration 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
