Latest revision as of 12:38, 25 November 2010

Design Specification: OXM XSD

ER 277920

Document History

Project overview

Goals:

• Support JAXB 2.1 annotations via XML external metadata.
• Support MOXy metadata (used to extend JAXB) via external metadata.
• Support the use of the XML metadata as a means to override metadata specified by annotations.

Note:

• This work will continue past the 2.0 release, ER 293925 will cover the work extending past the 2.0 release.

Concepts

• Although JAXB annotations can be applied independently they are logically linked. For example @XmlList can only be used with XmlElement, XmlAttribute, XmlValue, XmlIDREF. These rules will be enforced through the XML metadata.
• Overriding will be handled at the property level.

Requirements

The following sections will expand the goals of this project into more concrete requirements.

Design Constraints

JAXB Annotations

The XML should have the same feel as the JAXB annotations.

javax.xml.bind.annotation Javadoc

EclipseLink JPA Metadata

The XML should have the same feel as the equivalent XML for EclipseLink JPA

EclipseLink JPA XSD

EclipseLink MOXy Metadata

The metadata that will be available in EclipseLink 2.0 is outlined below.

Design Phases

JAXB 2.1 annotation support via XML external metadata

This support will be added as outlined in the following phases:

• Phase #1 – Bootstrapping
  • Use EclipseLink external metadata file to provide list of classes
  • Allow basic schema to be generated
• Phase #2 – High Level Metadata
  • Provide core type metadata
• Phase #3 – Containment Mappings
  • Provide support for nested data. The the following MOXy mappings will be utilized:
    • Direct
    • Direct Collection
    • Composite Object
    • Composite Collection
• Phase #4 – Any/Choice Content
  • Provide support for wild card data. The the following MOXy mappings will be utilized:
    • Any
    • Any Collection
    • Any Attribute
• Phase #5 – Reference Mappings
  • Provide support for key based mappings. The the following MOXy mappings will be utilized:
    • Object Reference
    • Collection Reference
• Phase #5.1 – Attachments
  • Provide support for WebService attachments

Design / Functionality

XML Schema

Design Notes

• The XML names are based directly on the corresponding annotation name. The annotation name is lower cased, and hyphens ('-') are used as separators between each word in the name. For example, the annotation XmlJavaTypeAdapter would correspond to xml-java-type-adapter in XML.
• Where applicable xs:all is used instead of xs:sequence, such that specific ordering is not required. This is done to avoid placing an unnecessary requirement on the user.
• To facilitate metadata processing, more specifically to align with MOXy mapping creation, where possible any single valued information (boolean, String, etc.) will be mapped as an attribute in the schema. Other items with multiple values will be mapped as sub-elements.

Annotations to XML

The following table outlines how annotations relate to schema components:

Schema file

The schema file for EclipseLink 2.0 can be found in the eclipselink.jar here: xsd\eclipselink_oxm_2_0.xsd. The JAR can be downloaded on the EclipseLink nightly build page.

XML Bindings

A given XML metadata bindings file will correspond to a single package. This association is made by using the package name for the key in the properties map that is passed in to the JAXBContext. See below for information on boot strapping the JAXBContext. The bindings file may contain information that applies to the entire package, as well as class-specific information. The java-type element is used for a java class. Each java-type may have a number of attributes and elements set (refer to the XML Schema above for more information) as well as zero or more java-attributes. A java-attribute corresponds to a property (field/method). In order to handle various settings applicable to a given property, a number of java-attribute extensions exist:

• xml-java-type-adapter
• xml-transient
• xml-any-attribute
• xml-attribute
• xml-any-element
• xml-element
• xml-value

Example

Following is a simple example showing java-attribute use in a bindings file. Here, the 'id' property is set as an attribute and made required, the 'name' property is renamed 'employee-name', and the 'thing' property is set transient. Note that the 'java-attribute' attribute in each corresponds to the field name or method name (for methods, is/set/get is stripped off and the first letter is lower cased).

org.example.Employee.java

package org.example;
 
public class Employee {
    public int id;
    public String name;
    private Object theThing;
 
    public void setThing(Object theThing) {
        this.theThing = theThing;
    }
    public Object getThing() { 
        return theThing;
    }
}

eclipselink-oxm.xml

<?xml version="1.0" encoding="US-ASCII"?>
<xml-bindings xmlns="http://www.eclipse.org/eclipselink/xsds/persistence/oxm">
  <java-types>
    <java-type name="org.example.Employee">
      <java-attributes>
        <xml-attribute java-attribute="id" required="true" />
        <xml-element java-attribute="name" name="employee-name" />
        <xml-transient java-attribute="thing" />
      </java-attributes>
    </java-type>
  </java-types>
</xml-bindings>

Boot Strapping

