Thanks, Christopher. Looking forward to seeing that Jira issue being
created.
Regards
Werner
[EMAIL PROTECTED] wrote:
> hi
>
> I'll open the Jira issue as requested.
>
> My solution is pretty crude - just extract the namespace component buried
> in the XPath (appearing inside {}) - and then proceed as before, works
> fine for me. This is probably OK for most cases. the namespace
> qualification probably should have no effect on the revised name given to
> the class (unless we get into relatively uncommon cases where the same
> element name appears in multiple namespaces).
And funny enough, I have seen such questions being asked in the last 6
months or so. But as always, there's a natural limit to how far
'automatic resolution' should (and could) go. In such a case, I'd always
recommend resorting to a binding file (entry).
> You *could* include the
> namespace definitions in the adjusted class name, but that would mean
> extremely long class names, ...
Even longer .. ;-).
> ... and you'd need a strategy for mapping
> 'unacceptable' characters in the namespace to valid characters in a Java
> class name.
Which we have available.
> I'll include the code in the jira bug report.
>
> - chris
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Chris Jobson
> Staff Software Engineer
> Sybase (UK) Limited
>
> Telephone number +44 (0)1628 597263
> Fax number +44 (0)1628 597319
>
> Sybase (UK) Limited, Sybase Court, Crown Lane, Maidenhead, Berkshire SL6
> 8QZ is a company incorporated in England & Wales under company
> registration number 2175260.
>
> NOTICE: This e-mail message and all attachments transmitted with it are
> intended solely for the use of the addressee and may contain confidential
> information and may be protected by the attorney-client privilege. If the
> reader of this message is not the intended recipient, or an employee or
> agent responsible for delivering the message to the intended recipient,
> you are hereby notified that any dissemination, distribution, copying or
> other use of this communication or its attachments is strictly prohibited.
> If you have received this communication in error, please notify the
> sender immediately by replying to this message and please immediately
> delete it from your computer.
>
>
>
> Werner Guttmann <[EMAIL PROTECTED]>
> 17/04/2008 15:46
> Please respond to
> [email protected]
>
>
> To
> [email protected]
> cc
>
> Subject
> Re: [castor-user] XPATH conflict resolution issue
>
>
>
>
>
>
> 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
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
