Chris, you have come across a bug, indeed, and I'd like to learn about the solution you have implemented to get you going again.
As such, can you please open a new Jira issue and attach everything I need to replicate the problem, i.e. XML schema, builder configuration (if used), binding file (if used), patch (svn diff, if possible), etc. On the more general side of things: I think we should try to look at a better approach about how to analyse and deal with XPATH in Castor than what we currently have. I guess that with one of the GSoC projects, this might happen anyhow. Regards Werner [EMAIL PROTECTED] wrote: > 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 --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
