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.
Difference between revisions of "EclipseLink/Development/DBWS/oNmMetadata"
(New page: TBD) |
|||
Line 1: | Line 1: | ||
− | + | == '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 : | ||
+ | <source> | ||
+ | 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. |
Revision as of 15:49, 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 : 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 :
Invalid language.
You need to specify a language like this: <source lang="html4strict">...</source>
Supported languages for syntax highlighting:
4cs, 6502acme, 6502kickass, 6502tasm, 68000devpac, abap, actionscript, actionscript3, ada, algol68, apache, applescript, apt_sources, arm, asm, asp, asymptote, autoconf, autohotkey, autoit, avisynth, awk, bascomavr, bash, basic4gl, bf, bibtex, blitzbasic, bnf, boo, c, c_loadrunner, c_mac, caddcl, cadlisp, cfdg, cfm, chaiscript, cil, clojure, cmake, cobol, coffeescript, cpp, cpp-qt, csharp, css, cuesheet, d, dcl, dcpu16, dcs, delphi, diff, div, dos, dot, e, ecmascript, eiffel, email, epc, erlang, euphoria, f1, falcon, fo, fortran, freebasic, freeswitch, fsharp, gambas, gdb, genero, genie, gettext, glsl, gml, gnuplot, go, groovy, gwbasic, haskell, haxe, hicest, hq9plus, html4strict, html5, icon, idl, ini, inno, intercal, io, j, java, java5, javascript, jquery, kixtart, klonec, klonecpp, latex, lb, ldif, lisp, llvm, locobasic, logtalk, lolcode, lotusformulas, lotusscript, lscript, lsl2, lua, m68k, magiksf, make, mapbasic, matlab, mirc, mmix, modula2, modula3, mpasm, mxml, mysql, nagios, netrexx, newlisp, nsis, oberon2, objc, objeck, ocaml, ocaml-brief, octave, oobas, oorexx, oracle11, oracle8, otj, oxygene, oz, parasail, parigp, pascal, pcre, per, perl, perl6, pf, php, php-brief, pic16, pike, pixelbender, pli, plsql, postgresql, povray, powerbuilder, powershell, proftpd, progress, prolog, properties, providex, purebasic, pycon, pys60, python, q, qbasic, rails, rebol, reg, rexx, robots, rpmspec, rsplus, ruby, sas, scala, scheme, scilab, sdlbasic, smalltalk, smarty, spark, sparql, sql, stonescript, systemverilog, tcl, teraterm, text, thinbasic, tsql, typoscript, unicon, upc, urbi, uscript, vala, vb, vbnet, vedit, verilog, vhdl, vim, visualfoxpro, visualprolog, whitespace, whois, winbatch, xbasic, xml, xorg_conf, xpp, yaml, z80, zxbasic
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.