DO NOT REPLY [Bug 21163] New: - Bug in WSIFOperation_ApacheAxis.findContextTypeSerializer()

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21163>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21163

Bug in WSIFOperation_ApacheAxis.findContextTypeSerializer()

           Summary: Bug in
                    WSIFOperation_ApacheAxis.findContextTypeSerializer()
           Product: Axis-WSIF
           Version: 2.0
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Major
          Priority: Other
         Component: Basic Architecture
        AssignedTo: [email protected]
        ReportedBy: allan-rjG/IGzrnjlWk0Htik3J/[email protected]


Hi,

Here is an excerpt from the method named in the subject:

  	if ( (javaType != null) || (javaType.isAssignableFrom(clazz))
       	&& ( (elementType != null) || (elementType.equals(xmlType)) ) ){
        	    if (serializer == null || serializer instanceof SerializerFactory
        	    && deserializer == null || deserializer instanceof 
DeserializerFactory
        	    && serializer != null || deserializer != null) {
        		    return tm;
        	    }
            }

This code is condition is quite significant since it determines the availability 
of a TypeSerializerInfo for a particular java/xml combination. Unfortunately I 
believe this condition contains a bug with the result that either the first 
TypeSerializerInfo in the List (that is currently being iterated through) will 
always be selected or there will be a NullPointerException. If the first 
TypeSerializerInfo is always selected it is impossible to use more than one 
custom serializer/deserializer combination.

Please note the first two lines of the condition (the outer condition statement 
- the inner one looks fine). The first test "javaType != null" will always be 
evaluated. If it is true then "javaType.isAssignableFrom(clazz)" will not be 
evaluated. If it is false the attempt to evaluate "javaType.
isAssignableFrom(clazz)" will throw a NullPointerException. The same is true for 
the elementType tests. Since the isAssignableFrom() and equals() tests are never 
evaluated if javaType and elementType are not null, then it is quite likely that 
the wrong tm will be returned and this always happens when there is > 1 tm 
available and > 1 are required.

This bug is in v2.0 and in the nighly build of 28-June-2003.

I think if the ||'s was replaced by &&'s in the outer condition, this would 
solve the problem.

regards,
Allan.