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/DesignDocs/322284"
(→Open Issues) |
(→Decisions) |
||
Line 62: | Line 62: | ||
! Decision | ! Decision | ||
|- | |- | ||
− | | | + | | \\ |
− | | | + | | \\ |
− | | | + | | \\ |
|} | |} |
Revision as of 10:00, 17 August 2010
Dynamic JAXB: Support For Specifying The Collection Type Via XML metadata
This design page will capture design and decisions involving adding support for specifying a collection class via XML metadata. This support is required by Dynamic JAXB.
Problem
For Dynamic JAXB, there must be a way of specifying the class of the collection being used, such that the underlying dynamic JavaModel can be built correctly. We currently support setting the type via type
attribute (based on the corresponding JAXB annotation) as follows:
<?xml version="1.0" encoding="US-ASCII"?> <xml-bindings xmlns="http://www.eclipse.org/eclipselink/xsds/persistence/oxm"> <java-types> <java-type name="org.example.Employee"> <java-attributes> <xml-element java-attribute="zipCodes" type="java.lang.Integer"/> </java-attributes> </java-type> </java-types> </xml-bindings>
This level of support will NOT allow us to configure, for example, the following dynamically:
package org.example; public class Employee { java.util.List<Integer> zipCodes; }
JPA Metadata
Dynamic JPA allows setting the container class via attribute-type
attribute, and the property type via target-entity
, as follows:
<one-to-many name="phoneNumbers" mapped-by="owner" target-entity="PhoneNumber" attribute-type="java.util.List" />
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 |
---|---|---|
1 | D.McCann | For MOXy, the the property type is set via type attribute. Adding an attribute named attribute-type to support setting the container class would be confusing for users. Should a different name be used, and if so, what should it be named? Possible names include container-class and container-type .
|
2 | D.McCann | Should the container type be limited to interfaces (Map, List, Set) via enumeration? |
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 |
---|---|---|
\\ | \\ | \\ |