[
https://issues.apache.org/jira/browse/AXIS2-4968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13003210#comment-13003210
]
Konstantinos Mavridis commented on AXIS2-4968:
----------------------------------------------
Thank you for your email.
I am currently attending a training course onsite and may not readily reply.
Best regards,
Konstantinos Mavridis
> Inconsistent wsdl2java generation with IBM JDK
> ----------------------------------------------
>
> Key: AXIS2-4968
> URL: https://issues.apache.org/jira/browse/AXIS2-4968
> Project: Axis2
> Issue Type: Bug
> Components: codegen
> Affects Versions: 1.5.1, 1.5.4
> Environment: Microsoft Windows XP (32-bit), IBM JDK 6.0SR8FP1 (also
> with IBM JDK 1.5.0SR9)
> Reporter: Konstantinos Mavridis
> Priority: Critical
>
> The issue below prevents migration to the IBM jdk and breaks build production
> as there are methods missing from the generated code. The problem is not a
> simple difference (as, for example, random placement of methods inside
> classes would be acceptable) but the fact that there are methods missing and
> conditional statements missing from generated files seemingly at random. The
> files that are affected appear to also be random across different runs (i.e.
> usually the same file does not consistently lack methods).
>
> After investigation the issue appeared to originate from Axis2/WS Common
> XmlSchema. The problem does appear to be in the Apache ws-commons code or a
> combination of that and the way the Axis2 code uses the ws-commons code.
>
>
> The org.apache.axis2.schema.SchemaCompiler class has a field named
> processedAnonymousComplexTypesMap, which is a HashMap whose keys are
> instances of org.apache.ws.commons.schema.XmlSchemaElement. That is, an
> anonymous complex types is looked up using the schema element that contains
> it.
>
> I believe the problem is that XmlSchemaElement inherits its equals(Object)
> method from the XmlSchemaObject class. That equals method compares the
> sourceURIs, the line numbers and line positions of
> the two objects. However, in the Axis2 usage, it seems that the sourceURIs
> are always null, and the line numbers and line positions are always zero, so
> the XmlSchemaObject.equals method always returns true in the Axis2 usage.
>
>
> On occasion the hashCode() of two XmlSchemaElement instances is equal.
> Duplicate values are somewhat rare, but they do happen, apparently randomly.
> When the hashCode() values of two XmlSchemaElement instances are the same,
> and they both contain anonymous complex types, the first is entered into the
> processedAnonymousComplexTypesMap HashMap using the
> first XmlSchemaElement as the key. The second XmlSchemaElement is
> subsequently used as a key in entering the second anonymous complex type.
> Because the hashCode() values are equal, the HashMap finds that there is
> already a key with the same hashCode(), so it calls the equals(Object) method
> to see whether the two keys are equal. The equals method returns true, so
> the second anonymous complex type is stored as the value associated with the
> first XmlSchemaElement.
> We suspect that the SUN JDK just has a different hashing algorithm. It is
> not required to produce distinct hash codes for distinct objects as the
> java.lang.Object documentation
> for the hashCode method states:
>
> It is not required that if two objects are unequal according to the
> equals(java.lang.Object) method, then calling the hashCode method on each of
> the two objects must produce distinct integer results.
> For each axis2 object to be treated distinctly, an IdentityHashMap must be
> used.
> Workaround:
> Modify the Apache WS Commons XmlSchemaElement class overwriting the hashCode
> method.
>
> private static int counter = 1;
> private int hashCode = -1;
>
> public int hashCode() {
> if (hashCode == -1) {
> hashCode = counter++;
> }
> return hashCode;
> }
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
For additional commands, e-mail: java-dev-h...@axis.apache.org
