Castor srcgen binding file

Please note that the mode specified in this attribute will override the binding type specified in the castorbuilder. This element allows you to include a binding declaration defined in another file. This allows reuse of binding files defined for various XML schemas. This language namespace is defined in the generated Java source as a package declaration. This element allows you to keep the structure hierarchy defined in XML schema in a single generated Java package. Thus the binding file allows you to define the mapping between a schemaLocation attribute and a Java package.

One of the aims of the binding file is to avoid naming collisions. It is not possible to control the names of the classes generated to represent nested model groups all, choice, and sequence.

These elements are the tenets of the binding file since they contain the binding definition for an XML schema element, attribute, complex type and model group definition. The binding file is written from an XML schema point of view; there are two distinct ways to define the XML schema component for which we are defining a binding. The value of the name attribute uniquely identifies the XML schema component. It can refer to the top-level component using the NCName of that component or it can use a location language based on XPath.

The grammar of that language can be defined by the following BNF :. The second option to identify an XML schema component is to embed its binding definition inside its parent binding definition. This element defines all the options for the class to be generated, including common properties such as class name, package name, and so on. The package of the class to be generated. If true, the generated class will implement the equals and hashCode method. If true, the generated class will implement bound properties, allowing property change notification.

For instance, the following binding definition instructs the source generator to generate a class TestWithInterface that implements the interface org. SomeInterface in addition to java. The subsequent binding definition instructs the source generator to generate a class TestWithExtendsAndInterface that implements the interface org. Serializable , and extends from a probably abstract base class SomeAbstractBaseClass.

This element represents the binding for class member. It allows the definition of its name and java type as well as a custom implementation of FieldHandler to help the Marshaling framework in handling that member. Defining a validator is also possible. The names given for the validator and the fieldHandler must be fully qualified. Set instead of the default java. List :. This element represents the binding for content class member generated as a result of a mixed mode declaration of a complex type definition.

It allows the definition of its name and its visibility. A custom visibility of the content class member generated, with the default being public. String :. The following sections cover these features in detail. During code generation, the Castor XML code generator will run into situations where a class about to be generated, and as such about to be written to the file system will overwrite an already existing class.

In such a case, Castor will emit warning messages that inform the user that a class will be overwritten. Please select the reporting mode of your choice according to your needs, the default being warnViaConsoleDialog. Please note that the informViaLog reporting mode should be the preferred choice when using the XML code generator in an automated environment.

In general, the warning messages produced are very useful in assisting you in your creation of the binding file, as shown in below example for the warnViaConsoleDialog mode:. As already mentioned, this mode emits warning messages to stdout , and asks you whether you want to continue with the code generation or not. This allows for very fine grained control over the extent of the code generation. Please note that there is several setter methods on the org.

SourceGenerator that allow you to fine-tune various settings for this reporting mode. Genuinely, we believe that for automated code generation through either Ant or Maven, the new informViaLog is better suited for these needs.

To enable this new mode, please override the following property in your custom property file as shown below:. As a result of enabling automatic conflict resolution, Castor will try to resolve such name collisions automatically, using one of the following two strategies:. For selecting one of the two strategies during XML code generation, please see the documentation for the following code artifacts:. In order to explain the modus operandi of these two modes, please assume two complex type definitions AType and BType in an XML schema, with both of them defining a local element named c.

Without automatic collision resolution enabled, Castor will create identically named classes C. Please note the different types for the two c element definitions, which requires two class files to be generated in order not to lose this information.

This strategy will prepend an XPATH fragment to the default Java name as derived during code generation, the default name frequently being the name of the XML schema artifact, e. The Castor XML code generator, with automatic collision resolution enabled, is capable of resolving the following collisions automatically:. Please note that collision resolution for a local to local collision will only take place for the second local element definition encountered and subsequent ones.

An alternative to using the command line as shown in the previous section, the Castor Source Generator Ant Task can be used to call the source generator for class generation. At least one input source has to be specified. Please refer to the samples shown below. Please find below the complete list of parameters that can be set on the Castor source generator to fine-tune the execution behavior.

Attribute Description Required Since ——————————- ————————————————————————————————————————————————————————————————————————————————- ——————————————————————- ———— package The default package to be used during source code generation. No; if not given, all classes will be placed in the root package.

In this directory all generated Java classes will be placed. No - bindingfile A Castor source generator binding file. No - lineseparator Defines whether to use Unix- or Windows- or Mac-style line separators during source code generation.

Java 2. No - generateMapping If used, instructs the source generator to additionally generate a mapping file. No - nomarshal If specified, instructs the source generator not to create un marshalling methods within the Java classes generated. No - caseInsensitive If used, instructs the source generator to generate code for enumerated type lookup in a case insensitive manner. No - sax1 If used, instructs the source generator to generate SAX-1 compliant code.

No - generateImportedSchemas If used, instructs the source generator to generate code for imported schemas as well. No - properties Location of file defining a set of properties to be used during source code generation.

This overrides the default mechanisms of configuring the source generator through a castorbuilder. Below is the same sample as above, this time using the url attribute as the source of input instead:. For those working with Maven 2 instead of Ant, the Maven 2 plugin for Castor can be used to integrate source code generation from XML schemas with the Castor XML code generator as part of the standard Maven build life-cycle.

