Latest revision as of 12:15, 21 June 2011

Design Documentation: XML Virtual Access Methods

ER 339381

Currently, EclipseLink MOXy supports the mapping of Java fields and properties to XML. Said another way; in order to map data to XML, the user must have an existing Java field or property to map.

To support multi-tenancy, we will be allowing the user to add additional mappings at runtime. Because these new mappings would not have existing fields / properties on the Java class to map to, we will introduce the concept of virtual properties, where we can instead rely on special get() and set() methods to maintain extension data.

Requirements

1. Users must be able to add new mappings at runtime through EclipseLink OXM
2. Users should be able to add any type of MOXy mapping as virtual property
3. Users must be able to specify that a Java type virtual access methods, using either Annotations or EclipseLink OXM

Configuration

In order to add virtual properties to an entity:

• the Java class must be marked with an @XmlVirtualAccessMethods annotation, or <xml-virtual-access-methods> element in OXM
• the Java class must contain getter and setter methods to access virtual property values
  • public Object get(String propertyName)
  • public void set(String propertyName, Object value)
  • method names are configurable but must have the same method signatures as above

By default, EclipseLink will look for methods named "set" and "get". To customize accessor method names, see Specifying Alternate Accessor Methods.

Annotations

The user can specify that a Java class may hold virtual properties by using the @XmlVirtualAccessMethods annotation:

@Target({TYPE}) 
@Retention(RUNTIME)
public @interface XmlVirtualAccessMethods {
 
    /**
     * (Optional) Defines the name of the method used to retrieve virtual properties.
     */
    String getMethod() default "get";
 
    /**
     * (Optional) Defines the name of the method used to store virtual properties.
     */
    String setMethod() default "set";
 
    /**
     * (Optional) Configure the way that virtual properties will appear in generated schemas.<br><br>
     * <b>XmlExtensibleSchema.NODES</b> (default) - Virtual properties will appear as individual nodes<br>
     * <b>XmlExtensibleSchema.ANY</b> - An XSD &lt;any&gt; element will be written to the schema to 
     * represent all of the defined virtual properties
     */
    XmlVirtualAccessMethodsSchema schema() default XmlVirtualAccessMethodsSchema.NODES;
 
}

public enum XmlVirtualAccessMethodsSchema {
    /**
     * Virtual properties are written to the schema as individual nodes (default).
     */
    NODES,
 
    /**
     * An XML <any> element will be written to the schema to represent all
     * of the defined virtual properties.
     */
    ANY;
}

OXM Metadata

To indicate an extensions field in EclipseLink OXM, the user can specify an xml-extensible element in their metadata file:

eclipselink_oxm_2_3.xsd:

...
<xs:element name="java-type">
   <xs:complexType>
      <xs:all>
         ...
         <xs:element ref="xml-virtual-access-methods" minOccurs="0"/>
         ...
 
...
    <xs:element name="xml-virtual-access-methods">
        <xs:complexType>
            <xs:attribute name="get-method" type="xs:string" default="get" />
            <xs:attribute name="set-method" type="xs:string" default="set" />
            <xs:attribute name="schema" type="xml-virtual-access-methods-schema" default="NODES" />
        </xs:complexType>
    </xs:element>
...

Example

The following domain class is annotated with @XmlVirtualAccessMethods, indicating that it has special accessor methods to handle additional mappings. EclipseLink's default behaviour will look for the methods public Object get(String) and public void set(String, Object) to be the accessors of the virtual property map.

@XmlRootElement
@XmlVirtualAccessMethods
@XmlAccessorType(AccessType.PROPERTY)
public class Customer {
 
   private int id;
 
   private String name;
 
   private Map<String, Object> extensions = new HashMap<String, Object>();
 
   public Object get(String name) {
      return extensions.get(name);
   }
 
   public void set(String name, Object value) {
      extensions.put(name, value);
   }
 
   @XmlAttribute
   public int getId() {
   ...
 
}

The class above can be expressed in EclipseLink OXM metadata as follows:

...
<java-types>
   <java-type name="Customer">
      <xml-virtual-access-methods />
      <java-attributes>
         <xml-attribute java-attribute="id" type="java.lang.Integer" />
         <xml-element java-attribute="name" type="java.lang.String" />
      </java-attributes>
   </java-type>
...

In a secondary metadata file, we will define additional mappings that we would like to add to Customer:

...
<java-types>
    <java-type name="Customer">
        <java-attributes>
            <xml-element java-attribute="discountCode" name="discount-code"
                type="java.lang.String" />
        </java-attributes>
    </java-type>
</java-types>
...

(Note that there is no special configuration needed for additional mappings; they are specified in the same way as "normal" mappings.)

To set the values for these additional mappings, we will use the aforementioned set() method:

InputStream oxm = classLoader.getResourceAsStream("eclipselink-oxm.xml");
Map<String, Object> properties = new HashMap<String, Object>();
properties.put(JAXBContextFactory.ECLIPSELINK_OXM_XML_KEY, oxm);
 
Class[] classes = new Class[] { Customer.class };
JAXBContext ctx = JAXBContext.newInstance(classes, properties);
 
Customer c = new Customer();
c.setName("Dan Swano");
c.set("discountCode", "SIUB372JS7G2IUDS7");
 
ctx.createMarshaller().marshal(e, System.out);

This will produce the following XML:

<customer name="Dan Swano">
   <discount-code>SIUB372JS7G2IUDS7</discount-code>
</customer>

Config Options

Specifying Alternate Accessor Methods

To use different method names as your extensions accessors, specify them using the getMethodName and setMethodName attributes on @XmlExtensible:

@XmlRootElement
@XmlVirtualAccessMethods(getMethod = "getCustomProps", setMethod = "putCustomProps")
@XmlAccessorType(AccessType.FIELD)
public class Customer {
 
