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



Reply via email to