Difference between revisions of "EclipseLink/Development/DBWS/oNmMetadata"

Revision as of 15:51, 21 May 2009

'orm.xml' and 'oxm.xml' Metadata

At some point in the future, DBWS would like to switch from using 'native' EclipseLink meta-data (a.k.a. project xml) to using JPA-style 'orm.xml' and JAXB3 'oxm.xml' meta-data (once Blaise gets around to building JAXB3 for me!)

The DBWS requirements for a meta-data model are different from 'typical' usage - DBWS does not expose any domain model POJO classes; therefore, classes are dynamically generated at runtime when the service is initialized. Thus the DBWS utility builds meta-data model objects at design-time without any domain model POJO classes on the classpath - the only types used in describing the meta-data are Strings, booleans, enums and numbers.

High-level Requirements :

• an in-memory instance of a meta-data model can be built solely from simple types without domain model POJO classes on the classpath
• the model can be written to disk as an 'oNm.xml' file (where N can be: 'r '== JPA-style || 'x' == JAXB3)
• an 'oNm.xml' file can be read in (from disk, stream, URL, etc) without domain model POJO classes on the classpath
• a meta-data model can be converted to 'real' runtime artifacts along with a custom classloader that dynamically generates domain model POJO classes
• a generated domain model POJO class must work when mapped via both an orm and oxm metadata model.

Thus a row can be retrieved from the database, built into an object and serialized to XML - and vice-versa.

Dynamic generation of domain model POJO classes Currently, a 'least-effort' code-gen strategy is used - all generated classes are a sub-class of a 'helper' class o.e.p.internal.dynamicpersist.BaseEntity:

public class BaseEntity implements PersistenceEntity, Cloneable {
 
    protected Object[] fields; // BaseEntities only deal with Objects, never
                                // primitives
 
    protected BaseEntity() {
    }
 
    public Object get(int i) {
        return fields[i];
    }
    public void set(int i, Object aFieldValue) {
        fields[i] = aFieldValue;
    }
...

Member fields are uniquely identified by their index into the fields Object array - this works with the EclipseLink native meta-model via the use of custom o.e.p.mappings.AttributeAccessor's that translate requests for an object's attribute into the correct fields index (SDO uses a similar strategy, but different impl). The custom accessors are added to the Project after it is built from the meta-data and custom classloader, but before it is logged in .

It is unclear if use of the public JPA runtime artifacts (javax.persistence.EntityManagerFactory, javax.persistence.EntityManager) prevents the above 'trick' (their lifecycle may not be able to distinguish the after-build-but-before-login point in time, or access to the granularity of individual mapping's accessors may not be available). An alternate code-gen strategy - with actual member fields - may be required.