Hi Sérgio,
I also checked the generated code for WSDL2Java code and didn't find
anything related to output headers, May be I have missed something.
Anyway Axis2/Java too doesn't have a getHeader function in
ServiceClient. so it looks like not that straight forward. I too need
some axis2 experts thoughts on this?
Thanks
Dimuthu
On Fri, Mar 28, 2008 at 2:26 AM, Sérgio Gomes <[EMAIL PROTECTED]> wrote:
> Hi Dimuthu,
>
> I looked around in the source code quite a bit and wasn't able to find
> any way to get the envelope node that I required to create a header
> node. I'd have to get the message context somehow, which I don't think
> makes sense from axis2_svc_client 's point of view (since presumably
> one svc_client can emit many messages and thus have many message
> contexts in its lifetime). That would indeed coincide with your
> analysis that an API change would be needed. Of course, my analysis
> may be completely wrong, since I'm an outsider to the code and I was
> just poking around trying to scratch my itch :)
>
> Anyway, regarding your solution for the code generator, that looks
> like what's needed, that is, assuming that adb_input_header_t and
> adb_out_header_t would be the ADB models for whatever objects we were
> trying to set in the header (say, a simpleType with a "string"
> restriction). I'll give it a try tomorrow to adapt that tentative code
> to the code I had generated and see how it goes.
>
> Cheers,
> Sérgio
>
> ---
>
>
>
> On Thu, Mar 27, 2008 at 6:31 PM, Dimuthu Gamage <[EMAIL PROTECTED]> wrote:
> > Hi Sérgio,
> >
> > Hm, Actually you will face a problem if you try to add headers
> > manually. Because currently axis2_svc_client doesnt have a way to get
> > response headers. So there is an API change needed. Please correct me
> > if I m wrong on this.
> >
> > I was thinking implement the thing in this way. Say you have a
> > operation so that it has one input message, one input header one
> > output header, I m assuming there is a function called
> > get_response_header.
> >
> >
> > axis2_stub_op_exampleOp(axis2_stub_t *stub, adb_input_t *input,
> > adb_input_header_t *header_in, adb_out_header_t **header_out)
> > {
> > /* the following part should be added before send_receive call */
> > axiom_node_t * header1;
> > header1 = adb_input_header_serialize(header_in, env, NULL, NULL,
> > AXIS2_TRUE, NULL, NULL);
> > svc_client = axis2_stub_get_svc_client(stub, env); //this is already
> there
> >
> > axis2_svc_client_add_header(svc_client, env, header1);
> >
> >
> > /* this is after send recieve */
> > axutil_array_list_t * headers =
> axis2_svc_client_get_response_headers(..);
> > header_node = (adb_out_header_t *) axutil_array_list_get(headers, env,
> 0);
> >
> > *out_header = adb_output_header_create(env);
> > adb_output_header_deserialize(*out_header, env, &header_node, NULL,
> > AXIS2_FALSE ) ;
> >
> > }
> >
> > Anyway you won't be able to handle that manually since currently axis2
> > api doesn't have a function to get output headers :(. I will raise a
> > JIRA on this.
> >
> > Thanks
> > Dimuthu
> >
> >
> >
> >
> > On Thu, Mar 27, 2008 at 3:56 PM, Sérgio Gomes <[EMAIL PROTECTED]> wrote:
> > > Hi Dimuthu,
> > >
> > > Thanks for the update, let me know if you'd like me to do some testing
> > > once it's done.
> > >
> > > In the meantime, is there any way I can overcome this, by, say,
> > > providing the header part of the XML myself?
> > >
> > > Cheers,
> > > Sérgio
> > >
> > > ---
> > >
> > >
> > > On Thu, Mar 27, 2008 at 4:22 AM, Dimuthu Gamage <[EMAIL PROTECTED]>
> wrote:
> > > > Hi Sérgio,
> > > > Currently WSDL2C doesn't support picking headers from the wsdl. The
> > > > classes are generated because it support in wsdl2java tool. Anyway
> I m
> > > > right now working in that and the class name problem. Hope I can fix
> > > > this for the client side within this week
> > > >
> > > > Thanks
> > > > Dimuthu
> > > >
> > > >
> > > >
> > > > On Thu, Mar 27, 2008 at 2:30 AM, Sérgio Gomes <[EMAIL PROTECTED]>
> wrote:
> > > > > Hello again,
> > > > >
> > > > > When sending my SOAP messages, I noticed that the headers were
> always
> > > > > empty, even though the WSDL2C tool generated support for the
> header
> > > > > fields:
> > > > >
> > > > > adb_getAllAdWordsCampaignsResponse_t*
> > > > > axis2_stub_op_CampaignService_getAllAdWordsCampaigns(
> > > > > axis2_stub_t *stub, const axutil_env_t *env,
> > > > >
> > > > > adb_getAllAdWordsCampaigns_t* _getAllAdWordsCampaigns,
> > > > >
> > > > > adb_useragent_t* _useragent22,
> > > > >
> > > > > adb_password_t* _password23,
> > > > >
> adb_email_t* _email24,
> > > > >
> > > > > adb_clientEmail_t* _clientEmail25,
> > > > >
> > > > > adb_clientCustomerId_t* _clientCustomerId26,
> > > > >
> > > > > adb_developerToken_t* _developerToken27,
> > > > >
> > > > > adb_applicationToken_t* _applicationToken28);
> > > > >
> > > > > (There is also a bug that prevents the correct generation of the
> class
> > > > > names, but it has already been confirmed and will be fixed,
> according
> > > > > to the reply I received when I posted that issue)
> > > > > (WSDL can be found at
> > > > > https://adwords.google.com/api/adwords/v11/CampaignService?wsdl )
> > > > >
> > > > > As you can see, the function header has all the items that should
> > > > > appear on the SOAP header (useragent, password, etc), yet when I
> > > > > analyzed the generated .c file, I noticed that these parameters
> were
> > > > > being used nowhere, and thus the header would always be empty.
> > > > >
> > > > > Any tips on this issue? Also, is there an alternate way to set
> the
> > > > > outgoing SOAP header, so that I can work around the issue?
> > > > >
> > > > >
> > > > > Thanks,
> > > > > Sérgio
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > 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]
