Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "EclipseLink/Development/OSGi"

(→‎Benefits)
m (EclipseLink OSGi)
 
(12 intermediate revisions by 3 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 may 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 ==
 
== Rationale ==
Line 13: Line 11:
 
# Enable other Eclipse projects and those building Eclipse RCP applications to more easily consume EclipseLink (project MayInstall, EMF Teneo)
 
# 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
 
# 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
+
# 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.0M3 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].
  
−
== Proposal ==
+
== 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.
  
−
To explore the packaging of EclipseLink as OSGi bundles, a branch should be created in the SVN repository.  This branch will provide a safe "sandbox" in which to experiment with different packaging and integration strategies.  It will also provide a way for EclipseLink developers and community members to access, try, and provide feedback on the approach.
+
== 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.
−
The approach to supporting OSGi being proposed includes:
+
−
* Conversion of all EclipseLink projects to PDE projects to support development, debugging, and testing in an OSGi environment.
+
−
** This would require all developers of EclipseLink to be aware of how to develop using PDE rather than directly in JDT (e.g., classpath's defined through required bundles instead of require projects).
+
−
* A bundle containing the JPA specification classes contained in javax.persistence.
+
−
** Modification of javax.persistence.Persistence to introduce a pluggable mechanism for JPA Provider resolution.  The spec provided implementation relies on classpath scanning which doesn't work in an OSGi container.  This would support the use of JPA providers other than EclipseLink in an OSGi environment.
+
−
** Applications requiring JPA would require the javax.persistence bundle, not EclipseLink (unless using EclipseLink extensions).  EclipseLink JPA would be discovered through the OSGi Service Registry.
+
−
* A bundle containing the JAXB specification classes contained in javax.xml.bind.
+
−
** It's expected that a modification to the spec classes similar to those proposed for JPA would be necessary to deal with classloader issues.
+
−
* A service based approach to extending EclipseLink with database and server platforms.
+
−
** 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.
 
* 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.
 
** 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.
  
−
=== Proposed Bundles ===
+
=== EclipseLink Bundles ===
  
−
* '''javax.persistence'''
+
There are a number of Java standard API libraries packaged as bundles and included with EclipseLink. EclipseLink is itself packaged into the following bundles:
−
** Spec classes and interfaces augmented with support for discovering JPA provider services.
+
 
−
*'''javax.xml.bind'''
+
* '''org.eclipse.persistence.core'''
−
** Spec classes and interfaces augmented with support for discovering JAXB provider services.
+
** Native object-relational persistence API(underlies JPA implementation)
−
* '''org.eclipse.persistence.foundation'''
+
** Native Object-XML API (underlies JAXB and SDO implementations)
−
** Native object-relational persistence using ElcipseLink-ORM.XML or API
+
−
** Native Object-XML API using native XML mapping file or API configuration
+
 
* '''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 54: 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'''
−
== Dependent Bundles ==
+
** Repackaged ASM library for byte code weaving.
−
 
+
* '''org.eclipse.persistence.oracle'''
−
=== JPA ===
+
** Oracle database platform classes.
−
 
+
−
# ''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?
+
−
#* Having the javax.persistence classes available in a separate bundle would support the use of multiple persistence providers in a single application--having multiple copies of these classes can (as practical experience has shown me--Shaun) lead to nasty ClassCastExceptions.
+
−
#* Separating spec classes from the impl classes would support multiple spec versions independent of impl versions
+
−
#* Specification versions and implementations should probably be decoupled to be consistent with the expectations of OSGi users.
+
−
 
+
−
=== JAXB ===
+
−
 
+
−
# ''QUESTION: Should JAXB be a bundle or should it be advertised API from EclipseLink's MOXy bundle?''
+
−
#* If we take the same approach to JAXB as is proposed for JPA then JAXB would be its own bundle and be extended to support resolving specific JAXB implementations through a service registry.
+
−
# ''QUESTION: If it is a separate bundle should the RI be included with the API to make it functionally useful on its own?''
+
  
−
=== SDO ===
+
== Open Issues/Areas of Development ==
  
−
#''NOTE: SDO's vendor implementation approach of customizing a class from the public API (Helper) will make bundling it interesting.''
+
* Dynamic Byte Code Weaving
−
#* The SDO 2.1 spec classes contain a single static variable that holds a single SDO implementation class.  This effectively makes it impossible to have two SDO implementations on your classpath. Also the way in which SDO bootstraps to find this sole implementation makes it impossible to have more than one.  Given this is the case there is no motivation to make the SDO classes available in a separate bundle.  They should be included in the EclipseLink SDO bundle.
+
** 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.
  
−
== Issues ==
+
== Other Initiatives ==
  
−
# 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.
+
* Proposed Persistence Service and Extensions
−
#* '''Jan. 8, 2008''' -- Further investigation has lead to an approach that does not require Equinox Buddy Classloaders.  The solution is for EclipseLink to use the classloader of the bundle containing the JPA client code to perform class and resource loading.  The challenge is in obtaining the classloader.  One approach that has been prototyped is to use an Activator class in the the client application bundle to obtain the bundle classloader.  This class can be identified through the Manifest.mf of a JPA client bundle.  EclipseLink can listen for bundle events to identify JPA client bundles and obtain their classloader.
+
** There is a proposal to provide support for configuring EclipseLink JPA using the Equinox plugin extension framework
−
# 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].
+
** [http://wiki.eclipse.org/EclipseLink/Development/OSGi/ServiceProposal Proposal Page]
−
#* '''Jan. 8, 2008''' -- Prototyping has resulted in a fleshing out of the issue of using the Spec API vs. Services.  The current thinking is that a hybrid of both is the way to go.  The idea is that JPA client code would us the JPA spec API to obtain an EntityManagerFactory from javax.persistence.Persistence, but behind the scenes it would use a service approach to locate JPA providers.  This approach would allow client code to ignore the underlying OSGi service mechanism and just use JPA as they would in an SE environment.  It would also allow for the using of multiple JPA providers in the same OSGi container and even application.
+
−
# When dynamic weaving is enabled, EclipseLink will alter Entity classes as they are loaded to introduce a ValueHolder (proxy) for lazy OneToOne  and ManyToOne relationships as well as fetch-groups and change tracking.  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 into this, and may even provide an API at some point.
+
−
# It is not uncommon for EclipseLink customers to actually modify the EclipseLink framework by either subclassing an EclipseLink class or adding another implementation of an EclipseLink interface. We need to work with the OSGi group to see what mechanism would best accomplish the case where some of the EclipseLink code is actually defined in the client bundle, i.e. when clients add EclipseLink extension code.
+
  
 
[[Category:EclipseLink|OSGi]]
 
[[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.

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
Retrieved from "https://wiki.eclipse.org/index.php?title=EclipseLink/Development/OSGi&oldid=126769"

This page was last modified 12:19, 3 November 2008 by Shaun Smith. Based on work by Tom Ware, Bryan Hunt and Doug Clarke and others.

Back to the top