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: [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.
