aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <>
Subject Re: Prototype for a new aries jpa impl
Date Thu, 02 Apr 2015 19:26:31 GMT
Hi Giuseppe,

the main thing missing is the more advanced transaction handling.
Currently for blueprint the transaction starts at the outermost place 
where an EntityManager or EmSupplier is injected.
So it is as if you would use a @Transactional with Required type on each 
such class.

Apart from that you should already be able to write jpa applications 
with the current code.

Currently only the persistence.xml is regarded for creating the 
EntityManagerFactory. While you can add properties to the 
@PersistenceContext annotation they are not used.
Honestly I do not understand anyway how you would handle such 
properties. You could have different properties at every 
@PersistenceContext for the same unit name. As we are only creating the 
EntityManager at the outermost call the other properties can not be 
applied. Can you explain what use case you have in mind for the properties?


Am 02.04.2015 um 18:48 schrieb Giuseppe Gerla:
> Hi Christian
> I would be very interested to try the new prototype, but I have few time.
> So before I start, I would like to ask you:
> 1. you say that the current code is not yet complete. What is missing? What
> functionalities I will not test?
> 2. Is it possible or it will be possible to set some properties to the EMF?
> (something like jpa:map functionality. See
> Thanks for your work
> Regards
> Giuseppe
> 2015-04-02 15:41 GMT+02:00 Christian Schneider <>:
>> I am experimenting for some time with a new way to implement jpa support.
>> You can find the design on this website:
>> The prototype code is at:
>> The goals for the new design are:
>> - Simpler and more robust implementation using OSGi service dynamics.
>> Tracking all dependencies and publishing / unpublishing
>> EntityManagerFactory when any go away
>> - Move some functionality to other projects like wrapping XA DataSources
>> to pax-jdbc.
>> - Support for other frameworks like declarative services using JPATemplate
>> and closures
>> The current code is not yet complete but already works for blueprint and
>> DS.
>> I would be happy about any feedback.
>> Especially I would be interested if with the new approach Quiesce is still
>> necessary. The code already makes sure that the EntityManagerFactory is
>> nicely cleaned up. EntityManagers are only held for the duration of a
>> request. So if blueprint Quiesce shuts down the requests then I think the
>> jpa impls should not need to do additional work here. I tested to update
>> all modules at runtime and all seems to work nicely. With the current aries
>> jpa I can not update the persistence unit bundles. See
>> Christian
>> --
>> Christian Schneider
>> Open Source Architect

View raw message