Danushka Menikkumbura wrote:
Hi Devs,
There is a requirement to have support for custom HTTP headers in
Axis2/C. To do that we need to let the operation client know the
header details. One options is to set headers in service client
options and pass them on to operation client as the operat
If you need more control you can directly use operation client
bypassing service client. Then you can be smarter :)
It is imperative that I use the service client. So, it is not possible
to talk to operation client directly. :)
The other issue that was found when I was going through the
/axi
[
https://issues.apache.org/jira/browse/AXIS2C-1254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626893#action_12626893
]
Damitha Kumarage commented on AXIS2C-1254:
--
I had a look at your patch. Is not it
Hi Danushka,
override options come into play when we reuse operation client. Say
after sending some application messages you need to override some
options. Then you create new options struct and called svc client's
set_override_options. What happens is that existing options struct
becomes par
[
https://issues.apache.org/jira/browse/AXIS2C-1254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626897#action_12626897
]
Supun Kamburugamuva commented on AXIS2C-1254:
-
I think if a client specificall
override options come into play when we reuse operation client. Say
after sending some application messages you need to override some
options. Then you create new options struct and called svc client's
set_override_options. What happens is that existing options struct
becomes parent and your
Danushka Menikkumbura wrote:
Hi Devs,
There is a requirement to have support for custom HTTP headers in
Axis2/C. To do that we need to let the operation client know the
header details. One options is to set headers in service client
options and pass them on to operation client as the operat
So what is the option that you propose?
HTTP_HEADERS => array of (key => value) ?
An array of axis2_http_header_t*.
Danushka
--
Danushka Menikkumbura
Technical Lead, WSO2 Inc.
blog : http://danushka-menikkumbura.blogspot.com/
http://wso2.com/ - The Open Source SOA Company
---
Danushka Menikkumbura wrote:
So what is the option that you propose?
HTTP_HEADERS => array of (key => value) ?
An array of axis2_http_header_t*.
But then the user need to create axis2_http_header_t instances. Can we
use an string key value pair and covert them to the header type internally?
But then the user need to create axis2_http_header_t instances. Can we
use an string key value pair and covert them to the header type
internally?
No he doesn't have to. The interface call accepts the name and the value
and it in turn creates the header instance.
The interface call :
axis2
At what point will these headers get freed and who will be responsible
for freeing them?
Currently, I add http headers right before axis2_svc_client_send_receive
and free them right after axis2_svc_client_send_receive
Thanks
-Original Message-
From: Danushka Menikkumbura [mailto:[EMAIL P
Danushka Menikkumbura wrote:
But then the user need to create axis2_http_header_t instances. Can
we use an string key value pair and covert them to the header type
internally?
No he doesn't have to. The interface call accepts the name and the
value and it in turn creates the header instance
12 matches
Mail list logo
