You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Konstantinos Mavridis (JIRA)" <ji...@apache.org> on 2011/02/28 16:54:37 UTC
[jira] Created: (AXIS2-4968) Inconsistent wsdl2java generation with
IBM JDK 6.0SR8FP1
Inconsistent wsdl2java generation with IBM JDK 6.0SR8FP1
--------------------------------------------------------
Key: AXIS2-4968
URL: https://issues.apache.org/jira/browse/AXIS2-4968
Project: Axis2
Issue Type: Bug
Components: codegen
Affects Versions: 1.5.4, 1.5.1
Environment: Microsoft Windows XP (32-bit), IBM JDK 6.0SR8FP1
Reporter: Konstantinos Mavridis
Priority: Critical
Initially, we opened an issue against IBM. After investigation the issue appeared to originate from Axis2/WS Common XmlSchema. Below is the response from IBM:
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-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
[jira] Updated: (AXIS2-4968) Inconsistent wsdl2java generation with
IBM JDK
Posted by "Konstantinos Mavridis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-4968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Konstantinos Mavridis updated AXIS2-4968:
-----------------------------------------
Comment: was deleted
(was: 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-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
[jira] Updated: (AXIS2-4968) Inconsistent wsdl2java generation with
IBM JDK 6.0SR8FP1
Posted by "Konstantinos Mavridis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-4968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Konstantinos Mavridis updated AXIS2-4968:
-----------------------------------------
Description:
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).
Initially, we opened an issue against IBM. 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;
}
was:
The issue below prevents migration to the IBM jdk and breaks build production as there 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 a file does not consistently missing methods).
Initially, we opened an issue against IBM. After investigation the issue appeared to originate from Axis2/WS Common XmlSchema. Below is the response from IBM:
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;
}
> Inconsistent wsdl2java generation with IBM JDK 6.0SR8FP1
> --------------------------------------------------------
>
> 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
> 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).
> Initially, we opened an issue against IBM. 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-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
[jira] Commented: (AXIS2-4968) Inconsistent wsdl2java generation
with IBM JDK
Posted by "Konstantinos Mavridis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-4968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004417#comment-13004417 ]
Konstantinos Mavridis commented on AXIS2-4968:
----------------------------------------------
The described behaviour is present even when not using the default IBM TransformerFactory (com.ibm.xtq.xslt.jaxp.compiler.TransformerFactoryImpl). Having replaced it with Apache Xalan (org.apache.xalan.processor.TransformerFactoryImpl) the inconsistency in code generation remains. There is no 'splitlimit' warning (AXIS2-4910) anymore but the exact same problem remains.
> 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-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
[jira] Updated: (AXIS2-4968) Inconsistent wsdl2java generation with
IBM JDK 6.0SR8FP1
Posted by "Konstantinos Mavridis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-4968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Konstantinos Mavridis updated AXIS2-4968:
-----------------------------------------
Description:
The issue below prevents migration to the IBM jdk and breaks build production as there 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 a file does not consistently missing methods).
Initially, we opened an issue against IBM. After investigation the issue appeared to originate from Axis2/WS Common XmlSchema. Below is the response from IBM:
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;
}
was:
Initially, we opened an issue against IBM. After investigation the issue appeared to originate from Axis2/WS Common XmlSchema. Below is the response from IBM:
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;
}
> Inconsistent wsdl2java generation with IBM JDK 6.0SR8FP1
> --------------------------------------------------------
>
> 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
> Reporter: Konstantinos Mavridis
> Priority: Critical
>
> The issue below prevents migration to the IBM jdk and breaks build production as there 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 a file does not consistently missing methods).
> Initially, we opened an issue against IBM. After investigation the issue appeared to originate from Axis2/WS Common XmlSchema. Below is the response from IBM:
> 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-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
[jira] Commented: (AXIS2-4968) Inconsistent wsdl2java generation
with IBM JDK
Posted by "Konstantinos Mavridis (JIRA)" <ji...@apache.org>.
[ 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-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
[jira] Updated: (AXIS2-4968) Inconsistent wsdl2java generation with
IBM JDK
Posted by "Konstantinos Mavridis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-4968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Konstantinos Mavridis updated AXIS2-4968:
-----------------------------------------
Environment: Microsoft Windows XP (32-bit), IBM JDK 6.0SR8FP1 (also with IBM JDK 1.5.0SR9) (was: Microsoft Windows XP (32-bit), IBM JDK 6.0SR8FP1)
Summary: Inconsistent wsdl2java generation with IBM JDK (was: Inconsistent wsdl2java generation with IBM JDK 6.0SR8FP1)
> 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-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
[jira] Commented: (AXIS2-4968) Inconsistent wsdl2java generation
with IBM JDK 6.0SR8FP1
Posted by "Konstantinos Mavridis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-4968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13000358#comment-13000358 ]
Konstantinos Mavridis commented on AXIS2-4968:
----------------------------------------------
We can provide a sample of this behaviour in an attachment. It demonstrates the inconsistent behaviour across different runs. Since it is quite large in size (129MB) we have opted not to upload until requested.
> Inconsistent wsdl2java generation with IBM JDK 6.0SR8FP1
> --------------------------------------------------------
>
> 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
> 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).
> Initially, we opened an issue against IBM. 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-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
[jira] Updated: (AXIS2-4968) Inconsistent wsdl2java generation with
IBM JDK 6.0SR8FP1
Posted by "Konstantinos Mavridis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-4968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Konstantinos Mavridis updated AXIS2-4968:
-----------------------------------------
Description:
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;
}
was:
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).
Initially, we opened an issue against IBM. 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;
}
> Inconsistent wsdl2java generation with IBM JDK 6.0SR8FP1
> --------------------------------------------------------
>
> 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
> 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-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org