Right, it actually makes sense to me now, but go figure when I apply this to
the WSDL of the service I want to call, the extra parameter for the header
is somehow disappearing.  I'm in a debugging session with CXF right now
attempting to find out at what point it loses it.. so far it's retaining
that parameter.. I'll let you all know when I isolate the code that seems to
be causing my problem, which should be shortly.

On 9/11/07, Ulhas Bhole <[EMAIL PROTECTED]> wrote:
>
> Hi Ryan,
>
> The problem you are seeing might be because he Header processing is
> getting the expectation of header from Service model generated from
> WSDL. However, the actual header insertion is not happening because the
> generated method signature is not containing the header parameter.
>
> You can take a look at the system tests related to SOAP Headers.
>
> Regards,
>
> Ulhas Bhole
>
> Ryan Moquin wrote:
> > I was able to get this to work now with my scaled down test wsdl, but
> not
> > the full wsdl that I need it to work with, I'll do my best to help you
> with
> > what I know about this.
> >
> > I did notice your thread that sounded familiar.  Apparently if you add
> the
> > -exsh true parameter to wsdl2java, you'll end up with an extra parameter
> in
> > your method signature of your port class implementation.  This extra
> > parameter is the header specified in your wsdl.  If you don't add the
> exsh,
> > you won't get the parameter and end up with an IndexOutOfBounds error
> > because cxf is expecting the header.  I'm not sure why cxf would assume
> you
> > are including the header if you never generated your classes to accept
> one.
> >
> > I know my classes weren't setting the header because when I did a find
> > usages on my AuthCredentials class, which is put in the header, it
> wasn't
> > used anywhere.  Actually the generated client code, didn't even actually
> > make calls to invoke the webservice.  It would just create a response
> object
> > set to null and return it, and that was it.  So the generated client in
> my
> > opinion was useless anyhow.
> >
> > On 9/11/07, Gamble, Wesley (WG10) <[EMAIL PROTECTED]> wrote:
> >
> >> Ryan,
> >>
> >> "All I
> >> get currently is an IndexOutOfBoundsException when CXF tries to create
> >> the
> >> header of the SOAP message to send,"
> >>
> >> sounds suspiciously like my problem (thread: "Can't get at SOAP error
> >> from Web service...").  I'm getting an index out of bounds exception as
> >> well on the header processing.
> >>
> >> What is the -exsh flag on wsdl2java supposed to do for you?  What does
> >> "Enables or disables processing of extended soap header message
> >> binding." mean?  How would I know the difference between a regular and
> >> an extended soap header message?
> >>
> >> How do you know that "the generated client classes do NOT set the
> header
> >> that is specified in the binding"?
> >>
> >> Wes
> >>
> >> -----Original Message-----
> >> From: Ryan Moquin [mailto:[EMAIL PROTECTED]
> >> Sent: Tuesday, September 11, 2007 9:36 AM
> >> To: [email protected]
> >> Subject: Adding headers to soap request
> >>
> >> I'm writing this as a new message, but I'm hoping that it's answer will
> >> solve my other issue I'm writing about.  I think I'm having having
> >> trouble
> >> understanding how to add a header to my request using cxf.  In short, I
> >> have
> >> a WSDL that defines this element:
> >>
> >> <s:element name="AuthCredentials" type="tns:AuthCredentials"/>
> >>       <s:complexType name="AuthCredentials">
> >>         <s:sequence>
> >>           <s:element minOccurs="0" maxOccurs="1" name="username"
> >> type="s:string"/>
> >>           <s:element minOccurs="0" maxOccurs="1" name="password"
> >> type="s:string"/>
> >>         </s:sequence>
> >>       </s:complexType>
> >>
> >> and then defines a binding that uses it:
> >>
> >> <wsdl:operation name="sendNotification">
> >>       <soap:operation
> >> soapAction="urn://testnotification/sendNotification"
> >> style="document"/>
> >>       <wsdl:input>
> >>         <soap:body use="literal"/>
> >>         <soap:header message="tns:sendNotificationAuthCredentials"
> >> part="AuthCredentials" use="literal"/>
> >>       </wsdl:input>
> >>       <wsdl:output>
> >>         <soap:body use="literal"/>
> >>       </wsdl:output>
> >>     </wsdl:operation>
> >>
> >> When I run this WSDL through wsdltojava using -exsh true, the generated
> >> client classes do NOT set the header that is specified in the binding,
> >> which
> >> is what I thought that the -exsh is supposed to do for you.  So
> >> basically,
> >> I'm trying to figure out how I would add this element to my request.
> >> Here
> >> is what WSDL to java generated, how do I add the AuthCredentials
> element
> >> to
> >> the messagingPort class so that my request will go through with it? All
> >> I
> >> get currently is an IndexOutOfBoundsException when CXF tries to create
> >> the
> >> header of the SOAP message to send, I'm guessing because I don't know
> >> how to
> >> add the header.  I looked at the CXF examples on it, but it doesn't
> look
> >> like the headers are being added as a header:
> >>
> >> public void sendNotification() {
> >>     NotificationService messagingService = null;
> >>     NotificationServicePort messagingPort = null;
> >>
> >>     messagingService = new NotificationService(wsdl, SERVICE_NAME);
> >>     messagingPort = messagingService.getNotificationServicePort();
> >>
> >>     System.out.println("Invoking sendNotification...");
> >>     java.lang.String _sendNotification_parametersVal = "";
> >>     javax.xml.ws.Holder<java.lang.String> _sendNotification_parameters
> =
> >> new
> >> javax.xml.ws.Holder<java.lang.String>(_sendNotification_parametersVal);
> >>     messagingPort.sendNotification(_sendNotification_parameters);
> >>     System.out.println("sendNotification._sendNotification_parameters="
> >> +
> >> _sendNotification_parameters.value);
> >>   }
> >>
> >>
> >
> >
>
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
>

Reply via email to