The following sections show how to configure the Maven 2 Castor plugin and hwo to instruct Maven 2 to generate sources from your XML schemas. To be able to start source code generation from XML schema from within Maven, you will have to configure the Maven 2 Castor plugin as follows:.

Details on the available configuration properties can be found here. By default, the Maven Castor plugin has been built and tested against a particular version of Castor. Below command shows how to instruct Maven manually to generate Java sources from the XML schemas as configured above. This will generate a set of source files from the the XML Schema foo-schema. Created class will have marshal and unmarshal methods which are used to go back and forth between XML and an Object instance.

The source code generator has a number of different options which may be set. At least one input source must be specified. The source code generator has the ability to use the following types of collections when generating source code, using the -type option:.

The Java class name shown in above table indicates the default collection type that will be emitted during generation. You can also write your own FieldInfoFactory to handle specific collection types. All you have to do is to pass in the fully qualified name of that FieldInfoFactory as follows:.

Please note that the use of a binding file is not dicussed in that document. The Castor Schema Object Model can read org. It allows you to create and manipulate an in-memory view of an XML Schema. The aim of the following sections is to provide a list of supported features in the Source Generator. Some Schema types do not have a corresponding type in Java.

Thus the Source Generator uses Castor implementation of these specific types located in the org. For instance the duration type is implemented directly in Castor. The following is a list of the supported datatypes with the corresponding facets and the Java mapping type. Supporting XML schema structures is a constant work. The main structures are already supported with some limitations.

The following will give you a rough list of the supported structures. For each nested group, a class is generated. However, full namespace validation is not yet implemented, even though an AnyNode structure is fully namespace aware. In this section we illustrate the use of the XML code generator by discussing the classes generated from given XML schemas. The structure of this schema is simple: it is composed of a top-level element which is a complexType with references to other elements inside.

This schema represents a simple invoice: an invoice is a customer customer top-level group , an article item element , a shipping method shipping-method element and a shipping date shipping-date element. Notice that the ship-to element uses a reference to an address element. This address element is a top-level element that contains a reference to a non-top-level element the zip-cod element.

At the end of the schema we have two simpleTypes for representing a telephone number and a price. The Source Generator is used with the element property set for class creation so a class is going to be generated for all top-level elements. No classes are going to be generated for complexTypes and simpleTypes since the simpleType is not an enumeration. Note that a class is generated for the top-level group customer.

To run the source generator and create the source from the invoice. One of the aim of the binding file is to avoid naming collisions. Indeed XML Schema allows elements and complexTypes to share the same name which results in name collisions when generated the sources. Note: It is not possible to control the names of the classes generated to represent nested model groups all, choice, sequence. These elements are the tenets of the binding file since they contain the binding definition for an XML Schema element, attribute, complexType and modelGroup definition.

The binding file being written from an XML Schema point of view; there are two distinct ways to define the XML Schema component for which we are defining a binding. First we can define it throught the name attribute. It can refer to the top-level component using the NCName of that component or it can use a location language based on XPath 3. The grammar of that language can be defined by the following BNF:. The second option to identify a XML Schema Component is to embed its binding definition inside its parent binding definition.

For instance, the following binding definition will be equivalent and will identify the element 'foo' defined in the top-level complexType 'fooType'. This element defines all the options for the class to be generated. This element specifies the name of the interface to be generated for an XML schema component. This element represents the binding for class member.

It allows the definition of its name and java type as well as an implementation of FieldHandler to help the Marshalling framework in handling that member. Defining a validator is also possible. The names given for the validator and the fieldHandler must be fully qualified.

This element will allow more control on the type safe enumerations generated to represent an XML Schema simpleType enumeration. The input file to the source code generator is an XML Schema 2. Castor Forums.

Mailing Lists. Using XML. Source Generator. Schema Support. XML Mapping. Using JDO. JDO Config. JDO Mapping. Other Features. Long Trans. Nested Attrs. Pooling Examples.

The Examples. JDO Tests. XML Tests. Full JavaDoc. As of release 1. For the time being, Castor will support two modes for code generation, i. Default will be the legacy mode; this will be changed with a later release of Castor. As we consider the code stable enough for a major release, we do encourage users to use the new Velocity-based mode and to provide us with valuable feedback.

Please note that we have changed the mechanics of changing the JClass printing type between releases 1. In order to have these additional methods generated as shown above, please override the following code generator property in a custom castorbuilder. Old releases. Release 1. Reference guide. Maven 2 support. Maven 2 archetypes. Recent HTML changes. News Archive. RSS news feed. Mailing Lists. Continuous builds. Spring ORM support. Spring XML factories.

WS frameworks. XML Code Generator. First steps. Using JDO. JDO Config. JDO Mapping. JDO Examples. Other Features. Schema generator. Long Trans. Nested Attrs. Pooling Examples. Best practice. Using DDL Generator. Ant task. Type Mapping. The Examples. JDO Tests. XML Tests. User stories. Status, Todo. Project Name. Forces the code generator to create 'old' Java 1.