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 Sat, 04 Apr 2015 12:23:17 GMT
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

If you want I can help you to develop this functionality.


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