Axis2 Serialization problem with emptyset bitflag enums.
--------------------------------------------------------
Key: AXIS2-3034
URL: https://issues.apache.org/jira/browse/AXIS2-3034
Project: Axis 2.0 (Axis2)
Issue Type: Bug
Affects Versions: 1.2
Reporter: David R. Kraus
I created a bitflag enum, where one value is associated with each bit of the
enum, and multiple values/bits can be set for the value of the enum (see dotnet
generated WSDL below). The DotNet generated WSDL was taken and used to create
Java serialization classes (wsdl2java).The problem is that Axis2 can't handle
the zero length string that is passed representing the empty set. A bitflag
enum can have more than one value, because each possible enum value is
represented by a bit. The problem occurs when none of the values is set, and a
bitflag value of zero(0) is serialized as "" (zero length string).
Enums are a tricky type since their representation as a numeric entity (bits)
making them a non-nullable type, although their value is transfered as a string
with multiple concatenated enum values.
There are two classes generated by wsdl2java to handle the bitflag enum at the
server (eg. EnumMWSSearchFlags, EnumMWSSearchFlags_type0). EnumMWSSearchFlags
contains an array of EnumMWSearchFlags_type0, each element of which can refer
to a bit value.
Both dotnet and java clients serialize the empty set as a zero length string.
This zero length string is parsed, at the server, looking for individual enum
values. Of course, none are found, and when the zero length string is used in a
table lookup for valid members of the enum (in EnumMWSSearchFlags_type0) an
IllegalArgumentException is generated. I have been able to get this to work by
commenting out the check for valid enum members being passed in (server side
only), but obviously this isn't the best way to do this (see specific commented
out code below).
I have been able to workaround this on the server side by commenting out an
exception (described in email thread below), BUT the real problem now is that
this only handles the case where the enum is being passed into the service from
the client. Patching the client side is not an option (when empty enum is
passed to the client from the service). We do not have a workaround for this
problem (client side can't be patched) and are near the end of our development
cycle, so we are very concerned!
If Axis2 serialization code interprets the empty bitflag as a zero length
string when it serializes it, then the receiving code should then be able to
handle this zero length string. Right now that is not happening correctly. I
think this is a bug.
Thanks, Dave Kraus
Altered server side code - see comment:
public static EnumMWSSearchFlags_type0
fromValue(java.lang.String value)
throws java.lang.IllegalArgumentException {
EnumMWSSearchFlags_type0 enumeration =
(EnumMWSSearchFlags_type0)
_table_.get(value);
//drk: Comment out so that bitflag enum can accept an
emptyset enum
/*if (enumeration==null) throw new
java.lang.IllegalArgumentException();*/
return enumeration;
}
WSDL representation of a bitflag enum:
<s:simpleType name="EnumMWSSearchFlags">
<s:list>
<s:simpleType>
<s:restriction base="s:string">
<s:enumeration value="MWSAbbreviationWildCard"/>
<s:enumeration value="MWSDescriptionWildCard"/>
<s:enumeration value="MWSFolderBrowseStyle"/>
<s:enumeration value="MWSModificationTime"/>
<s:enumeration value="MWSNameWildCard"/>
<s:enumeration value="MWSRootRecursive"/>
<s:enumeration value="MWSUsedByOneOf"/>
<s:enumeration value="MWSUsedByRecursive"/>
<s:enumeration value="MWSUsesOneOf"/>
<s:enumeration value="MWSUsesRecursive"/>
<s:enumeration value="MWSVisibleOnly"/>
<s:enumeration value="MWSBrowseAsync"/>
<s:enumeration value="MWSOwnedByCurrentUser"/>
</s:restriction>
</s:simpleType>
</s:list>
</s:simpleType>
WSDL representation of usage of the bitflag enum as a parameter showing
minoccurs=1 because it's a non-nullable type. So it really doesn't make sense
to pass in a null instead of the emptyset.
<s:element maxOccurs="1" minOccurs="1" name="eFlags"
type="tns:EnumMWSSearchFlags"/>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
