Hi Dan,
I tried now several combinations, but could not succeed to have the methods
generated. I downloaded the latest Muse 2.2.0 bin and src package yesterday.
I'm using the following ant target from Eclipse 3.2
<target name="generate-muse-client">
<!-- make sure to have a clean deployment -->
<delete dir="${target.muse.client.dir}" />
<mkdir dir="${target.muse.client.dir}" />
<!-- make sure to have $MUSE_HOME or %MUSE_HOME% set -->
<!-- and see that wsdl2java.bat in $MUSE_HOME/bin is on the path!!! -->
<exec executable="wsdl2java.bat">
<arg value="-proxy" />
<arg value="-wsdl" />
<arg file="${src.resources.dir}/wsdl/wsn-ossj-producer.wsdl" />
<arg value="-output" />
<arg file="${target.muse.client.dir}" />
<arg value="-overwrite" />
<arg value="-headers" />
</exec>
</target>
My resource in the WSDL file looks like this:
<xsd:element name="ApplicationDN" type="xsd:string" />
<xsd:element name="JmsProducer">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="wsn-ossj:ApplicationDN" />
<xsd:element ref="wsnt:FixedTopicSet" />
<xsd:element ref="wst:TopicSet" minOccurs="0" />
<xsd:element ref="wsnt:TopicExpression" minOccurs="0" maxOccurs="unbounded"
/>
<xsd:element ref="wsnt:TopicExpressionDialect" minOccurs="0"
maxOccurs="unbounded" />
<xsd:element ref="wsrf-rl:CurrentTime" />
<xsd:element ref="wsrf-rl:TerminationTime" />
<xsd:element ref="wsrf-rp:QueryExpressionDialect" minOccurs="0"
maxOccurs="unbounded" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
For me the solution I've found is okay.
THX in each case for helping. It's good to known that somebody helps in case of
trouble. Makes using Muse easier.
Best regards,
Matthias
-----Ursprüngliche Nachricht-----
Von: Daniel Jemiolo [mailto:[EMAIL PROTECTED]
Gesendet: Donnerstag, 29. März 2007 16:08
An: [email protected]
Betreff: Re: AW: AW: Setting ConfigurationContext for NotificationProducerClient
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
