Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "EclipseLink/Development/Dynamic"

(→‎Design)
(→‎Issues and Current Limitations)
Line 56: Line 56:
 
# [[EclipseLink/Development/Dynamic/Design_NativeXML | Native XML Configuration]] - deployment/sessions XML usage
 
# [[EclipseLink/Development/Dynamic/Design_NativeXML | Native XML Configuration]] - deployment/sessions XML usage
 
# [[EclipseLink/Development/Dynamic/Design_RuntimeDefinition | Defining/Modifying/Removing dynamic entity types at runtime]]
 
# [[EclipseLink/Development/Dynamic/Design_RuntimeDefinition | Defining/Modifying/Removing dynamic entity types at runtime]]
−
 
−
==Issues and Current Limitations ==
 
−
In order to control the scope of this feature the following limitations are listed here as potential future enhancements.
 
−
* <b>Fixed Base Class</b>: all generated classes sub-class DynamicEntityImpl; there are use-cases that require different base class, possibly user-provided
 
−
* <b>Mapping support</b>: This feature does not support all mapping types - missing:
 
−
** Inheritance - required by JPA2 meta-data
 
−
** Embedded/EmbeddedId
 
−
** Composite primary keys
 
−
* <b>Hybrid Classes</b>: Similar to the '''Fixed Base Class''' issue, in the future developers may want the ability to combine static java classes with one or more attributes accessed dynamically.
 
−
* <b>Mis-matched APIs</b>: (from Requirements above) Ability to use dynamic persistence within SDO to share common infrastructure
 
−
<source lang="java5">
 
−
public interface DataObject {
 
−
 
−
    void set(String s, Object o);
 
−
 
−
}
 
−
public interface DynamicEntity {
 
−
 
−
    public DynamicEntity set(String s, Object o);
 
−
 
−
}
 
