EclipseLink 1.0 / JPA / Fragment Loading in SpringSource AP

Hello,
I ran the Petclinic using EclipseLink 1.0m8, however, when I upgrade to the Eclipse 1.0 release there seems to be a problem loading org/eclipse/persistence/jpa/PersistenceProvider ( ClassNotFound )

Eclipse 1.0 consists of two bundles, the core bundle and a JPA-fragment in which the org/eclipse/persistence/jpa/PersistenceProvider is located.

In the original PetClinic descriptor I had:
Import-Bundle: com.springsource.org.eclipse.persistence;version=" 1.0.0m8";import-scope:=application,

From the docs, I understand the the 'import-scope:=application' gives JPA access to all bundles contained in the app. However, the JPA 1.0 fragment for com.springsource.org.eclipse.persistence seems to require explicit import.

I've tried adding Import-Bundle: com.springsource.org.eclipse.persistence;version=" 1.0.0";import-scope:=application,
com.springsource.org.eclipse.persistence.jpa;versi on="1.0.0";import-scope:=application

But I keep getting an error the class located in the JPA fragment cannot be located, its not until I do a manual import in the model classes that its detected.

Seems import-scope:=application does not pick-up fragments or cannot be applied to fragments.

Anyone else had experience using EclipseLink 1.0(final) which consists of two separate bundles ?

Hi,

I've just taken a look into using 1.0.0 of EclipseLink with the Petclinic sample and there are a couple of problems.

The first is that the Spring 2.5.5.A ORM bundle imports the EclipseLink types with a version range of 1.0.0.M5 to 2.0.0. Unfortunately, in OSGi, 1.0.0 is deemed to be lower than 1.0.0.M5 so the 1.0.0 EclipseLink types lie outside the requested range. This means that they aren't imported by the ORM bundle and leads to the ClassNotFoundException for org/eclipse/persistence/jpa/PersistenceProvider.

This problem will be fixed when Spring 2.5.6 is released and added to the Enterprise Bundle Repository by changing the version range on the imports. In the meantime you can workaround the problem by modifying the existing Spring ORM bundle to import the EclipseLink packages with a range of [1.0.0,2.0.0) rather than the current range of [1.0.0.M5, 2.0.0).

The second problem is that there is a bug in EclipseLink 1.0.0 that prevents it from finding @Id annotations on get() methods of a @MappedSuperClass: https://bugs.eclipse.org/bugs/show_bug.cgi?id=240679.

To workaround this problem you would have to modify the types in the PetClinic domain bundle to move the annotations on all the types to their fields as suggested in the bug report.

Thanks for bringing this problem to our attention.

Hope this helps,

Andy

Andy,
Thanks for clearing this up. Sure enough, modified the internal Spring 2.5.5.A ORM bundle and its working.

Since I'm using SpringSource-AP RC1, do you anticipate this ORM bundle will change by the SpringSource-AP 1.0 (final) release ? I ask because I'm writing on the subject of SpringSource-AP....and thinking of adding a note on this, but if the ORM included in the final SpringSource-AP will have [1.0.0,2.0.0) I can avoid mentioning this all together.

Just minor, but still nice to know if you anticipate this change in the internal ORM library for the final release.

Thanks again!

We've actually decided to correct the 2.5.5.A version of the ORM bundle, and this fixed version is now available in the Enterprise Bundle Repository. The next release of AP 1.0 will include this version of the ORM bundle, so no need to mention it :) .

Hi

I've noticed com.springsource.org.eclipse.persistence.* bundles export quite a lot of internal packages. I don't think this is correct.

Also, was there any reason why you have packaged these jars under com.springsource.* name? I believe EclipseLink jars are already osgi bundles.

Jaro

Jaro,

The exporting of internal packages is not something that we've changed: the original EclipseLink bundles export the same internal packages.

The jar names and bundle symbolic names of the EclipseLink bundles in the Enterprise Bundle Repository have been prefixed with com.springsource as we have made slight modifications to them, e.g. we have removed the use of Require-Bundle and instead replaced it with appropriate Import-Package entries.

Andy