Skip to main content
Jump to: navigation, search


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.


  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.



    • 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

Proposal: Bundle Components

This proposal refers to making parallel bundle PDE projects which expose the existing functionality from the Java projects.

Proposal: Use PDE for Component Projects

Convert the existing Java projects into PDE projects.

Dependent Bundles


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?


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?


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


  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.

Back to the top