Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
EclipseLink/Development/DBWS/oNmMetadata
'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 : i) an in-memory instance of a meta-data model can be built solely from simple types without domain model POJO classes on the classpath ii) the model can be written to disk as an 'oNm.xml' file (where N can be: 'r '== JPA-style || 'x' == JAXB3) iii) an 'oNm.xml' file can be read in (from disk, stream, URL, etc) without domain model POJO classes on the classpath iv) a meta-data model can be converted to 'real' runtime artifacts along with a custom classloader that dynamically generates domain model POJO classes v) 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; } ... <source> 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.