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/Examples/OSGi"

(Importing Javax.Persistence 2.0)
(OSGi)
Line 3: Line 3:
 
=== Importing Javax.Persistence 2.0 ===
 
=== Importing Javax.Persistence 2.0 ===
  
In March of 2010, the OSGi Alliance released the OSGi Enterprise Specification which defines how a number of Java EE technologies including JPA can be used within OSGi.  One issue raised by this specification is how to identify each API version as Java EE numbering is not based on the same strict rules as OSGi.  For example, by the OSGi versioning rules JPA 2.0 should really be 1.1 as it is fully backwards compatible with JPA 1.0 and adds additional API. The [http://www.eclipse.org/gemini Gemini] project (based on EclipseLink) is building the Enterprise OSGi JPA spec implementation and will provide support for JPA 1.1 (OSGi numbering) but will tag each package export with a "jpa" attribute to allow importers to specify the Java EE specification number independent of the OSGi version.   
+
In March of 2010, the OSGi Alliance released the OSGi Enterprise Specification which defines how a number of Java EE technologies including JPA can be used within OSGi.  The [http://www.eclipse.org/gemini Gemini] project (based on EclipseLink) is building the Enterprise OSGi JPA spec implementation which will make the existing EclispeLink OSGi support, which pre-dates the specification, obsolete.  You can try out a milestone of [http://www.eclipse.org/gemini Gemini] today or use the existing EclipseLink OSGi support.  Links to examples of EclipseLink OSGi usage are provided below.
 +
 
 +
One issue raised by the OSGi Enterprise Specification is how to identify each API version as Java EE numbering is not based on the same strict rules as OSGi.  For example, by the OSGi versioning rules JPA 2.0 should really be 1.1 as it is fully backwards compatible with JPA 1.0 and adds additional API.   To resolve this conflict EclipseLink will provide support for JPA 1.1 (OSGi numbering) but will tag each package export with a "jpa" attribute to allow importers to specify the Java EE specification number independent of the OSGi version.   
  
 
So, to use JPA 2.0 in OSGi you would use the following import package declaration:
 
So, to use JPA 2.0 in OSGi you would use the following import package declaration:
Line 20: Line 22:
 
* [[EclipseLink/Examples/OSGi/Equinox Byte Code Weaving|Equinox Byte Code Weaving]]
 
* [[EclipseLink/Examples/OSGi/Equinox Byte Code Weaving|Equinox Byte Code Weaving]]
 
* [[EclipseLink/Examples/OSGi/LazyLoadingRCP|Using EclipseLink JPA in an RCP application]]
 
* [[EclipseLink/Examples/OSGi/LazyLoadingRCP|Using EclipseLink JPA in an RCP application]]
 +
 +
==Eclipse Rich Client Platform (RCP)==
 +
Examples that show how to use EclipseLink in RCP Applications.
 +
 +
* [[EclipseLink/Examples/OSGi/LazyLoadingRCP|Lazy Loading RCP Tree Example]]
 +
 +
[[Category:EclipseLink/Example|OSGi Examples]]
  
 
==Eclipse Rich Client Platform (RCP)==
 
==Eclipse Rich Client Platform (RCP)==

Revision as of 10:14, 18 October 2010

OSGi

Importing Javax.Persistence 2.0

In March of 2010, the OSGi Alliance released the OSGi Enterprise Specification which defines how a number of Java EE technologies including JPA can be used within OSGi. The Gemini project (based on EclipseLink) is building the Enterprise OSGi JPA spec implementation which will make the existing EclispeLink OSGi support, which pre-dates the specification, obsolete. You can try out a milestone of Gemini today or use the existing EclipseLink OSGi support. Links to examples of EclipseLink OSGi usage are provided below.

One issue raised by the OSGi Enterprise Specification is how to identify each API version as Java EE numbering is not based on the same strict rules as OSGi. For example, by the OSGi versioning rules JPA 2.0 should really be 1.1 as it is fully backwards compatible with JPA 1.0 and adds additional API. To resolve this conflict EclipseLink will provide support for JPA 1.1 (OSGi numbering) but will tag each package export with a "jpa" attribute to allow importers to specify the Java EE specification number independent of the OSGi version.

So, to use JPA 2.0 in OSGi you would use the following import package declaration:

Import-Package: javax.persistence;version="1.1.0";jpa="2.0"

Prior to the definition of the OSGi Enterprise specification, EclipseLink shipped a JPA 2.0 preview bundle versioned as 1.99, but without a jpa attribute specified. By specifying jpa="2.0" you can ensure that the preview bundle is not used even when you specify the OSGi Enterprise spec JPA version of 1.1.0.

Examples

Examples that illustrate the use of EclipseLink in OSGi applications

Eclipse Rich Client Platform (RCP)

Examples that show how to use EclipseLink in RCP Applications.

Eclipse Rich Client Platform (RCP)

Examples that show how to use EclipseLink in RCP Applications.

Copyright © Eclipse Foundation, Inc. All Rights Reserved.