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 Sun, 05 Apr 2015 06:46:03 GMT
Hi Guiseppe,

would be great if you can tackle that.


Am 04.04.2015 um 14:23 schrieb Giuseppe Gerla:
> Hi Christian
> Great idea.
> I understood the problem and yesterday I was thinking about a possible
> solution like yours.
> I'm thinking to use config admin in the parser of persistence.xml so to be
> able to use parameter value in the properties, but your solution seems more
> complete.
> If you want I can help you to develop this functionality.
> Thanks
> Regards
> Giuseppe
> 2015-04-04 10:24 GMT+02:00 Christian Schneider <>:
>> 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.
>> Christian
>> 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
>>>>> 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
>>>>>> 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
>>>>>> 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
>>>>>> 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
>>>>>>> time.
>>>>>>> So before I start, I would like to ask you:
>>>>>>> 1. you say that the current code is not yet complete. What is
>>>>>>> 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
>>>>>>> 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
>>>>>>>> Tracking all dependencies and publishing / unpublishing
>>>>>>>> EntityManagerFactory when any go away
>>>>>>>> - Move some functionality to other projects like wrapping
>>>>>>>> DataSources
>>>>>>>> to pax-jdbc.
>>>>>>>> - Support for other frameworks like declarative services
>>>>>>>> JPATemplate
>>>>>>>> and closures
>>>>>>>> The current code is not yet complete but already works for
>>>>>>>> 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
>>>>>>>> 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