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"

(Dependent Bundles)
(Issues)
Line 51: Line 51:
  
 
# 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.
 
# 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.
 +
 +
# 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].

Revision as of 16:55, 17 December 2007

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 will be required.

Requirements

  1. Make EclipseLink bundles easy to use within other Eclipse projects and RCP applications without hindering the Java (SE/EE) usage
  2. 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.

Proposals

Bundles:

  • 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

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

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

SDO

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

Back to the top