Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "EclipseLink/Development/OSGi"
< EclipseLink | Development
(→JPA) |
m (EclipseLink OSGi) |
||
| (43 intermediate revisions by 6 users not shown) | |||
| Line 1: | Line 1: | ||
| − | This page is focussed on capturing how EclipseLink | + | This page is focussed on capturing how EclipseLink can be used in OSGi. The goal of this effort is to produce OSGi bundles for use in any OSGi application, other Eclipse projects, and RCP applications. While the focus is on OSGi it is understood that Equinox extensions may also be provided. |
| − | + | ||
| − | The goal of this effort is to produce OSGi bundles for use in other Eclipse projects and RCP applications. While the focus is on OSGi it is understood that Equinox extensions | + | |
== Requirements == | == Requirements == | ||
| − | # | + | # Provide EclipseLink bundles that are easy to use within other OSGi applications, Eclipse projects, and RCP applications. |
| − | # Ensure that the bundles offer flexibility in their independent usage. | + | # Provide EclipseLink bundle jars that can be used in both OSGi and in Java SE and EE environments. |
| + | # Ensure that the bundles offer flexibility in their independent usage. For example, the usage of EclipseLink JPA should not force the usage of EclipseLink's JAXB implementation. | ||
| + | |||
| + | == Rationale == | ||
| + | |||
| + | # Enable other Eclipse projects and those building Eclipse RCP applications to more easily consume EclipseLink (project MayInstall, EMF Teneo) | ||
| + | # Address our stated project goal to define a blue-print for persistence services usage in OSGi | ||
| + | # As a member project of the proposed top level Runtime project centered around Equinox we must be usable in an Equinox environment | ||
== Current Status == | == Current Status == | ||
| − | As of 1. | + | As of release 1.0 EclipseLink is packaged as a set of bundles for use in OSGi as well as a set of jars for Java SE/EE usage. They can be downloaded from the [http://www.eclipse.org/eclipselink/downloads EclipseLink Download page]. |
| − | == | + | == Features == |
| + | * An implementation of javax.persistence.Persistence that provides a pluggable mechanism for JPA Provider resolution. This mechanism is open and supports the use of JPA providers other than EclipseLink in an OSGi environment. | ||
| + | * Applications requiring JPA only require the javax.persistence bundle, not EclipseLink (unless using EclipseLink extensions). EclipseLink JPA is discovered through the OSGi Service Registry. | ||
| + | * JAXB and SDO implementations are available as OSGi bundles. | ||
| − | + | == Future == | |
| − | * '''org.eclipse.persistence. | + | * To avoid EclipseLink foundation having compile time dependencies on specific database or server platform APIs, such classes are contained in separate bundles. For example, in SVN, Oracle database platform classes are housed in the eclipselink.extension.oracle project. In OSGi, classloader restrictions mean that EclipseLink foundation classes cannot directly load database platform classes identified in persistence.xml properties. Through a service based approach, EclipseLink will obtain the identified platform classes from a service. |
| − | ** Native object-relational persistence | + | * A service based approach to obtaining JDBC Drivers. |
| − | ** Native Object-XML API | + | ** The rationale is similar to that for database and server platforms--classloader limitations do not make it possible for EclipseLink to see classes unless it explicitly pre-reqs the bundle containing a driver. This is not extensible. The OSGi solution to this problem (see OSGi RFC 122) is for the drivers to be registered as services and to look them up when needed. |
| + | |||
| + | === EclipseLink Bundles === | ||
| + | |||
| + | There are a number of Java standard API libraries packaged as bundles and included with EclipseLink. EclipseLink is itself packaged into the following bundles: | ||
| + | |||
| + | * '''org.eclipse.persistence.core''' | ||
| + | ** Native object-relational persistence API(underlies JPA implementation) | ||
| + | ** Native Object-XML API (underlies JAXB and SDO implementations) | ||
* '''org.eclipse.persistence.jpa''' | * '''org.eclipse.persistence.jpa''' | ||
** JPA 1.0 functionality | ** JPA 1.0 functionality | ||
| − | ** Extended JPA support using EclipseLink's annotations, PU properties, and query hints | + | ** Extended JPA support using EclipseLink's annotations, PU properties, mapping file extensions, and query hints |
| − | + | ||
* '''org.eclipse.persistence.moxy''' | * '''org.eclipse.persistence.moxy''' | ||
** JAXB 2.0 using annotations | ** JAXB 2.0 using annotations | ||
| Line 27: | Line 42: | ||
* '''org.eclipse.persistence.sdo''' | * '''org.eclipse.persistence.sdo''' | ||
** SDO 2.1 support | ** SDO 2.1 support | ||
| − | * '''org.eclipse.persistence. | + | * '''org.eclipse.persistence.antlr''' |
| − | ** | + | ** Repackaged ANTLR library for JP QL parsing. |
| − | + | * '''org.eclipse.persistence.asm''' | |
| − | + | ** Repackaged ASM library for byte code weaving. | |
| − | + | * '''org.eclipse.persistence.oracle''' | |
| − | + | ** Oracle database platform classes. | |
| − | == | + | == Open Issues/Areas of Development == |
| − | + | * Dynamic Byte Code Weaving | |
| + | ** When dynamic byte code weaving is enabled, EclipseLink will alter Entity classes as they are loaded to introduce a proxy (ValueHolder) for lazy OneToOne and ManyToOne relationships as well as fetch-groups and change tracking. | ||
| + | ** As of EclipseLink 1.0 there is some support for byte code weaving in Equinox. An example will be put up on the wiki. | ||
| + | ** Discussions have been had with the team providing [http://www.eclipse.org/equinox/incubator/aspects/index.php AspectJ in OSGi and Equinox] to see if EclipseLink can leverage their work. Initial investigations suggest it may be possible but it would require significant engineering work. | ||
| − | + | == Other Initiatives == | |
| − | + | * Proposed Persistence Service and Extensions | |
| + | ** There is a proposal to provide support for configuring EclipseLink JPA using the Equinox plugin extension framework | ||
| + | ** [http://wiki.eclipse.org/EclipseLink/Development/OSGi/ServiceProposal Proposal Page] | ||
| − | + | [[Category:EclipseLink|OSGi]] | |
Latest revision as of 12:19, 3 November 2008
This page is focussed on capturing how EclipseLink can be used in OSGi. The goal of this effort is to produce OSGi bundles for use in any OSGi application, other Eclipse projects, and RCP applications. While the focus is on OSGi it is understood that Equinox extensions may also be provided.
Contents
Requirements
- Provide EclipseLink bundles that are easy to use within other OSGi applications, Eclipse projects, and RCP applications.
- Provide EclipseLink bundle jars that can be used in both OSGi and in Java SE and EE environments.
- Ensure that the bundles offer flexibility in their independent usage. For example, the usage of EclipseLink JPA should not force the usage of EclipseLink's JAXB implementation.
Rationale
- Enable other Eclipse projects and those building Eclipse RCP applications to more easily consume EclipseLink (project MayInstall, EMF Teneo)
- Address our stated project goal to define a blue-print for persistence services usage in OSGi
- As a member project of the proposed top level Runtime project centered around Equinox we must be usable in an Equinox environment
Current Status
As of release 1.0 EclipseLink is packaged as a set of bundles for use in OSGi as well as a set of jars for Java SE/EE usage. They can be downloaded from the EclipseLink Download page.
Features
- An implementation of javax.persistence.Persistence that provides a pluggable mechanism for JPA Provider resolution. This mechanism is open and supports the use of JPA providers other than EclipseLink in an OSGi environment.
- Applications requiring JPA only require the javax.persistence bundle, not EclipseLink (unless using EclipseLink extensions). EclipseLink JPA is discovered through the OSGi Service Registry.
- JAXB and SDO implementations are available as OSGi bundles.
Future
- To avoid EclipseLink foundation having compile time dependencies on specific database or server platform APIs, such classes are contained in separate bundles. For example, in SVN, Oracle database platform classes are housed in the eclipselink.extension.oracle project. In OSGi, classloader restrictions mean that EclipseLink foundation classes cannot directly load database platform classes identified in persistence.xml properties. Through a service based approach, EclipseLink will obtain the identified platform classes from a service.
- A service based approach to obtaining JDBC Drivers.
- The rationale is similar to that for database and server platforms--classloader limitations do not make it possible for EclipseLink to see classes unless it explicitly pre-reqs the bundle containing a driver. This is not extensible. The OSGi solution to this problem (see OSGi RFC 122) is for the drivers to be registered as services and to look them up when needed.
EclipseLink Bundles
There are a number of Java standard API libraries packaged as bundles and included with EclipseLink. EclipseLink is itself packaged into the following bundles:
- org.eclipse.persistence.core
- Native object-relational persistence API(underlies JPA implementation)
- Native Object-XML API (underlies JAXB and SDO implementations)
- org.eclipse.persistence.jpa
- JPA 1.0 functionality
- Extended JPA support using EclipseLink's annotations, PU properties, mapping file extensions, and query hints
- org.eclipse.persistence.moxy
- JAXB 2.0 using annotations
- JAXB 2.0 using native XML mapping file
- org.eclipse.persistence.sdo
- SDO 2.1 support
- org.eclipse.persistence.antlr
- Repackaged ANTLR library for JP QL parsing.
- org.eclipse.persistence.asm
- Repackaged ASM library for byte code weaving.
- org.eclipse.persistence.oracle
- Oracle database platform classes.
Open Issues/Areas of Development
- Dynamic Byte Code Weaving
- When dynamic byte code weaving is enabled, EclipseLink will alter Entity classes as they are loaded to introduce a proxy (ValueHolder) for lazy OneToOne and ManyToOne relationships as well as fetch-groups and change tracking.
- As of EclipseLink 1.0 there is some support for byte code weaving in Equinox. An example will be put up on the wiki.
- Discussions have been had with the team providing AspectJ in OSGi and Equinox to see if EclipseLink can leverage their work. Initial investigations suggest it may be possible but it would require significant engineering work.
Other Initiatives
- Proposed Persistence Service and Extensions
- There is a proposal to provide support for configuring EclipseLink JPA using the Equinox plugin extension framework
- Proposal Page