I believe I do understand the issue and I just want to drop a quick question here.
I would like to know to what extend muse *uses* functionality provided by the axis2 deployment. Apparently it uses its own sender for outgoing messages, I don't think that this is a big issue. What I consider more important is that it can leverage specific axis2 modules used for message processing, such as the security module, to change the payload of the application message. So basically the question is "Can I use rampart to protect my muse service". From your previous email I assume this would be the case, correct? Has anyone done any experiments with this already? -----Original Message----- From: Daniel Jemiolo [mailto:[EMAIL PROTECTED] Sent: 30 March 2007 14:37 To: [email protected] Subject: Re: AW: axis2 deployment and configuration The trouble is that while Muse *runs* on Axis2, it does not *depend* on Axis2 - it is abstracted away from any particular SOAP engine (this is how we run the same code on mini/J2ME). An interesting JIRA issue might be an alternate implementation of the SoapClient interface that sent messages by delegating to whatever Axis2 API was necessary. You could then instantiate this SoapClient instead of the default one using the *Client class constructor (there is a constructor that takes a third parameter, the SoapClient to use). Dan "Beil, Matthias" <[EMAIL PROTECTED]> wrote on 03/30/2007 02:52:48 AM: > 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] > --------------------------------------------------------------------- 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]
