axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dimuthu Gamage <dimut...@gmail.com>
Subject Re: decoding xsd:hexBinary mapped to axiom_node_t*
Date Thu, 09 Jul 2009 01:55:37 GMT
Hi Patrick,
You are having an axiom_node_t* in place of the xsd:hexBinary because
there is no 'Axis2/C' native type mapped to the xsd type 'hexBinary'.
(i.e. for an example there are native type mapped to xsd:int and
xsd:string or even xsd:base64Binary : i.e. int, axis2_char_t*,
axutil_base64_something but not for hexBinary. axiom_node_t* is the
default type that adb can't handle will be mapped to.

Here is the code that you may writing,

axiom_node_t* authToken = adb_myAPIRequest_get_authToken(_myAPIRequest, env);
if (axiom_node_get_node_type(authToken, env) == AXIOM_TEXT) {
    axiom_text_t* authTokenTxt = axiom_node_get_data_element(authTOken, env);
    axis2_char_t* hexBinary =  axiom_text_get_value(authTokenTxt, env);

    // you have to first decode this data as it is still the hexBinary
you have, then your logic
}


Thanks
Dimuthu

On Wed, Jul 8, 2009 at 8:56 PM, Patrick Cosmo<pcosmo@incognito.com> wrote:
> I'm resubmitting this question because I submitted it incorrectly last time
> (it was submitted accidentally as a reply to an existing unrelated thread).
>
> It seems that if you use the xsd:hexBinary data type in an WSDL/XML file,
> the generated service
> side skeletons created by the WSDL2C tool maps it to axiom_node_t*. I'm
> having trouble understanding
> what exactly this "axiom_node_t*" contains in it, and how to decode this
> into either a hex
> string or an unsigned char array.
>
> In more detail:
>
> I have a WSDL that defines an element as follows:
>         <xsd:element name="authToken" type="xsd:hexBinary"></xsd:element>
>
> This element belongs to a message passed by WSDL. The WSDL2C tool generates
> this service side
> skeleton:
>
> adb_myAPIResponse_t* axis2_skel_MyServiceService_myAPI(const axutil_env_t
> *env,
>                                              
adb_myAPIRequest_t*
> _myAPIRequest )
> {
>         return (adb_myAPIResponse_t*) NULL;
> }
>
> Now, I can retrieve the authToken from the "_myAPIRequest" like this:
>
>         axiom_node_t* authToken =
> adb_myAPIRequest_get_authToken(_myAPIRequest, env);
>
> But the above method simply returns another axiom_node_t*. How do I get the
> hexBinary string
> out of this?
>
> I thought perhaps it just a sequence of chars (but isn't that what
> axis2_char_t* is for?).
> I took a look at the documentation I could find for traversing sequences,
> namely this (from
> http://ws.apache.org/axis2/c/docs/om_tutorial.html):
>
> axiom_children_iterator_t *children_iter = NULL;
> children_iter = axiom_element_get_children(om_ele, env, om_node);
> if(NULL != children_iter )
> {
>     while(axiom_children_iterator_has_next(children_iter, env))
>     {
>         axiom_node_t *node = NULL;
>         node = axiom_children_iterator_next(children_iter, env);
>         if(NULL != node)
>         {
>            if(axiom_node_get_node_type(node, env) == AXIOM_ELEMENT)
>            {
>                /* processing logic goes here */
>            }
>         }
>
>     }
> }
>
> But the part that confuses me about the above is what is "om_ele" and where
> did it come from,
> how do I get it? I was thinking perhaps I should iterate on "authToken",
> e.g.:
>
>         axiom_node_t* authToken =
> adb_myAPIRequest_get_authToken(_myAPIRequest, env);
>
>         axiom_children_iterator_t *children_iter = NULL;
>         children_iter = axiom_element_get_children(om_ele, env, om_authToken
> );
>
> But I still don't understand what "om_ele" is supposed to be or how I'm
> supposed to get it,
> or if I'm even on the right track here.
>
> Tried finding other examples or more documentation for
> "axiom_element_get_children" on the
> internet, but haven't had much luck . I also read the comments for it in the
> header file,
> but I didn't find them very enlightening.
>
> As for the API documentation (html) that comes with the download, it doesn't
> really say much
> either.
>
> Any help pointing me in the right direction is greatly appreciated.
>
> thanks,
> Patrick Cosmo
> Incognito Software Inc.
> Senior Software Design Engineer
> T: +1(604)678-2855
> F: +1(604)688-4339
> E: pcosmo@incognito.com
> www.incognito.com
>
>
>
>
>



-- 
Thanks,
Dimuthu Gamage

http://www.dimuthu.org
http://www.wso2.org

Mime
View raw message