I recall a number of other users having success setting up the WS-Security module in Axis2 (w/ Muse). In fact, I think Matthias (the other participant in this thread) is one of them. I don't think you'll run into any issues, but if you do, please report them so we can fix Muse and allow the WS-Security module to work as expected.
Dan <[EMAIL PROTECTED]> wrote on 03/30/2007 09:51:05 AM: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
