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 23:03:00 GMT
Why should that make sense? Changing the persistence framework is much 
more than the schema generation and other properties.
They all have slight differences when you create real applications. 
Exchanging the JPA impl on the fly is not feasible and I can not imagine 
a use case where it is necessary.

Also the ddl generation is normally not working once you create bigger 
applications. The reason is that you want to manage the schema and 
provide a clearly defined migration of the schema when you deploy. I 
have seen people use liquibase for that case with good success. For my 
examples I of course use the schema generation but that is not how 
people do it in bigger projects.

So my assumption is that you probably will not really need properties 
where you inject the EntityManager. What might make sense though is to 
for example provide a way to set properties on the persistence unit 
level using config admin. That should be easy to do and would even help 
with your use case .. even if I doubt it is realistic.


Am 02.04.2015 um 23:13 schrieb Giuseppe Gerla:
> 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.
> Regards
> Giuseppe
> 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

View raw message