aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giuseppe Gerla <>
Subject Re: Prototype for a new aries jpa impl
Date Thu, 02 Apr 2015 21:13:10 GMT
Hi Christian
thanks for explanation. I hope to make some tests during next week-end.

About properties, I'd like to have a persistence.xml without reference to
JPA implementation, only classes list. Implementation should be changed
without re-compile the bundle.
So for example if I have a property to define the schema creation in the
persistence.xml like

<property name="" value="create-drop"/>

and replace hibernate with eclipselink, I have to replace the
persistence.xml with

<property name="eclipselink.ddl-generation" value="drop-and-create-tables"/>

and I have to deploy a new version of my bundle.
Using blueprint and hot-configuration of Karaf it could be possible to
change the property using a configuration file.


2015-04-02 21:26 GMT+02:00 Christian Schneider <>:

> 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?
> Christian
> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message