   @XmlAttribute
   private int id;
 
   private String name;
 
   @XmlTransient
   private Map<String, Object> extensions;
 
   public Object getCustomProps(String name) {
      if (extensions == null) {
         extensions = new HashMap<String, Object>();
      }
      return extensions.get(name);
   }
 
   public void putCustomProps(String name, Object value) {
      if (extensions == null) {
         extensions = new HashMap<String, Object>();
      }
      extensions.put(name, value);
   }
 
}

In OXM:

...
<java-types>
   <java-type name="Customer">
      <xml-virtual-access-methods get-method="getCustomProps" set-method="putCustomProps" />
      <java-attributes>
         <xml-attribute java-attribute="id" type="java.lang.Integer" />
         <xml-element java-attribute="name" type="java.lang.String" />
      </java-attributes>
   </java-type>
...

Schema Generation Options

If the user generates an XML Schema from the JAXBContext after virtual properties have been added, then the resulting schema will obviously be different from any Schema that may have been used to generate the initial domain objects.

To configure how these new properties should appear in future generated schemas, use the schema attribute on @XmlVirtualAccessMethods.

Virtual Properties as individual Nodes

This is EclipseLink's default behaviour, or can be specified explicitly as an override as follows:

@XmlRootElement
@XmlVirtualAccessMethods(schema = XmlVirtualAccessMethodsSchema.NODES)
@XmlAccessorType(AccessType.FIELD)
public class Customer {
 
   ...

For example:

Original Customer Schema:

<xs:schema ...>
 
    <xs:element name="customer">
        <xs:complexType>
            <xs:sequence>
                <xs:element name="first-name" type="xs:string" />
                <xs:element name="last-name" type="xs:string" />
            </xs:sequence>
        </xs:complexType>
    </xs:element>
 
</xs:schema>

Generated Schema after adding middle-initial and phone-number:

<xs:schema ...>
 
    <xs:element name="customer">
        <xs:complexType>
            <xs:sequence>
                <xs:element name="first-name" type="xs:string" />
                <xs:element name="last-name" type="xs:string" />
                <xs:element name="middle-initial" type="xs:string" />
                <xs:element name="phone-number" type="xs:string" />
            </xs:sequence>
        </xs:complexType>
    </xs:element>
 
</xs:schema>

Virtual Properties in an <any> Element

EclipseLink can also use an <any> element to hold all of the virtual properties in one node:

@XmlRootElement
@XmlVirtualAccessMethods(schema = XmlVirtualAccessMethodsSchema.ANY)
@XmlAccessorType(AccessType.FIELD)
public class Customer {
 
   ...

Taking the example from above, a newly generated schema using this approach would look like:

<xs:schema ...>
 
    <xs:element name="customer">
        <xs:complexType>
            <xs:sequence>
                <xs:element name="first-name" type="xs:string" />
                <xs:element name="last-name" type="xs:string" />
                <xs:any minOccurs="0" />
            </xs:sequence>
        </xs:complexType>
    </xs:element>
 
</xs:schema>

XmlAccessorType and XmlTransient

If you are using an @XmlAccessorType other than AccessType.PROPERTY, you will need to mark your virtual properties Map attribute to be @XmlTransient, to prevent the Map itself from being bound to XML.

@XmlRootElement
@XmlVirtualAccessMethods
@XmlAccessorType(AccessType.FIELD)
public class Customer {
 
   @XmlTransient
   private Map<String, Object> extensions;
   ...

Design

• org.eclipse.persistence.jaxb.compiler.Property
  • A Property will now know if it is virtual
• org.eclipse.persistence.jaxb.compiler.TypeInfo
  • A TypeInfo will now know if it contains virtual properties
• org.eclipse.persistence.jaxb.compiler.XMLProcessor
  • When processing an OXM file, if a Property is encountered (e.g. "foo") that does not have a corresponding property in Java:
    • If the TypeInfo has virtual properties enabled, then create a new "foo" Property, and setup an org.eclipse.persistence.internal.descriptors.VirtualAttributeAccessor for its mapping
    • If the TypeInfo does not virtual properties enabled, a "No such property exists" exception will be thrown

Document History