Hi Dimuthu,
I'm using libxml2 (at least I think so, that's the default, right)?
As for the infinite loop, it looks like it's happening even if the XML
doesn't get truncated (on second thought, it might have been only the
debug output to the log that was being truncated in the first case, I
have no way of knowing). Anyway, here's the offending code, taken from
adb_getAllAdWordsCampaignsResponse.c (starts line 206):
for (i = 0, sequence_broken = 0, current_node = first_node;
!sequence_broken && current_node != NULL;)
{
if(axiom_node_get_node_type(current_node, env) != AXIOM_ELEMENT)
{
continue;
}
This is happening when first_node == current_node, so right on the
first step. The type seems to be AXIOM_TEXT, so it doesn't ever leave
the loop. Any thoughts?
Cheers,
Sérgio
---
On Mon, Mar 31, 2008 at 6:15 PM, Dimuthu Gamage <[EMAIL PROTECTED]> wrote:
> Hi Sérgio,
> Please see my inline comment.
>
>
> On Mon, Mar 31, 2008 at 8:17 PM, Sérgio Gomes <[EMAIL PROTECTED]> wrote:
> > Hi Dimuthu,
> >
>
> > Sorry that I couldn't answer immediately. After solving a few bugs I
> > had in my code, looks like your changes did the trick! The message is
> > serialized properly, sent over the line, and I'm getting the response
> > I expected :)
> >
> > Well, almost. Looks like the response is being truncated,
>
> AFAIK there is no maximum size of a message. we have tested with 5000
> entries ( i think around 50k) and it worked properly. I think that was
> with libxml2, if you are using guththila you may better change the
> parser and check.
>
>
> which causes
> > the deserialization to be stuck in an infinite loop.
>
> Whatever the response if deserialization stuck in a loop, it is a bug.
> Is that infinite loop occur in the deserialization logic or inside
> axiom?
>
> Thanks
> Dimuthu.
>
>
>
> Is there some
> > sort of maximum reply size (although this one wasn't too big, it was
> > around 6KB)?
> >
> > I'm going to try some other methods with smaller replies and see if
> > everything else works.
> >
> > Cheers,
> > Sérgio
> >
> > ---
> >
> >
> > On Sun, Mar 30, 2008 at 8:28 PM, Dimuthu Gamage <[EMAIL PROTECTED]> wrote:
> > > Hi Sérgio,
> > > I just resolved the issue on SOAP headers in both client and server
> > > side[1]. You can try the svn or just wait for the today nightly build.
> > > http://people.apache.org/dist/axis2/nightly.
> > >
> > > I attached the stub code for your wsdl here[1].
> > > You can get an idea on how to use the API with the test case
> > > attached[2]. It is more or less the same one that we discussed in this
> > > mail thread.
> > >
> > >
> > > [1] https://issues.apache.org/jira/browse/AXIS2C-833
> > > [2]
> https://issues.apache.org/jira/secure/attachment/12378904/case34_headers.zip
> > >
> > >
> > > Thanks
> > > Dimuthu
> > >
> > >
> > >
> > > On Fri, Mar 28, 2008 at 3:24 AM, Dimuthu Gamage <[EMAIL PROTECTED]>
> wrote:
> > > > 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]
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > 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]
