You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Jason Harrop <jh...@gmail.com> on 2007/11/27 05:09:42 UTC

Microsoft interop gotcha - WSDL with minOccurs="0", type="xs:long"

For my bottom up web service, Axis 1.4 generated, in part:

   <element name="getTransforms">
    <complexType>
     <sequence>
      <element name="in0" type="xsd:string"/>
      <element name="in1" type="xsd:long"/>
     </sequence>
    </complexType>
   </element>

Axis 2 1.3 generates:

           <xs:element name="getTransforms">
                <xs:complexType>
                    <xs:sequence>
                        <xs:element minOccurs="0" name="docID"
nillable="true" type="xs:string"/>
                        <xs:element minOccurs="0"
name="firstSequenceNumber" type="xs:long"/>
                    </xs:sequence>
                </xs:complexType>
            </xs:element>

This new form of WSDL causes source code auto-generated by
Microsoft.VSDesigner, Version 2.0.50727.312.
MS Web Services Client Protocol 2.0.50727.312
System.Web.Services, 2.0.50727.312

to include an unwanted third parameter named firstSequenceNumberSpecified:

        public string[] getTransforms(
           [System.Xml.Serialization.XmlElementAttribute(IsNullable=true)]
string docID,
           long firstSequenceNumber,
           [System.Xml.Serialization.XmlIgnoreAttribute()] bool
firstSequenceNumberSpecified)

Now in Axis 2's WSDL, everything has minOccurs="0".  That in itself is
not enough to trigger the errant behaviour in the Windows client.

The errant behaviour is triggered by the type xs:long, but not for
example, by xs:string or xs:anyType.  I also saw a post somewhere from
someone complaining about errant behaviour triggered by type boolean -
I have no booleans in my WSDL though.

I see org.apache.axis2.dataretrieval.WSDLDataLocator calls
org.apache.axis2.description.AxisService2WSDL11 which in turn uses
org.apache.ws.commons.schema.XmlSchema to serialise itself.

But a quick look at
http://svn.apache.org/viewvc/webservices/commons/trunk/modules/XmlSchema/src/main/java/org/apache/ws/commons/schema/XmlSchema.java?view=markup
suggests there is no easy way to tell Axis 2 not to generate
minOccurs="0"?

For the moment, I'm manually deleting minOccurs="0", and feeding the
resulting WSDL file to Visual Studio to generate the client.

Has anybody else experienced this?  What is the simplest workaround to
avoid editing the WSDL file manually?

thanks

Jason

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org

RE: Microsoft interop gotcha - WSDL with minOccurs="0", type="xs:long"

Posted by si...@bt.com.
Nice explanation Mauro!

Your explanation shows the value of a good defined WSDL spec. This is
the case because the WSDL is used to specify the contract. In one of my
earlier messages I explained and linked to some information about strong
typed WSDL files.

Therefore I think the approach to use java2wsdl is wrong. Because you're
first writing an implementation and then build a contract around it. You
should do that in reverse order and thus start with specifying the WSDL
and generate code from that (well-defined) contract. This also abstracts
from any implementation language which adds even more value imho.

This doesn't solve your problem but I hope it gives you a view from
another perspective.

Just my two cents...

Regards,
Sietse

-----Original Message-----
From: Mauro Molinari [mailto:mauro.molinari@cardinis.com] 
Sent: 27 November 2007 08:07
To: axis-user@ws.apache.org
Subject: Re: Microsoft interop gotcha - WSDL with minOccurs="0",
type="xs:long"

Hi Jason,
the first "problem" is that .NET translates optional WSDL elements
(i.e.: those with minOccurs="0" and maxOccurs="1" - please note
maxOccurs="1" is the default, if not specified) with a second boolean
parameter like "xxxSpecified" that states if the previous parameter has
been specified or not.
This is because .NET 1.1 was not able to specify null for primitive
types (like int, long, etc.; string is an exception), so the convention
is the following:
- <any value>, xxxSpecified = false => means "null"
- <a value>, xxxSpecified = true => means "value"

.NET 2.0 behaves the same, probably because of some kind of
retro-compatibility.

However, I would not consider that a big problem. If you are sure your
parameters cannot be null, you can manually delete all minOccurs="0";
otherwise, you may remove minOccurs="0" and substitute with
nillable="true", but be careful: as I said before, .NET 1.1 cannot
specify null for primitive types, so a .NET 1.1 client would not be able
to specify null for, say, an int parameter marked as nillable="true". 
.NET 2.0 does not have this problem.

The second (and real) problem is that if you are writing your web
services bottom up, Axis2 Java2WSDL always generates minOccurs="0" and,
in some circumstances, this can lead to bigger problems that the one you
described. Please also have a look to my bug report:
http://issues.apache.org/jira/browse/AXIS2-3300

Cheers.

--
Mauro Molinari
Software Developer
mauro.molinari@cardinis.com

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org

Re: Microsoft interop gotcha - WSDL with minOccurs="0", type="xs:long"

Posted by Mauro Molinari <ma...@cardinis.com>.
Hi Jason,
the first "problem" is that .NET translates optional WSDL elements 
(i.e.: those with minOccurs="0" and maxOccurs="1" - please note 
maxOccurs="1" is the default, if not specified) with a second boolean 
parameter like "xxxSpecified" that states if the previous parameter has 
been specified or not.
This is because .NET 1.1 was not able to specify null for primitive 
types (like int, long, etc.; string is an exception), so the convention 
is the following:
- <any value>, xxxSpecified = false => means "null"
- <a value>, xxxSpecified = true => means "value"

.NET 2.0 behaves the same, probably because of some kind of 
retro-compatibility.

However, I would not consider that a big problem. If you are sure your 
parameters cannot be null, you can manually delete all minOccurs="0"; 
otherwise, you may remove minOccurs="0" and substitute with 
nillable="true", but be careful: as I said before, .NET 1.1 cannot 
specify null for primitive types, so a .NET 1.1 client would not be able 
to specify null for, say, an int parameter marked as nillable="true". 
.NET 2.0 does not have this problem.

The second (and real) problem is that if you are writing your web 
services bottom up, Axis2 Java2WSDL always generates minOccurs="0" and, 
in some circumstances, this can lead to bigger problems that the one you 
described. Please also have a look to my bug report:
http://issues.apache.org/jira/browse/AXIS2-3300

Cheers.

-- 
Mauro Molinari
Software Developer
mauro.molinari@cardinis.com

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org