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 Fri, 03 Apr 2015 07:44:39 GMT
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
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


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 is
>>>>> 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

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