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 Sat, 04 Apr 2015 08:24:30 GMT
Hi Guiseppe,

I see your point. The problem though is that the EntityManagerFactory is 
created when the persistence.xml is read. At that point the 
EntityManagerFactory service is created.
So the aries jpa xml or @PersistenceContext properties can only 
influence the creation of the EntityManager. So for you case this would 
not work.

My proposal to use config admin would work though. Imagine we have a 
ManagedServiceFactory that reacts on configs like 
etc/org.apache.aries.jpa-*.cfg. In the config you set the persistence 
unit name and the properties you want to override. These properties 
would be read when creating the EntityManagerFactory. So this would 
allow you to even override the persistenceProvider.


Am 03.04.2015 um 09:44 schrieb Giuseppe Gerla:
> Hi Christian
> I understand your point of view, but I not agree.
> JPA define API, so it is an abstraction. My application MUST be independent
> from the implementation.
> Think about this. I have a software based on postgreSQL that use OpenJPA.
> For some reason a new customer buy my software with the constraint that it
> has to use MySQL. In this case, using your approach I have to use OpenJPA
> with MySQL, but this combination is not performing. From my experience, the
> best JPA implementation for mysql is Eclipselink. Using my approach I have
> the chance to deploy my software on mysql using eclipse without change the
> code!!!
> Not only. Using my approach, without change the code, I can do several test
> in the real environment to select the best combination between DBMS and JPA
> implementation from performance point of view.
> However, I have to say that write jpa query (using criteria builder)
> independent from the JPA implementation and from DBMS is a bit complex.
> I think that my use case is not so common, but I have this need and using
> Spring ORM can satisfy it.
> This is because I open the ARIES-1295 issue and open a pull request to fix
> it.
> Regards
> Giuseppe
> 2015-04-03 1:03 GMT+02:00 Christian Schneider <>:
>> 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.
>> Christian
>> 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
>>>>>> still
>>>>>> necessary. The code already makes sure that the EntityManagerFactory
>>>>>> 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