Okay, I've been looking through the templates, and have a question:

Should lines 1315:1332 in :
<xsl:if test="not(@type)">
<xsl:for-each select="property">
<xsl:if test="position()=1">
        if( parent == NULL)
        {
                current_element = axiom_element_create (env, parent,
"<xsl:value-of select="$originalName"/>", ns1,
&amp;current_node);
                axiom_element_set_namespace( current_element, env,
ns1, current_node);
                <xsl:if test="@child-nsuri and @child-nsprefix and
@ours">
                ns1 = axiom_namespace_create (env,
                        "<xsl:value-of select="@child-nsuri"/>",
                        "<xsl:value-of select="@child-nsprefix"/>");
axiom_element_declare_namespace( current_element,
                        env, current_node, ns1);    
            </xsl:if>
                parent = current_node;
        }
</xsl:if>
</xsl:for-each>
</xsl:if>

Actually be (something similar to):
if( parent == NULL)
        {
                current_element = axiom_element_create (env, parent,
"<xsl:value-of select="$originalName"/>", ns1,
&amp;current_node);
                axiom_element_set_namespace( current_element, env,
ns1, current_node);
                <xsl:if test="@child-nsuri and @child-nsprefix and
@ours">
                ns1 = axiom_namespace_create (env,
                        "<xsl:value-of select="@child-nsuri"/>",
                        "<xsl:value-of select="@child-nsprefix"/>");
axiom_element_declare_namespace( current_element,
                        env, current_node, ns1);    
            </xsl:if>
                parent = current_node;
        }
<xsl:if test="not(@type)">
<xsl:for-each select="property">
<xsl:if test="position()=1">
        if( parent == NULL)
        {
                current_element = axiom_element_create (env, parent,
"<xsl:value-of select="$originalName"/>", ns1,
&amp;current_node);
                axiom_element_set_namespace( current_element, env,
ns1, current_node);
                <xsl:if test="@child-nsuri and @child-nsprefix and
@ours">
                ns1 = axiom_namespace_create (env,
                        "<xsl:value-of select="@child-nsuri"/>",
                        "<xsl:value-of select="@child-nsprefix"/>");
axiom_element_declare_namespace( current_element,
                        env, current_node, ns1);    
            </xsl:if>
                parent = current_node;
        }
</xsl:if>
</xsl:for-each>
</xsl:if>

I.e. One unconditional element & namespace creation, followed by element
and namespaces for all the children?

Unless there's a specific property for the root node, which I can't
find, so you could do something like:
<xsl:for-each select="root and property"> (pseudo)

Any suggestions?

-Jamie

> -----Original Message-----
> From: Jamie Lyon [mailto:[EMAIL PROTECTED]
> Sent: 01 August 2007 11:44
> To: Apache AXIS C Developers List
> Subject: [WSDL2Code/C] Embedding soap operations in body (with adb
> databinding)
> 
>  <<DataService.wsdl>> Hi,
> 
> I'm having some problems with the WSDL2C tool. I'm running the latest
> nightly build (Aug 1st). All of the methods below were generated using
> adb databinding from the attached wsdl file using the following
command:
> wsdl2c.sh -uri DataService.wsdl -g -f -d adb -u -o output
> Where wsdl2c.sh is just wsdl2java.sh with the line:
> sh `dirname $0`/axis2.sh org.apache.axis2.wsdl.WSDL2Java $*
> replaced with:
> sh `dirname $0`/axis2.sh org.apache.axis2.wsdl.WSDL2C $*
> 
> There are several small problems:
> 1) When compiling the wsdl file I attached, I get a re-defined warning
> on adb_GetResourceProperty_get_qname in adb_GetResourceProperty.c.
> 2) A known bug is not yet fixed in the nightly, though a fix is known
-
> basically rampart/c does not work with autogenerated stubs with adb
> databinding:
>          Problem:
>
http://www.nabble.com/rampart-c-not-working-with-stubs-generated-using-w
> sdl2c-t4125131.html
>       Solution:
>
http://www.nabble.com/Re%3A-rampart-c-not-working-with-stubs-generated-u
> sing-wsdl2c-p11760941.html
> These are all fixable via manual edits in a small amount of time
> however, and are really just minor inconveniences.
> 
> The last problem however I cannot find a fix for:
> When a request contains no parameters, no soap operation is defined in
> the body, only the SOAPAction in the HTTP header is generated. If you
> generate the attached wsdl file, you will get the following operation
> (and more):
> getResources - this has no parameters, and as such the soap body looks
> like:
> <soapenv:Body wsu:Id="SigID-b5477fd2-3f48-1dc1"
>
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssec
> urity-utility-1.0.xsd">
> </soapenv:Body>
> When it should look like:
> <soapenv:Body wsu:Id="SigID-b5477fd2-3f48-1dc1"
>
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssec
> urity-utility-1.0.xsd">
> <getResources></getResources>
> </soapenv:Body>
> 
> Looking at the source code for this operation
> (adb_getResources_serialize in adb_getResources.c) you can see the
> reason for it, all the code for generating the root element, such as
> that found in the operation 'save', is not included:
> If( parent == NULL )
> {
>       current_element = axiom_element_create (env, parent, "save", ns1
> , &current_node);
> ...
> }
> 
> Is there an easy solution to fix this? I shall look into the wsdl2code
c
> templates myself, but if anyone is aware of a known solution, or can
fix
> it easily that would be much appreciated.
> 
> Cheers,
> Jamie

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to