Howdy Keith,
Thanks for the advice. Unfortunately I'd already hacked my schema and sample
fragments to have prefixes, but I've now moved over to the type-centric method.
I've now got some other problems:
- the mapping tool generates the following empty elements which the mapping
schema doesn't like
<include></include>
<container></container>
<key-generator></key-generator>
- once the above errors have been hacked out the generated mapping results
in the following messages at unmarshal time:
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
au.gov.vic.vwa.rules.engine.TestMarshalMapping test/resources
org.exolab.castor.mapping.MappingException: Nested error:
org.exolab.castor.mapping.MappingException: The method get_resultType in class
au.gov.vic.vwa.rules.castor_gen.T_UnaryOperator accepting/returning object of
type class au.gov.vic.vwa.rules.castor_gen.T_SimpleType was not found
org.exolab.castor.mapping.MappingException: The method get_resultType in class
au.gov.vic.vwa.rules.castor_gen.T_UnaryOperator accepting/returning object of
type class au.gov.vic.vwa.rules.castor_gen.T_SimpleType was not found
at
org.exolab.castor.mapping.loader.MappingLoader.createFieldDesc(MappingLoader.java:719)
at
org.exolab.castor.xml.XMLMappingLoader.createFieldDesc(XMLMappingLoader.java:260)
at
org.exolab.castor.mapping.loader.MappingLoader.createFieldDescs(MappingLoader.java:519)
at
org.exolab.castor.mapping.loader.MappingLoader.createDescriptor(MappingLoader.java:343)
at
org.exolab.castor.xml.XMLMappingLoader.createDescriptor(XMLMappingLoader.java:157)
at
org.exolab.castor.mapping.loader.MappingLoader.loadMapping(MappingLoader.java:212)
at org.exolab.castor.mapping.Mapping.getResolver(Mapping.java:278)
at org.exolab.castor.mapping.Mapping.getResolver(Mapping.java:234)
at org.exolab.castor.xml.Unmarshaller.setMapping(Unmarshaller.java:224)
at org.exolab.castor.xml.Unmarshaller.<init>(Unmarshaller.java:158)
at
au.gov.vic.vwa.rules.engine.TestMarshalMapping.main(TestMarshalMapping.java:74)
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
so its like the _fieldName mentioned in the *Descriptor.java is being used
and "get" is just stuck on the front.
It needs to remove the '_' and bi-capitalise to get the actual method generated
by the SourceGenerator: "getResultType()".
Is there a different ClassDescriptorResolverImpl I'm supposed to use or
something, I sort of expected that the SourceGenerator and MappingTool would be
compatible...
Thanks,
Norval
|--------+----------------------->
| | Keith Visco |
| | <kvisco@intal|
| | io.com> |
| | |
| | 21/02/2002 |
| | 10:43 AM |
| | Please |
| | respond to |
| | castor-dev |
| | |
|--------+----------------------->
>--------------------------------------------------------|
| |
| To: [EMAIL PROTECTED] |
| cc: (bcc: Norval Hope/ISD/VWA) |
| Subject: Re: [castor-dev] Overriding |
| Generated Classes |
>--------------------------------------------------------|
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
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
