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). You *could* include the
namespace definitions in the adjusted class name, but that would mean
extremely long class names, and you'd need a strategy for mapping
'unacceptable' characters in the namespace to valid characters in a Java
class name.
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
