Not sure how you are handling multiple schemas which is a separate
issue. We also have multiple schemas and we generate separate packages
for each schema. We also have a separate binding file for each
schema/package.
If you don't generate separate packages, I assume you run the generator
once for each schema?
We simply use a naming convention - based on the name of the schema we
look for a corresponding binding file.
On windows we write a simple batch file where we pass in the schema name
as a parameter and use that to pick up the appropriate binding file.
And yes, creating the binding file once is hand done. Someone must
determine where the duplicates are and resolve them in a binding file.
I haven't tried it, but you may be able to put it all in one binding
file assuming that you can uniquely describe the path to the duplicate
class/element name. If not, well, separate files should work as well.
The idea, hopefully, is you do this once. Then the script can be rerun
when needed to recreate the code. Of course, if a schema is changed in
the future to add more duplicate element names you'll have to edit your
binding file(s)
Hope this is helpful.
-----Original Message-----
From: Juan Wu [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 05, 2005 4:02 PM
To: [email protected]
Subject: Re: [castor-user] How to resolve java file name confliction
when use SourceGenerator to generate java files for schema with
same-name elements?
Hi, Paul and Lastric,
Thanks for your help. I can't modify the schema itself to make the
duplication of elements disappear in the schema.
I think the binding file will need to be generated for each of the
schema
and can only deal with a specific schema instance, do I understand it
correctly? For my case, I need to automatically parse any kind of schema
which may or may not contain duplicated elements. And the duplicated
element' names may be different from schema to schema. Also, I can't
generate a different binding file for each schema since this is part of
the
automatic parsing process.
I'm not sure how this generic problem about duplicate elements can be
resolved by just ONE generic binding file? Please advice.
Thank you very much again.
Best Regards,
Joanna
----- Original Message -----
From: "Paul Grillo" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, June 30, 2005 5:17 AM
Subject: RE: [castor-user] How to resolve java file name confliction
when
use SourceGenerator to generate java files for schema with same-name
elements?
You'll probably want to use a binding file when generating the java
source. use the -binding-file [filename] in your sourcegenerator
statement.
The binding file indicates how you want to handle these and other
issues.
an example might look like the following, but I can't guarantee its
accuracy. essentially you are indicating that you want to create a
class
called AccountPayableRow when you encounter the element you refer to.
The only thing I'm not sure of is if you will need a mapping file when
you
unmarshal at runtime. that is you may then have to indicate in a
mapping
file the mapping from the xml data back. At any rate this or a
combination of both of these will solve your problem. We had the
exact
same issue where we were not at liberty to change the XSD, and
overcame it
in this way.
<?xml version="1.0"?>
<binding xmlns:cbf="http://www.castor.org/SourceGenerator/Binding";
defaultBindingType="element">
<cbf:elementBinding name="/AccountPayble /row">
<cbf:java-class name=" AccountPaybleROW"/>
</cbf:elementBinding>
</binding>
________________________________________
From: Juan Wu [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 30, 2005 4:10 AM
To: [email protected]
Cc: [EMAIL PROTECTED]
Subject: [castor-user] How to resolve java file name confliction when
use
SourceGenerator to generate java files for schema with same-name
elements?
Hi,
I try to use SourceGenerator to generate java files for the following
schema. It has two top level elements AccountPayble and
PaymentMethods.
However, they all have a sub-element which is called the same as
"row".
And, these two "row" elements contain different sub-elements.
The SourceGenerator will generate a java file for each of the elements
-
however, I only get one "row `.java" file related with the 2nd element
(PaymentMethods), since it overwrites the "row.java" generated for the
1st
element (AccountPayble).
Is there a way that can let it generate two different row.java files
that
won't overwrite each other in an non-interactive way (with -f option)?
Since this process doesn't run on a command window, I can't manually
type
"y|n" when it asks for overwriting.
In another word, would it be possible to generate java files for the 2
"row" elements named like "AccountPayble_row.java" and
"PaymentMethods_row.java" instead of just "row.java" when there is
such
element name conflict?
I have set "org.exolab.castor.builder.javaclassmapping=type" in the
castorbuilder.properties.
Your any suggestions or answers will be highly appreciated.
Thanks a lot!
Joanna
...... part of the schema which has elements' name conflict......
<element maxOccurs="1" minOccurs="0" name="AccountPayble">
<complexType>
<sequence>
<element maxOccurs="unbounded" minOccurs="0" name="row">
<complexType>
<all>
<element maxOccurs="1" minOccurs="0" name="AccountType"
type="string"/>
<element maxOccurs="1" minOccurs="0" name="AccountCode"
type="string"/>
</all>
</complexType>
</element>
</sequence>
</complexType>
</element>
<element maxOccurs="1" minOccurs="0" name="PaymentMethods">
<complexType>
<sequence>
<element maxOccurs="unbounded" minOccurs="0" name="row">
<complexType>
<all>
<element maxOccurs="1" minOccurs="0" name="PaymentMethodCode"
type="string"/>
</all>
</complexType>
</element>
</sequence>
</complexType>
</element>
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