−
public class BaseEntityImpl {
 
−
 
−
    public Object set(String s, Object o) {
 
−
 
−
}
 
−
public class SDOBaseEntityImpl extends BaseEntityImpl implements DataObject {
 
−
 
−
    public void set(String s, Object o) {
 
−
          ^^^^^
 
−
          return type is incompatible with BaseEntityImpl.set
 
−
}
 
−
</source>
 
−
* <b>Property vs. Path</b>: from SDO work, ability to <b><i>navigate</i></b> to an attribute via XPath expression '/a/b/c' is powerful - should look at POJO-style navigation: 'address.city.street.direction'
 
−
* <b>Store mechanism</b>: should it be abstracted to an interface, as in SDO?
 
−
** What about alternate store implementations, such as a HashMap?
 
−
* <b>Live Meta-data</b>: XML meta-data must work 'live' without (some) classes as runtime dynamic creation of new classes can occur long after the meta-data is parsed.
 
−
* <b>DRY (<u>D</u>on't <u>R</u>epeat <u>Y</u>ourself)</b>: others in Java community have done similar things (Groovy, JRuby); should leverage expertise so as to not repeat past mistakes
 
−
** Mechanism in Java7/MLVM <br />
 
−
[http://jcp.org/en/jsr/detail?id=292 JSR-292 (Supporting Dynamically Typed Languages on the Java &trade; Platform)] introduces a new type of
 
−
classloader, <code>java.dyn.AnonymousClassLoader</code>. The <code>AnonymousClassLoader</code> class is designed to solve two problems:
 
−
# Generating many classes with similar bytecode and only minor changes is very inefficient, wasting a lot of precious memory.
 
−
# Generated bytecode must be contained in a class, which must be contained in a ClassLoader, which keeps a hard reference to the class; as a result, generated classes are rarely eligible for garbage collection, thus leading to memory issues (specifically, <code>java.lang.OutOfMemoryError</code><tt>: PermGen space error</tt>)
 
−
 
−
First, classes loaded by <code>AnonymousClassLoader</code> are not given full-fledged symbolic names in the global symbol tables; they're given rough numeric identifiers. They are effectively anonymized, allowing much more freedom to generate them at will, since naming conflicts essentially do not happen.
 
−
 
−
Second, the classes are loaded without a parent ClassLoader, so there's no overprotective mother keeping them on a short leash. When the last normal references to the class disappear, it's eligible for garbage collection like any other object.
 
−
 
−
Third, it provides a mechanism whereby an existing class can be loaded and slightly modified, producing a new class with those modifications but sharing the rest of its structure and data.
 

Revision as of 12:31, 10 September 2009

EclipseLink Dynamic Persistence

This page captures the functional requirements and design of a dynamic persistence solution that will allow consumers to specify their mappings. The purpose of dynamic persistence is to enable simplified data access where only mapping information is required and no concrete Java model is required.

The work is being tracked by bug 200045 and is scheduled for inclusion in EclipseLink 1.2

Terminology

Dynamic Persistence is defined as the ability to create a dynamic persistent entity and use it within an application without a-priori the entity's Java .class being present on the classpath (or in some .jar/.war archive).

The purpose of Dynamic Persistence is to enable simplified data access where only mapping information is required and no concrete Java model is required. This allows applications with dynamic storage requirements to avoid coupling to static classes or require specialized handling of new types. The application uses standard EclipseLink APIs to read, create, modify, and remove dynamic persistent entities from their data stores based on types that are either defined in XML mapping files or are constructed within the running application.


Configuration

Static Configuration

A static configuration defines the dynamic persistent entity's structure and mappings in XML packaged with the application. This is used when the entity is generated before/during deployment and no runtime alteration of its structure is required.

Dynamic Configuration

A dynamic configuration defines the dynamic persistent entity's structure and mappings at runtime, as part of the running application.

Functional Requirements

  1. JPA (ORM)
    1. Support for defining dynamic types using deployment XML (with or without sessions.xml) with EclipseLink native ORM API
    2. Support for defining dynamic types using deployment XML with sessions.xml with EclipseLink JPA using PU properties to specify sessions.xml location and session name
    3. Support for defining dynamic entities at runtime for use with EclipseLink native ORM API
    4. Support for defining dynamic entities at runtime for use with EclipseLink JPA
    5. Support for removal of a dynamic type - removing the descriptor and any entity caching
    6. Support for heterogeneous models where some entity types are persistent and some are dynamic including relationships between these

Limitations

This functionality is planned for EclipseLink 1.2.0 and for this release the following limitations in the use of dynamic persistence are known

  1. JPA/ORM Configuration
    1. Support will NOT be available for usage of JPA's orm.xml or eclipselink-orm.xml. This will require the attribute-classification to be added to the eclipselink-orm XSD and the metadata processing to support trusting this classification instead of accessing the attribute type from the entity class.
      • bug 241659: Add support to disable class validation in JPA metadata processing -
      • bug 267217: Add Named Access Type to EclipseLink ORM - enabling ValueAccessor config directly
    2. There will be no support for dynamic entity types having any static state. This means you cannot have a static class with additional dynamic attributes or a static entity superclass or mapped superclass
  2. MOXy - Not supported in 1.2.0 but planned for 2.0.0
    1. Support for defining dynamic types using deployment XML with sessions.xml to create a native XML Context
    2. Support for defining dynamic types using deployment XML with sessions.xml to create a JAXB Context
  3. JPA/ORM with MOXy - Not supported in 1.2.0 but planned for 2.0.0
    1. Support all of the JPA/ORM c0nfiguration options above with additional support for native/JAXB MOXy mappings of the same dynamic entities
      • The MOXy mappings are limited to be a subset of the JPA/ORM mappings
  4. DBWS - Not supported in 1.2.0 but planned for 2.0.0
    1. Upgrade the DBWS runtime to use the common DynamicClassLoader and DynamicClassWriter
    2. If possible share a common base class and support for MOXy with JPA
  5. SDO - Not supported in 1.2.0 but planned for 2.0.0
    1. Upgrade the SDO runtime for dynamic data objects to use the common DynamicClassLoader and DynamicClassWriter
      • SDO will require its own base class with a pluggable value-store as well as an extended DynamicClassWriter to handle the additional interfaces necessary

Incubator Exit Criteria

In order to exit the incubator and become part of EclipseLink proper, we must get consensus on the usage of this functionality and it must be able to function as the base dynamic solution for majority of components.

Design

The design of this new public functionality of EclipseLink is based on existing solutions consumers have used. These existing customers include Oracle BPEL/ESB, EclipseLink DBWS, and EclipseLink SDO. The design of this feature is divided into several pieces each described on their own page:

  1. Dynamic Class Creation - How EclispeLink will support creating classes
  2. Public API for runtime JPA and Native ORM Usage
  3. Native XML Configuration - deployment/sessions XML usage
  4. Defining/Modifying/Removing dynamic entity types at runtime
Retrieved from "https://wiki.eclipse.org/index.php?title=EclipseLink/Development/Dynamic&oldid=170506"

Back to the top