Jump to: navigation, search

Difference between revisions of "EclipseLink/Development/OSGi"

m (Issues)
(Current Status)
Line 11: Line 11:
 
== 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 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.
  
 
== Proposal ==
 
== Proposal ==

Revision as of 16:16, 8 January 2008

This page is focussed on capturing how EclipseLink will be developed and used for an OSGi (Equinox) environment.

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

  1. Provide EclipseLink bundles that are easy to use within other Eclipse projects and RCP applications
  2. Provide EclipseLink JAR files that enabled Java SE and EE usage
  3. Ensure that the bundles offer flexibility in their independent usage. The usage of EclipseLink JPA should not force the usage of EclipseLink's JAXB

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.

Proposal

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.

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.
    • 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:

  • javax.persistence
    • Spec classes and interfaces augmented with support for discovering JPA provider services.
  • javax.xml.bind
    • Spec classes and interfaces augmented with support for discovering JAXB provider services.
  • org.eclipse.persistence.foundation
    • 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
    • JPA 1.0 functionality
    • Extended JPA support using EclipseLink's annotations, PU properties, and query hints
    • Support for partial and complete EclipseLink-ORM.XML extensions of JPA
  • 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.eis
    • Native Object-EIS/JCA using native XML mapping file or API configuration

Dependent Bundles

JPA

  1. 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

  1. 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.
  2. QUESTION: If it is a separate bundle should the RI be included with the API to make it functionally useful on its own?

SDO

  1. NOTE: SDO's vendor implementation approach of customizing a class from the public API (Helper) will make bundling it interesting.
    • 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.

Issues

  1. 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, Peter Kriens, OSGi Director of Technology, 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.
    • 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.
  2. 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 described what a service based approach would look like.
    • 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.
  3. 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 AspectJ in OSGi and Equinox may provide some insight into this, and may even provide an API at some point.
  4. 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.