You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Christian Schneider <ch...@die-schneider.net> on 2015/04/02 15:41:08 UTC

Prototype for a new aries jpa impl

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

Re: Prototype for a new aries jpa impl

Posted by Giuseppe Gerla <gi...@gmail.com>.
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 <ch...@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 <ch...@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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>

Re: Prototype for a new aries jpa impl

Posted by Christian Schneider <ch...@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 <ch...@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 <ch...@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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>

Re: Prototype for a new aries jpa impl

Posted by Giuseppe Gerla <gi...@gmail.com>.
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 <ch...@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 <ch...@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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>

Re: Prototype for a new aries jpa impl

Posted by Christian Schneider <ch...@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 <ch...@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 <ch...@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
>>>>>>
>>>>>>
>>>>>>
>>>>>>

Re: Prototype for a new aries jpa impl

Posted by Giuseppe Gerla <gi...@gmail.com>.
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 <ch...@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 <ch...@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
>>>>>
>>>>>
>>>>>
>>>>>
>

Re: Prototype for a new aries jpa impl

Posted by Christian Schneider <ch...@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 <ch...@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 <ch...@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
>>>>
>>>>
>>>>

Re: Prototype for a new aries jpa impl

Posted by Giuseppe Gerla <gi...@gmail.com>.
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 <ch...@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 <ch...@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
>>>
>>>
>>>
>

Re: Prototype for a new aries jpa impl

Posted by Christian Schneider <ch...@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 <ch...@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
>>
>>

Re: Prototype for a new aries jpa impl

Posted by Giuseppe Gerla <gi...@gmail.com>.
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 <ch...@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
>
>