Re: Header parameters being ignored
Hi Dimuthu,
The updated code fixed the problem, once I applied it to several adb
classes. It now doesn't get stuck in an infinite loop anymore... but
I get a different error this time, which looks unrelated. I'll post it
in a new thread.
Thanks for the help!
Sérgio
---
On Mon, Mar 31, 2008 at 8:11 PM, Dimuthu Gamage [EMAIL PROTECTED] wrote:
On Mon, Mar 31, 2008 at 11:16 PM, Sérgio Gomes [EMAIL PROTECTED] wrote:
Hi Dimuthu,
I'm using libxml2 (at least I think so, that's the default, right)?
It is planned to put 'Guththila' as the default parser for future
releases. If you are using Axis2/C 1.3.0 you may try with guththila
too.
Thanks
Dimuthu
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
Re: Header parameters being ignored
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, which causes
the deserialization to be stuck in an infinite loop. 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
Re: Header parameters being ignored
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,
Re: Header parameters being ignored
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
Re: Header parameters being ignored
Yea that s a bug,
Changing that code to the following one will work.
if(axiom_node_get_node_type(current_node, env) != AXIOM_ELEMENT)
{
current_node
=axiom_node_get_next_sibling(current_node, env);
is_early_node_valid = AXIS2_FALSE;
continue;
}
Obviously we have some missing test cases. specially with messages
that has lot of spaces.
Thanks for pointing this out.
Thanks
Dimuthu
On Mon, Mar 31, 2008 at 11:16 PM, Sérgio Gomes [EMAIL PROTECTED] wrote:
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
Re: Header parameters being ignored
On Mon, Mar 31, 2008 at 11:16 PM, Sérgio Gomes [EMAIL PROTECTED] wrote:
Hi Dimuthu,
I'm using libxml2 (at least I think so, that's the default, right)?
It is planned to put 'Guththila' as the default parser for future
releases. If you are using Axis2/C 1.3.0 you may try with guththila
too.
Thanks
Dimuthu
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
Re: Header parameters being ignored
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
Re: Header parameters being ignored
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]
Re: Header parameters being ignored
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
Header parameters being ignored
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]
