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/2.1/DynamicMOXy/296967"
| Line 18: | Line 18: | ||
== Project overview == | == Project overview == | ||
| − | The goal of this feature is to enable users of EclipseLink JAXB to perform typical JAXB operations without having real .class files available for their domain objects. Users will pass in some form of metadata (EclipseLink | + | The goal of this feature is to enable users of EclipseLink JAXB to perform typical JAXB operations without having real .class files available for their domain objects. Users will pass in some form of metadata (EclipseLink Deployment XML or <code>eclipselink-oxm.xml</code>) to our <code>JAXBContextFactory</code>, and this metadata will be used to construct <code>DynamicEntity</code> objects representing the domain classes. |
The ultimate purpose of this feature is to support an end-to-end JPA<->JAXB solution. EclipseLink JPA already has some support for Dynamic Persistence and this work will provide a path from Dynamic JPA to JAXB. | The ultimate purpose of this feature is to support an end-to-end JPA<->JAXB solution. EclipseLink JPA already has some support for Dynamic Persistence and this work will provide a path from Dynamic JPA to JAXB. | ||
| Line 34: | Line 34: | ||
=== Dynamic Persistence === | === Dynamic Persistence === | ||
| − | The core of this feature is the Dynamic Persistence support that was initially added for JPA (found in org.eclipse.persistence.dynamic). To obtain a "dynamic" project (i.e. one that maps to classes that were generated in-memory), a "dry" project (one that does not have Java Classes specified, only class names) is passed to the DynamicTypeBuilder, passing in an instance of DynamicClassLoader: | + | The core of this feature is the Dynamic Persistence support that was initially added for JPA (found in <code>org.eclipse.persistence.dynamic</code>). To obtain a "dynamic" project (i.e. one that maps to classes that were generated in-memory), a "dry" project (one that does not have Java Classes specified, only class names) is passed to the <code>DynamicTypeBuilder</code>, passing in an instance of <code>DynamicClassLoader</code>, which does the work of building the in-memory classes: |
<source lang="java5"> | <source lang="java5"> | ||
| Line 41: | Line 41: | ||
</source> | </source> | ||
| − | When this project is used to unmarshall XML documents, the objects that are returned by EclipseLink will be subclasses of DynamicEntity. DynamicEntities offer a simple get(propertyName) / set(propertyName, propertyValue) API to manipulate their data: | + | When this project is used to unmarshall XML documents, the objects that are returned by EclipseLink will be subclasses of <code>DynamicEntity</code>. <code>DynamicEntities</code> offer a simple <code>get(propertyName)</code> / <code>set(propertyName, propertyValue)</code> API to manipulate their data: |
<source lang="java5"> | <source lang="java5"> | ||
Revision as of 17:21, 4 December 2009
Design Specification: MOXy support for Dynamic Persistence
Document History
| Date | Author | Version Description & Notes |
|---|---|---|
| 091204 | Rick Barkhouse |
Project overview
The goal of this feature is to enable users of EclipseLink JAXB to perform typical JAXB operations without having real .class files available for their domain objects. Users will pass in some form of metadata (EclipseLink Deployment XML or eclipselink-oxm.xml) to our JAXBContextFactory, and this metadata will be used to construct DynamicEntity objects representing the domain classes.
The ultimate purpose of this feature is to support an end-to-end JPA<->JAXB solution. EclipseLink JPA already has some support for Dynamic Persistence and this work will provide a path from Dynamic JPA to JAXB.
Goals:
- Bootstrapping of JAXB context with metadata and no class files
- Support adding arbitrary properties/mappings at run time, after initialization has been performed
Some initial groundwork was included in EclipseLink 2.0, more information is available here.
Concepts
Dynamic Persistence
The core of this feature is the Dynamic Persistence support that was initially added for JPA (found in org.eclipse.persistence.dynamic). To obtain a "dynamic" project (i.e. one that maps to classes that were generated in-memory), a "dry" project (one that does not have Java Classes specified, only class names) is passed to the DynamicTypeBuilder, passing in an instance of DynamicClassLoader, which does the work of building the in-memory classes:
InputStream metadata = ... Project dynamicProject = DynamicTypeBuilder.loadDynamicProject(inputStream, null, new DynamicClassLoader());
When this project is used to unmarshall XML documents, the objects that are returned by EclipseLink will be subclasses of DynamicEntity. DynamicEntities offer a simple get(propertyName) / set(propertyName, propertyValue) API to manipulate their data:
DynamicEntity dynamicEmployee = jaxbContext.createUnmarshaller().unmarshal(instanceDoc); String firstName = dynamicEmp.get("fname"); DynamicEntity dynamicAddress = dynamicEmp.get("address"); ... dynamicEmp.set("lname", "Duggar"); address.set("street", "1001 Duggar Ranch Way");
Requirements
The following sections will expand the goals of this project into more concrete requirements.
Design Constraints
Design / Functionality
Testing
API
GUI
Config files
Documentation
Open Issues
This section lists the open issues that are still pending that must be decided prior to fully implementing this project's requirements.
| Issue # | Owner | Description / Notes |
|---|---|---|
Decisions
This section lists decisions made. These are intended to document the resolution of open issues or constraints added to the project that are important.
| Issue # | Description / Notes | Decision |
|---|---|---|
Future Considerations
During the research for this project the following items were identified as out of scope but are captured here as potential future enhancements. If agreed upon during the review process these should be logged in the bug system.