Hi Norval,
My patch was for anonymous simpletype generation it doesn't handle
elements...so in your case there is still an issue when generating
classes for elements with the same name. We still need to find a
suitable approach for that...perhaps the appending parent names is the
solution...or using inner classes. I believe however that this only
affects the source generator when using the element-centric source
generation. I think if you try the type centric approach you won't have
this problem.
In castorbuilder.properties, change
org.exolab.castor.builder.javaclassmapping to use "type" instead of
"element"...also uncomment it.
Thanks,
--Keith
[EMAIL PROTECTED] wrote:
>
> Hi Keith/Anyone interested,
>
> I proposed:
>
> > 2. The SourceGenerator would use naming conventions in generated Java
> > files to avoid
> > name collisions (to generate source from my schema I've had to
> > artificially add
> > prefixes to each element name to avoid clashes, e.g. the element
> > "Type" gets reused
> > in five different contexts, so I've had to make a CV_Type "Constant
> > Value Type"
> > etc.
>
> Keith Visco said:
>
> Have you tried the CVS version. It contains some additional support for
> this. Please see my previous post:
>
> http://www.mail-archive.com/[email protected]/msg05235.html
>
> To demonstate the problem I used the following schema and test XML fragment
> against the latest CVS version (I presume I don't need a tag or anything?). I
> can tell when there has been a clash immediately as my Ant run freezes
> (ConsoleDialog issue I've discussed previously, but I realise others are working
> on the Ant support and now I know about it this behaviour doesn't concern me) so
> I use the "-f" argument to the SourceGenerator to force output. Then when I run
> a test program to unmarshal nameclash.xml I get the output included at the end
> of this post.
>
> nameclash.xsd:
>
>----------------------------------------------------------------------------------------------------------------
> <?xml version="1.0"?>
>
> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema";>
>
> <!-- ======================================================================= -->
> <xsd:annotation>
> <xsd:documentation xml:lang="en" >
>
> @author: Norval Hope
> @version: $Id: artwork.xsd,v 1.3 2002/01/24 12:54:41 norv1 Exp $
>
> Demonstrate name clashes in Java classes generated by Castor SourceGenerator
>
> </xsd:documentation>
> </xsd:annotation>
> <!-- ======================================================================= -->
>
> <xsd:complexType name="T_Key1">
> <xsd:sequence>
> <xsd:element name="Part1" type="xsd:string"/>
> <xsd:element name="Part2" type="xsd:string"/>
> </xsd:sequence>
> </xsd:complexType>
>
> <xsd:complexType name="T_Key2">
> <xsd:sequence>
> <xsd:element name="Part" type="xsd:string"/>
> </xsd:sequence>
> </xsd:complexType>
>
> <xsd:complexType name="T_Context1">
> <xsd:sequence>
> <xsd:element name="PrimaryKey" type="T_Key1"/>
> </xsd:sequence>
> </xsd:complexType>
>
> <xsd:complexType name="T_Context2">
> <xsd:sequence>
> <xsd:element name="PrimaryKey" type="T_Key2"/>
> </xsd:sequence>
> </xsd:complexType>
>
> <xsd:complexType name="T_Both">
> <xsd:sequence>
> <xsd:element name="Ctx1" type="T_Context1"/>
> <xsd:element name="Ctx2" type="T_Context2"/>
> </xsd:sequence>
> </xsd:complexType>
>
> <xsd:element name="Top" type="T_Both"/>
>
> </xsd:schema>
>
>
>----------------------------------------------------------------------------------------------------------------
>
> nameclash.xml:
>
>----------------------------------------------------------------------------------------------------------------
> <?xml version="1.0"?>
>
> <!--
>
> @author: Norval Hope
> @version: $Id: example1.xml,v 1.3 2002/01/24 12:54:41 norv1 Exp $
>
> @@What is a neater way of defining the schema to be used without having to
> wait until the first element is defined?
> -->
>
> <Top xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:noNamespaceSchemaLocation="nameclash.xsd">
>
> <Ctx1>
> <PrimaryKey>
> <Part1>fred</Part1>
> <Part2>fart</Part2>
> </PrimaryKey>
> </Ctx1>
> <Ctx2>
> <PrimaryKey><Part>fredfart</Part></PrimaryKey>
> </Ctx2>
>
> </Top>
>
>----------------------------------------------------------------------------------------------------------------
>
> unmarshall output (as you'd expect teh second def for PrimaryKey overwrites the
> first one).
>
>----------------------------------------------------------------------------------------------------------------
> com.lard.xml.castor.MarshallArtworkGen -v -f resources/example1.xml
> org.xml.sax.SAXException: unable to find FieldDescriptor for 'Part1' in
> ClassDescriptor of PrimaryKey
>
> org.xml.sax.SAXException: unable to find FieldDescriptor for 'Part1' in
> ClassDescriptor of PrimaryKey{file: ; line: 17; column: 14}
>
> at
> org.exolab.castor.xml.UnmarshalHandler.startElement(UnmarshalHandler.java:815)
>
> at org.apache.xerces.parsers.SAXParser.startElement(SAXParser.java:1340)
>
> at
>
>org.apache.xerces.validators.common.XMLValidator.callStartElement(XMLValidator.java:1284)
>
> at
>
>org.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.dispatch(XMLDocumentScanner.java:1171)
>
> at
> org.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDocumentScanner.java:381)
>
> at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:1098)
>
> at org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:338)
>
> at com.lard.xml.castor.MarshallArtworkGen.main(MarshallArtworkGen.java:43)
>
>
>----------------------------------------------------------------------------------------------------------------
>
> So as a result I've had to prefix all my elements with unique prefixes. Am I
> missing something or doing something wrong?
>
> It seems that the fix you talk about in
> http://www.mail-archive.com/[email protected]/msg05235.html
> may need to be applied to classes for all elements, not just those resulting
> from annoymous types?
>
> Thanks,
> Norval
> ***************************************************************************
> This message and any attachments is/are intended for the person/s to whom
> it was addressed. It may contain privileged or confidential information.
> If you have received this message in error, please notify the sender
> promptly and destroy the message without copying it or divulging its
> contents to any person.
>
> ***************************************************************************
>
> -----------------------------------------------------------
> If you wish to unsubscribe from this mailing, send mail to
> [EMAIL PROTECTED] with a subject of:
> unsubscribe castor-dev
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
