[
https://issues.apache.org/jira/browse/AXIS2-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796149#action_12796149
]
Mauro Molinari commented on AXIS2-3300:
---------------------------------------
It sounds like a dirty workaround rather than a real solution.
First of all: a String parameter for instance (see my table (*) below) can be
marked as nillable=true (rather than minOccurs=0) because it is handled
correctly even by any .NET client generator.
Second: Java primitive types (ex.: int) could be translated into minOccurs=1
because they cannot be null, so they must be mandatory. This can fix the
problem with a POJO method that returns an int, for example.
The actual problem is with types like Integer or Date/Calendar, for which .NET
1.x clients can have issues if they are generated from a WSDL that specifies
nillable=true rather than minOccurs=0. Actually, if we talk about method input
parameters, it is safe to use minOccurs=0, but this then leads to the
unconfortable double-parameter pattern generated by the .NET WSDL to code
translator. However, if we talk about the method return parameters, minOccurs=0
still leads to the void return parameter type problem.
With .NET 2.0 on, there is no problem to use nillable=true for any kind of
parameter (even Integer, Date/Calendar, etc.).
So, I think the best way to solve this issue is to do the following:
1) for Java primitive types, always use minOccurs=1
2) otherwise, use nillable=true for parameters of type other than
Byte/Integer/Double/Date/Calendar/Boolean/BigDecimal/Float/Long/Short/org.apache.axis2.databinding.types.Time(*)
3) for parameters of type
Byte/Integer/Double/Date/Calendar/Boolean/BigDecimal/Float/Long/Short/org.apache.axis2.databinding.types.Time(*),
provide an option in services.xml (or by using an annotation directly in the
Java source code?) like the following:
dotNet1CompatibilityMode
Then apply the following:
- if dotNet1CompatibilityMode=false, then always use nillable=true
- if dotNet1CompatibilityMode=true, then use minOccurs=0 for method input
parameters, but use minOccurs=1 for method return types; I know the latter case
does not perfectly match the meaning of the Java code, but this to avoid the
.NET code generation problem. Of course this has to be well documented and the
Java developer must keep it in mind when he codes the actual service
implementation; a null return value might then be translated by the Axis2 stack
to a fault during runtime.
(*) This is the actual translation table of the simple types:
XML Schema | Java | C#
xsd:boolean | boolean - java.lang.Boolean | bool
xsd:byte | byte - java.lang.Byte | sbyte
xsd:date | java.util.Date | System.DateTime
xsd:dateTime | java.util.Calendar | System.DateTime
xsd:decimal | java.math.BigDecimal | decimal
xsd:double | double - java.lang.Double | System.Double (.NET 1.1) - double
(.NET 2.0)
xsd:float | float - java.lang.Float | float
xsd:int | int/java.lang.Integer | int
xsd:long | long - java.lang.Long | long
xsd:QName | javax.xml.namespace.QName | System.Xml.XmlQualifiedName
xsd:short | short - java.lang.Short | short
xsd:string | java.lang.String | string
xsd:time | org.apache.axis2.databinding.types.Time | System.DateTime
The problem with C# types bool, sbyte, System.DateTime, decimal, System.Double,
float, long and short (but not string!) is that these are something like
"primitive types" that cannot be null in .NET 1.x. This is why a WSDL that
specifies nillable=true for parameters of the corresponding XML Schema Types
are not correctly translated by .NET 1.x client generators and minOccurs=0 must
be used instead in order to make them correctly handled. The trick they use to
specify if an optional (minOccurs=0) parameter of one of these types has
actually been specified or not, is to use the "double-parameter" pattern
mentioned in my bug report.
I hope this is of help.
> minOccurs="0" always generated by Java2WSDL - problems with .NET client
> generation
> ----------------------------------------------------------------------------------
>
> Key: AXIS2-3300
> URL: https://issues.apache.org/jira/browse/AXIS2-3300
> Project: Axis2
> Issue Type: Bug
> Components: Tools
> Affects Versions: 1.3
> Reporter: Mauro Molinari
> Assignee: Deepal Jayasinghe
> Attachments: axis2-1.4.1.diff
>
>
> When you try to expose a POJO as a webservice, suppose you have two Java
> methods with the following signatures:
> public Integer a(String, Integer)
> public String b(Integer, String)
> Java2WSDL adds the minOccurs="0" for each element of each complex type, both
> for the input parameters and for the output parameters.
> When generating clients using .NET WebService Studio 2.0, the result is the
> following:
> - all the generated C# methods input parameters are doubled, except for the
> string ones: the doubled parameters are booleans whose meaning is: "is the
> previous parameter specified or not?"
> - all the generated C# methods return parameters are void, except for the
> string ones
> The actual result are clients with methods like these:
> public void a(string, int, bool);
> public string b(int, bool, string);
> This is obviously a problem, particularly for the "void" return type.
> If I remove minOccurs="0", clients are generated correctly by .NET WebService
> Studio 2.0.
> The issue is this: why does Java2WSDL always adds minOccurs="0"? If its
> meaning were "it can be null", I think nillable="true" attribute should be
> more appropriate... Moreover, if I substitute Integer with int in the
> original Java class methods, minOccurs="0" is still added by Java2WSDL, even
> if an int cannot be null.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
