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