aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giuseppe Gerla <giuseppe.ge...@gmail.com>
Subject Re: Prototype for a new aries jpa impl
Date Sun, 05 Apr 2015 07:37:20 GMT
Ok.
I'm starting to implement.... using this scenario. Unit name is
"propertiesUnit". In the configuration file I search for:

propertiesUnit.<property-name> = <property-value>

So we will have one file for all persistence units.
I want create e private method in the ManagedEMF class to retrieve all
properties and use to create the EMF.
Wdyt?



Regards
Giuseppe

2015-04-05 8:46 GMT+02:00 Christian Schneider <chris@die-schneider.net>:

> Hi Guiseppe,
>
> would be great if you can tackle that.
>
> Christian
>
>
> 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 <chris@die-schneider.net>:
>>
>>  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 <chris@die-schneider.net
>>>> >:
>>>>
>>>>   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="hibernate.hbm2ddl.auto" 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 <
>>>>>> chris@die-schneider.net
>>>>>>
>>>>>>> :
>>>>>>>
>>>>>>    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
>>>>>>>> https://issues.apache.org/jira/browse/ARIES-1295
>>>>>>>>
>>>>>>>> Thanks for your work
>>>>>>>> Regards
>>>>>>>> Giuseppe
>>>>>>>>
>>>>>>>>
>>>>>>>> 2015-04-02 15:41 GMT+02:00 Christian Schneider <
>>>>>>>> chris@die-schneider.net
>>>>>>>>
>>>>>>>>  :
>>>>>>>>>
>>>>>>>>>      I am experimenting for some time with a new way
to implement
>>>>>>>> jpa
>>>>>>>> support.
>>>>>>>>
>>>>>>>>   You can find the design on this website:
>>>>>>>>
>>>>>>>>> http://liquid-reality.de/display/liquid/New+design+for+aries+jpa
>>>>>>>>>
>>>>>>>>> The prototype code is at:
>>>>>>>>> https://github.com/cschneider/jpa-experiments
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>> https://issues.apache.org/jira/browse/ARIES-1270
>>>>>>>>>
>>>>>>>>> Christian
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Christian Schneider
>>>>>>>>> http://www.liquid-reality.de
>>>>>>>>>
>>>>>>>>> Open Source Architect
>>>>>>>>> http://www.talend.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>

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