aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Fwd: Re: Prototype for a new aries jpa impl
Date Sun, 05 Apr 2015 08:43:12 GMT
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 <chris@die-schneider.net>
Antwort an: 	chris@die-schneider.net
An: 	Giuseppe Gerla <giuseppe.gerla@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 <chris@die-schneider.net 
> <mailto:chris@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
>         <chris@die-schneider.net <mailto:chris@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
>                 <chris@die-schneider.net
>                 <mailto:chris@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
>                         <chris@die-schneider.net
>                         <mailto:chris@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 <
>                                 chris@die-schneider.net
>                                 <mailto:chris@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
>
>
>
>
>
>
>




Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message