forgot to send to list too
-------- Weitergeleitete Nachricht --------
Betreff: Re: Prototype for a new aries jpa impl
Datum: Sun, 05 Apr 2015 10:42:30 +0200
Von: Christian Schneider <ch...@die-schneider.net>
Antwort an: ch...@die-schneider.net
An: Giuseppe Gerla <giuseppe.ge...@gmail.com>
I propose to use config admin with one config per punit instead of a
plain file. The reason is that you probably will want to deploy the
config together with your application.
This would be a lot more difficult if there is one config for all
persistence units and your deployment has to patch the config file.
So I propose you use config admin with a ManagedService. The pid could
look like a ManagedServiceFactory but probably it would be better to use
a real MSF.
So for each persistence unit you could publish a ManagedService with a
pid of org.apache.aries.jpa.<persistence-unit>.cfg. The EMF creation
would take place in the updated method of the ManagedService. When there
is a null config it would take the default properties if a config is
given it would take it.
Would that work?
Christian
Am 05.04.2015 um 09:37 schrieb Giuseppe Gerla:
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
<mailto: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 <mailto: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
<mailto: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
<mailto: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
<mailto: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
