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
