Jump to: navigation, search

Difference between revisions of "EclipseLink/Development/OSGi"

(Requirements)
m (EclipseLink OSGi)
 
(37 intermediate revisions by 6 users not shown)
Line 1: Line 1:
This page is focussed on capturing how EclipseLink will be developed and used for an OSGi (Equinox) environment.
+
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 will be required.
+
  
 
== Requirements ==
 
== Requirements ==
  
# Provide EclipseLink bundles that are easy to use within other Eclipse projects and RCP applications  
+
# Provide EclipseLink bundles that are easy to use within other OSGi applications, Eclipse projects, and RCP applications.
# Provide EclipseLink JAR files that enabled Java SE and EE 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. The usage of EclipseLink JPA should not force the usage of EclipseLink's JAXB
+
# 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.0M2 EclipseLink does not make OSGi/Equinox bundles available. This page is tracking the requirements, proposals, and discussion as to how EclipseLink can most effectively be bundled.
+
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].
  
== Proposals ==
+
== 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.
  
''' Bundles:'''
+
== Future ==
* '''org.eclipse.persistence.foundation'''
+
* 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 using ElcipseLink-ORM.XML or API
+
* A service based approach to obtaining JDBC Drivers.
** Native Object-XML API using native XML mapping file or API configuration
+
** 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
** Support for partial and complete EclipseLink-ORM.XML extensions of JPA
+
 
* '''org.eclipse.persistence.moxy'''
 
* '''org.eclipse.persistence.moxy'''
 
** JAXB 2.0 using annotations
 
** JAXB 2.0 using annotations
Line 28: Line 42:
 
* '''org.eclipse.persistence.sdo'''
 
* '''org.eclipse.persistence.sdo'''
 
** SDO 2.1 support
 
** SDO 2.1 support
* '''org.eclipse.persistence.eis'''
+
* '''org.eclipse.persistence.antlr'''
** Native Object-EIS/JCA using native XML mapping file or API configuration
+
** Repackaged ANTLR library for JP QL parsing.
 
+
* '''org.eclipse.persistence.asm'''
=== Proposal: Bundle Components ===
+
** Repackaged ASM library for byte code weaving.
 
+
* '''org.eclipse.persistence.oracle'''
This proposal refers to making parallel bundle PDE projects which expose the existing functionality from the Java projects.
+
** Oracle database platform classes.
 
+
=== Proposal: Use PDE for Component Projects ===
+
 
+
Convert the existing Java projects into PDE projects.
+
 
+
== Dependent Bundles ==
+
 
+
=== JPA ===
+
  
''QUESTION'': Is there any value in having JPA (persistence.jar) available as a separate bundle or is this just part of the API exposed from the '''org.eclipse.persistence.jpa''' bundle?
+
== Open Issues/Areas of Development ==
  
=== JAXB ===
+
* 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.
  
=== SDO ===
+
== Other Initiatives ==
  
== Issues ==
+
* 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]
  
# Current Proof-of-Concept packaging of EclipseLink into bundles has relied upon the Equinox Buddy Classloader extension.  This approach is not portable to other OSGi containers and is therefore not a long term solution.  In his blog, [http://www.aqute.biz/Blog/HomePage Peter Kriens], OSGi Director of Technology, [http://www.osgi.org/blog/2007/06/osgi-and-hibernate.html describes his efforts] to address classloader issues with Hibernate that are similar to those facing EclipseLink in an OSGi environment.  Unfortunately he concludes that future versions of OSGi would require new features to solve the problem elegantly and portably.
+
[[Category:EclipseLink|OSGi]]
# Does packaging EclipseLink into OSGi bundles require the use of an OSGi service approach or is the JPA sufficient?  Bryan Hunt, on the eclipselink-users mailing, list has [http://dev.eclipse.org/mhonarc/lists/eclipselink-users/msg00046.html described what a service based approach would look like].
+
# When dynamic weaving is enabled, EclipseLink will alter Entity classes as they are loaded to introduce a ValueHolder (proxy) for lazy OneToOne relationships.  How can byte code weaving work in an OSGi container?  Support for [http://www.eclipse.org/equinox/incubator/aspects/index.php AspectJ in OSGi and Equinox] may provide some insight or this or even some APIs.
+

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.

Requirements

  1. Provide EclipseLink bundles that are easy to use within other OSGi applications, Eclipse projects, and RCP applications.
  2. Provide EclipseLink bundle jars that can be used in both OSGi and in Java SE and EE environments.
  3. 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

  1. Enable other Eclipse projects and those building Eclipse RCP applications to more easily consume EclipseLink (project MayInstall, EMF Teneo)
  2. Address our stated project goal to define a blue-print for persistence services usage in OSGi
  3. 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