aries-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Ward <timothyjw...@hotmail.com>
Subject RE: AW: OSGi JPA and JDBC Services
Date Sat, 18 Sep 2010 10:02:22 GMT

Hi,

I'm glad that you have a basic application up and running. I have a few comments.

Technically it's not allowed for entities to be in separate bundles from the persistence descriptor
that uses them, its a violation of the encapsulation of the data model. It will probably work
in most environments, but only for pre-enhanced entities. I would strongly recommend not putting
entities into a different bundle from the persistence descriptor, primarily because it is
explicitly forbidden in the JPA service specification.

As for the JPA provider, there is a minimum level of OSGi awareness necessary. Firstly, it
needs to be packaged as an OSGi bundle. Secondly it needs to register its PersistenceProvider
implementation in the service registry (using some service properties defined in the JPA service
specification). Both of these things are easy for a user to package in, but have already been
done by OpenJPA and EclipseLink. If you wanted to to use Hibernate, then you would almost
certainly need to re-package it, and use blueprint, DS, or an Activator to register the service.

It should be possible to use EclipseLink with the Aries JPA container, there were some bugs
when we originally tested it, which we raised against them. I don't know if they've been fixed
yet, but I'd be happy to set up some more itests if you were interested.

The "incompatible" approach taken by EclipseLink is actually the support that the JPA service
specification was built upon. Meta-Persistence is an OSGi defined header for doing JPA in
OSGi, it's more or less identical to the JPA-PersistenceUnits header.

I will take this opportunity to say that EclipseLink's OSGi support is different to the JPA
container in Aries. EclipseLink implements the JPA service specification, which defines unmanaged
JPA in OSGi, Aries uses the same metadata (Meta-Persistence) and spec defined integration
(the PersistenceProvider service) to do container managed JPA. As a result, the Aries JPA
container does not implement a standard (but does use OSGi standards). The advantage that
Aries has is that it theoretically works with any JPA provider (barring bugs in their implementations),
whereas as far as I am aware EclipseLink is the only provider that can be used with the JPA
service specification.

Regards,

Tim

----------------------------------------
> From: Harald.Wellmann@multi-m.de
> To: aries-user@incubator.apache.org
> Date: Fri, 17 Sep 2010 17:37:01 +0200
> Subject: AW: OSGi JPA and JDBC Services
>
> Good news:
>
> - I'm now using the following persistence.xml
>
> 
> transaction-type="RESOURCE_LOCAL">
> osgi:service/javax.sql.DataSource
> test.openjpa.model.Book
> true
> 
>
> - I've added the three bundles org.apache.aries.jndi.api, jndi.core and jndi.url to my
application.
>
> - I have another bundle which imports the appropriate JDBC driver and publishes a data
source as an OSGi service.
>
> A simple test case with just one entity in the PU bundle now works.
>
> My real application is a bit more complex, the PU bundle imports entity classes from
two other bundles, and there are custom value handlers which need to be loaded by OpenJPA
in addition to the entity classes. This is the next thing I'm going to try.
>
> Just for my better understanding: does the JPA provider have to be OSGi aware to make
this setup work? I.e. does OpenJPA now work with Aries because the OpenJPA guys have made
some additions in the past? Or would the same example also work with Hibernate or Eclipselink?
>
> Eclipselink supports OSGi out of the box (while Hibernate notoriously doesn't), but their
approach appears to be slightly incompatible, e.g. they use a JPA-PersistenceUnits manifest
header instead of Meta-Persistence.
>
> Best regards,
>
> Harald
>
>
> ________________________________________
> Von: Timothy Ward [timothyjward@hotmail.com]
> Gesendet: Freitag, 17. September 2010 16:57
> An: aries-user@incubator.apache.org
> Betreff: RE: AW: OSGi JPA and JDBC Services
>
> You're absolutely right, that was supposed to say 'true' not 'false' - whoops!
>
> Tim
>
> ----------------------------------------
>> From: Harald.Wellmann@multi-m.de
>> To: aries-user@incubator.apache.org
>> Date: Fri, 17 Sep 2010 16:53:49 +0200
>> Subject: AW: OSGi JPA and JDBC Services
>>
>> Hi Tim,
>>
>> 1. I do enhance my classes at build time.
>> 2: I do not list all classes in the persistence.xml.
>>
>> So I believe you're meaning to say that true would avoid my problem because OpenJPA
would not need to scan from the persistence unit root. That makes sense - I'll give it a try...
>>
>> Best regards,
>> Harald
>>
>>
>> ________________________________________
>> Von: Timothy Ward [timothyjward@hotmail.com]
>> Gesendet: Freitag, 17. September 2010 16:36
>> An: aries-user@incubator.apache.org
>> Betreff: RE: AW: OSGi JPA and JDBC Services
>>
>> Hi Harald,
>>
>> I have two questions:
>>
>> 1. Are you pre-enhancing your Entity classes? This is a requirement using the base
Aries JPA container as load-time weaving cannot be supported in a generic OSGi framework (although
some runtimes extend the Aries code to provide this, e.g. Geronimo and WebSphere).
>>
>> 2. Are you listing all of your entity classes in the persistence unit definition
and setting false? In unmanaged JPA you are supposed to do this (though many providers support
scanning in unmanaged environments). In OSGi scanning doesn't work the same way, and is, once
again, not supported in the Aries JPA container (though it is provided in WebSphere).
>>
>> Both of these limitations will (hopefully) be lifted in the future, but they will
need to rely on features proposed for version 4.3 of OSGi, and so there's not a lot we can
do about them at the moment.
>>
>> Regards,
>>
>> Tim
>>
 		 	   		  
Mime
View raw message