Specifying the Externalized Metadata File

The externalized metadata file (one per package) can be passed in through a property when creating the JAXBContext. Prior to EclipseLink 2.2 the only supported input format for specifying the externalized metadata file(s) was Map<String, Source>. For EclipseLink 2.2, however, the following will be supported:

• Map<String, Object>
  • String is the package name
  • Object is one of File, Reader, etc. listed below
• List<Object>
  • Object is one of File, Reader, etc. listed below
  • Package name is set via package-name attribute on xml-bindings element in the bindings file.
• One of:
  • java.io.File
  • java.io.InputStream
  • java.io.Reader
  • java.net.URL
  • javax.xml.stream.XMLEventReader
  • javax.xml.stream.XMLStreamReader
  • javax.xml.transform.Source
  • org.w3c.dom.Node
  • org.xml.sax.InputSource
  • --
  • Package name is set via package-name attribute on xml-bindings element in the bindings file.

Example: Map<String, Object>

InputStream employeeExternalizedMetadata = 
     aClassLoader.getResourceAsStream("org/example/employee/metadata.xml";
InputStream customerExternalizedMetadata = 
     aClassLoader.getResourceAsStream("org/example/customer/metadata.xml";
 
HashMap<String, Source> metadataSourceMap = new HashMap<String, Source>();
metadataSourceMap.put("org.example.employee", new StreamSource(employeeExternalizedMetadata));
metadataSourceMap.put("org.example.customer", new StreamSource(customerExternalizedMetadata));
 
Map<String, Map<String, Source>> properties = new HashMap<String, Map<String, Source>>();
properties.put("eclipselink-oxm-xml", metadataSourceMap);
 
JAXBContext.newInstance("org.example.customer:org.example.employee", aClassLoader, properties);

Following is an example of how to pass in the property when creating the JAXBContext based on an array of classes:

Class[] classes = new Class[2];
classes[0] = Customer.class;
classes[1] = Employee.class;
JAXBContext.newInstance(classes, properties);

Example: List<Object>

List<Object> inputFiles = new ArrayList<Object>();
inputFiles.add(new java.io.File("org/example/employee/metadata.xml"));
inputFiles.add(new java.io.FileInputStream("org/example/customer/metadata.xml"));
 
Map<String, Object> properties = new HashMap<String, Object>();
properties.put("eclipselink-oxm-xml", inputFiles);
 
Class[] classes = new Class[] { org.example.employee.Employee.class, org.example.customer.Customer.class };
 
JAXBContext.newInstance(classes, properties);

Following shows sample externalized metadata files for Employee and Customer:

org/example/employee/metadata.xml

<?xml version="1.0" encoding="US-ASCII"?>
<xml-bindings xmlns="http://www.eclipse.org/eclipselink/xsds/persistence/oxm" package-name="org.example.employee">
    <java-types>
        <java-type name="Employee">
            <xml-root-element name="emp"/>
            <java-attributes>
                <xml-attribute java-attribute="id"/>
            </java-attributes>
        </java-type>
    </java-types>
</xml-bindings>

org/example/customer/metadata.xml

<?xml version="1.0" encoding="US-ASCII"?>
<xml-bindings xmlns="http://www.eclipse.org/eclipselink/xsds/persistence/oxm" package-name="org.example.customer">
    <java-types>
        <java-type name="Customer">
            <xml-root-element name="cust"/>
            <java-attributes>
                <xml-attribute java-attribute="id"/>
            </java-attributes>
        </java-type>
    </java-types>
</xml-bindings>

Example: java.io.File

Map<String, Object> properties = new HashMap<String, Object>();
properties.put("eclipselink-oxm-xml", new java.io.File("org/example/customer/metadata.xml")));
 
Class[] classes = new Class[] { org.example.customer.Customer.class };
 
JAXBContext.newInstance(classes, properties);

Following shows a sample externalized metadata file for Customer:

org/example/customer/metadata.xml

<?xml version="1.0" encoding="US-ASCII"?>
<xml-bindings xmlns="http://www.eclipse.org/eclipselink/xsds/persistence/oxm" package-name="org.example.customer">
    <java-types>
        <java-type name="Customer">
            <xml-root-element name="cust"/>
            <java-attributes>
                <xml-attribute java-attribute="id"/>
            </java-attributes>
        </java-type>
    </java-types>
</xml-bindings>

Testing

API

GUI

Config files

Documentation

Open Issues

This section lists the open issues that are still pending that must be decided prior to fully implementing this project's requirements.

Decisions

This section lists decisions made. These are intended to document the resolution of open issues or constraints added to the project that are important.

Future Considerations

During the research for this project the following items were identified as out of scope but are captured here as potential future enhancements. If agreed upon during the review process these should be logged in the bug system.