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