The Element[] parameter should have been added to your methods - are you
saying this didn't happen? I just tried this, and I found that wsdl2java
adds the Element[] parameter to both methods and constructors (adding it
to constructors is a bug, albeit a harmless bug for now). I'd like to make
sure you can invoke the operations you defined w/o having to call the
generic invoke() yourself.
Dan
"Beil, Matthias" <[EMAIL PROTECTED]> wrote on 03/29/2007 09:30:16 AM:
> Hi,
>
> The suggestion from Dan to use wsdl2java -wsdl MyResource.wsdl -headers
> produced something like this:
>
> public class WsnOssjPortProxy extends NotificationProducerClient
implements WsnOssjPort
> {
> public WsnOssjPortProxy(EndpointReference param0, Element[]
customHeaders) {
> super(param0);
> }
> }
>
> Meaning the customHeaders where added but I could not set them to the
super class :-(
>
> So I extended NotificationProducerClient and could then call the
>
> final Element responseXML = this.invoke(WsnConstants.GET_CURRENT_URI,
get.
> toXML(), extraHeaders);
>
> method, where I could use the extraHeaders.
>
> I filled the extraHeaders with the WS-Security element which I created
with this:
>
> package com.ascom.ossj.wsn.producer.test;
>
> import org.apache.muse.util.xml.XmlUtils;
> import org.apache.muse.ws.addressing.soap.SoapConstants;
> import org.apache.ws.security.WSConstants;
> import org.apache.ws.security.message.WSSecHeader;
> import org.apache.ws.security.message.WSSecUsernameToken;
>
> import org.w3c.dom.Document;
> import org.w3c.dom.Element;
>
> public final class Wss4jTestClient {
>
> public static void main(final String[] args) {
>
> // create doc element
> Document doc = XmlUtils.createDocument();
> Element soapXML = XmlUtils.createElement(doc,
SoapConstants.ENVELOPE_QNAME);
>
> // add child element, otherwise it doesn't go
> doc.appendChild(soapXML);
>
> // get security header
> WSSecHeader secHeader = new WSSecHeader();
> secHeader.insertSecurityHeader(doc);
>
> // get user token
> WSSecUsernameToken sec = new WSSecUsernameToken();
> sec.addCreated();
> sec.addNonce();
> sec.setPasswordType(WSConstants.PASSWORD_DIGEST);
> sec.setUserInfo("test", "test");
>
> // create usertoken element
> sec.prepare(doc);
>
> // add usertoken element to header
> sec.prependToHeader(secHeader);
>
> // get security element
> Element secElement = secHeader.insertSecurityHeader(doc);
>
> System.out.println(XmlUtils.toString(secElement));
> System.out.println(XmlUtils.toString(soapXML));
> }
> }
>
> Finally I had to extend on the server side the classes
> NotificationConsumerClient and SimpleSubscriptionManager to have again
access to the
>
> this.invoke(WsnConstants.NOTIFY_URI, notify, this.getSecurityHeader());
>
> method.
>
> With this modification I got WS-Security working with Muse. Now the
notify
> message has also a WSSE header when send to the consumer.
>
> Still have to find out why the SoapFault is not returned correctly. But
this
> is a matter of setting up Axis2 with rampart and not of Muse ;-)
>
> Best regards,
> Matthias
>
>
> -----Ursprüngliche Nachricht-----
> Von: Beil, Matthias [mailto:[EMAIL PROTECTED]
> Gesendet: Mittwoch, 28. März 2007 09:16
> An: [email protected]
> Betreff: AW: AW: Setting ConfigurationContext for
NotificationProducerClient
>
> Hi Dan,
>
> thx for the reply.
>
> I had a look at the source code and saw that the client is using
> HttpURLConnection to output the message. So the client does not use
axis2 to
> send the messages, meaning I will try to use WSS4J directly.
>
> What I also found out, is that this is also valid for the notify method
on the
> server!!! I just wanted to test the notify message between the producer
web
> service and the consumer web service, but there wasn't any security
header
> send. The source code showed me that the "notify" method at the web
service
> producer is also implemented as a direct http call. This means that also
here
> I must provide some headers.
>
> I will see how to manage that.
>
> Best regards,
> Matthias
>
>
> -----Ursprüngliche Nachricht-----
> Von: Daniel Jemiolo [mailto:[EMAIL PROTECTED]
> Gesendet: Dienstag, 27. März 2007 20:19
> An: [email protected]
> Betreff: Re: AW: Setting ConfigurationContext for
NotificationProducerClient
>
> I'm guessing the clients that Axis's wsdl2java generates look for this
> file/repository automatically, which is why following the steps in the
> article still doesn't work. Right now the Muse client API has a way to
> generate methods so that you can add custom SOAP headers to your
request.
> If you do:
>
> wsdl2java -wsdl MyResource.wsdl -headers
>
> It will add to each method signature an additional parameter, Element[]
> customHeaders, which you can use to pass things like WS-Security values.
> Would it be possible to use the WSS4J API directly to add the headers
you
> need for the request?
>
> Dan
>
>
>
> "Beil, Matthias" <[EMAIL PROTECTED]> wrote on 03/27/2007 10:55:18 AM:
>
> > Hi Dan,
> >
> > thx for the reply.
> >
> > Yes, the ConfigurationContext is part of Axis2 client API. What I've
> found out
> > so far for the integration of rampart is that I need on the client
side
> an
> > axis2.xml file and also a service.xml file. In other words this means
> that I
> > have to set up a client side repository.
> >
> > I found following URL http://wso2.org/library/585 for "Different Ways
of
>
> > Creating a ConfigurationContext in Axis2". I tried to set the
properties
> -
> > Daxis2.xml and -Daxis2.repo but that seems not to be enough.
> >
> > So I think what I need is a way to make the Muse classes
> ConfigurationContext
> > aware, or at least set the Axis environment with a configuration
context
> so
> > that the client repository is used. As rampart is a Axis2 handler the
> server
> > call must go through Axis2 handlers.
> >
> > Setting up the server side was easy, now the server rejects each
> incoming
> > message as there is no security header ;-)
> >
> > Best regards,
> > Matthias
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Daniel Jemiolo [mailto:[EMAIL PROTECTED]
> > Gesendet: Dienstag, 27. März 2007 16:20
> > An: [email protected]
> > Betreff: Re: Setting ConfigurationContext for
NotificationProducerClient
> >
> > Is the client's ConfigurationContext part of the Axis2 client API? The
> > generated clients aren't Axis2-based clients, so I'm not sure how
you'd
> > add that in. Perhaps you can tell us exactly what is involved in
making
> > the client aware of Rampart and we can propose a way to integrate the
> > Axis2 API usage with the Muse client class.
> >
> > Dan
> >
> >
> >
> > "Beil, Matthias" <[EMAIL PROTECTED]> wrote on 03/26/2007 12:13:30 PM:
> >
> > > Hi,
> > >
> > >
> > >
> > > is there a way in Muse to set the ConfigurationContext for the
client?
> > >
> > >
> > >
> > > I need to set the ConfigurationContext in the client to make the
> client
> > > aware of the rampart initialization. As I don't want to start to
write
> a
> > > complete new client I would like to continue to use the Muse
> convenient
> > > NotificationProducerClient class. But I can't find a way how to set
> the
> > > ConfigurationContext.
> > >
> > >
> > >
> > > Just setting the -Daxis2.xml and -Daxis2.repo variables don't change
> > > anything.
> > >
> > >
> > >
> > > Mit freundlichen Gruessen / With kind regards
> > >
> > > Matthias Beil
> > >
> >
> >
> > ---------------------------------------------------------------------
> > 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]
