hi I have hit an issue with using automatic name conflict resolution that I wonder if anyone else has found.
Consider the following schema <?xml version="1.0" encoding="UTF-8"?> <xs:schema elementFormDefault="qualified" targetNamespace="http://webservices.amazon.com/AWSECommerceService/2008-04-07"; xmlns:tns="http://webservices.amazon.com/AWSECommerceService/2008-04-07"; xmlns:xs="http://www.w3.org/2001/XMLSchema";> <xs:element name="ItemAttributes"> <xs:complexType> <xs:sequence> <xs:element maxOccurs="unbounded" minOccurs="0" name="Creator"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="Role" type="xs:string" use="required"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="MerchantItemAttributes"> <xs:complexType> <xs:sequence> <xs:element maxOccurs="unbounded" minOccurs="0" name="Creator"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="Role" type="xs:string" use="required"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:schema> It's actually part of the schema from an Amazon Web Services WSDL. Notice the duplicate 'Creator' elements - one in each of ItemAttributes and MerchantItemAttributes. When I run codegen with name conflict resolution (set to xpath or type), I get 16-Apr-2008 11:17:27 org.exolab.castor.builder.JClassRegistry bind INFO: Resolving conflict for local element /MerchantItemAttributes{http://webservices.amazon.com/AWSECommerceService/2008-04-07}/Creator[/MerchantItemAttributes {http://webservices.amazon.com/AWSECommerceService/2008-04-07}/Creator] against another local element of the same name. java.lang.IllegalArgumentException: 'WebservicesAmazonComAWSECommerceService20080407}CreatorDescriptor' is not a valid Java identifier. at org.exolab.javasource.JStructure.<init>(JStructure.java:121) at org.exolab.javasource.AbstractJClass.<init>(AbstractJClass.java:54) at org.exolab.javasource.JClass.<init>(JClass.java:70) at org.exolab.castor.builder.descriptors.DescriptorJClass.<init>(DescriptorJClass.java:102) at org.exolab.castor.builder.descriptors.DescriptorSourceFactory.createSource(DescriptorSourceFactory.java:121) etc.etc. If you then see what files it has generated, you see this : Creator.java WebservicesAmazonComAWSECommerceService20080407}Creator.java It has correctly detected the conflict, but attempted to create a Java class with a bad classname. Clearly the logic in XPATHClassNameConflictResolver.java is not working quite as intended. Has this been reported before? I couldn't see any reference to this issue,but I would have thought it not that unusual a situation. The problem seems to be in XPATHClassNameConflictResolver.java, when it tries to 'parse' the Xpath it is presented with. It fails to handle the Xpath of this form: /MerchantItemAttributes{http://webservices.amazon.com/AWSECommerceService/2008-04-07}/Creator (I have debugged the code and that's the exact string that is presented). Looking at the code logic, I guess this is because of the way the method calculateXPathPrefix uses StringTokenizer to split on './' and thus gets confused by the / inside the url in the {} section (the namespace associated with the Xpath component MerchantItemAttrubutes). I have 'hacked' this by patching the caclulateXPathPrefix method to first strip out {} sections and generating an XPath Prefix on the remaining XPath, So in the above case, I fixup the XPath to look like /MerchantItemAttributes/Creator and proceed from there. That fixes up my problem. Is this the correct solution? I am happy to provide my fix to XPATHClassNameConflictResolver.java if others think this is the correct approach. or whether the problem should be resolved by a different approach altogether. thanks chris
