EclipseLink/Development/OSGi

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

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.

The approach to supporting OSGi being pursued 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.

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

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?

JAXB

QUESTION: Should JAXB be a bundle or should it be advertised API from EclipseLink's MOXy bundle?

QUESTION: If it is a separate bundle should the RI be included with the API to make it functionally useful on its own?

SDO

NOTE: SDO's vendor implementation approach of customizing a class from the public API (Helper) will make bundling it interesting.

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.
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.
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 or this or even some APIs.