Hi, Just to say that a solution for entities in bundle fragments has been found, using Gemini and the EclipseLink API. A bug has also been filled in Gemini to include this feature. See http://www.eclipse.org/forums/index.php/mv/msg/365382/895890/#msg_895890
Balázs: I took a look at your code, seems a good starting point if I ever need to use/create a new JPA implementation. Thanks for the links. But I think I'll stick with Gemini for a while, since I found a piece of the solution. /Thomas From: [email protected] [mailto:[email protected]] On Behalf Of Balázs Zsoldos Sent: lundi 2 juillet 2012 04:27 To: OSGi Developer Mail List Subject: Re: [osgi-dev] Dynamic persistence units Hi, you are right I use the same entity classes in different PUs. However I also collect Entity classes into one PU from several bundles. I do not want to add Entity classes to one PU without restarting the PU bundle. It is enough for me that if I reinstall the PU bundle (that may be only one persistence.xml file) and the new entity classes are available. You can find the JPA-Container solution at http://everit.org/osgi/jpa/org.everit.osgi.jpa.container/index.html You can find the hibernate bundle at http://everit.org/osgi/hibernate/org.everit.osgi.hibernate.bundle/index.html And an adapter that makes hibernate working at http://everit.org/osgi/hibernate/org.everit.osgi.hibernate.adapter/index.html Please note that I am in the middle of a big refactor. I did not want to write an answer before I am available however I see now that this stuff will take at least one more week. In the bundles here we decided not to use the following packages with version 0.0.0 anymore: javax.transaction, javax.sql, javax,xml.*, org.w3c.... If you have problems that for example javax.sql package with version 4.0.0 (the version of jdbc) is not found you may change the Import-Package section to contain this package with 0.0.0 version. You can also use the 0.3.0 release where this refactor was not started yet. Regards, Balazs Zsoldos Software Architect Mobile: +36-70/594-92-34 Everit Kft. https://www.everit.biz Everit OpenSource http://everit.org On Thu, Jun 28, 2012 at 5:27 PM, Gillet Thomas (2) <[email protected]> wrote: Hi Balazs, Seems your concern is a little different from mine, since from my understanding you want to use part of one set of entities in several PUs, while I want to gather several sets of entities in one PU. But I see it's still about the same idea. You said you wrote your own OSGi JPA implementation. Did you use EclipseLink or Hibernate? Or both? And does your implementation bring more dynamicity? Is it able to gather entities from different sources? If it is, I would be glad to take a look at your code. Is it available somewhere? Then you asked "How can we use multiple persistence unites by the same *-core bundle services?". I don't really understand what you mean there. Are you trying to use different PUs (that is different EMF services) in the same bundle? Or do you want to publish different PUs from the same bundle (that is multiple "persistence-unit" tags in one persistence.xml)? About Hibernate, you seem to imply it's working almost in the same way regarding dynamicity, but I think Hibernate have more support for creating PUs dynamically than EclipseLink (and I actually mean PUs, not entities). I would think it would be easier to pick the entities you need in each of your PU with Hibernate. Am I wrong? -- Thomas From: Balázs Zsoldos [mailto:[email protected]] Sent: dimanche 24 juin 2012 17:03 To: Gillet Thomas (2) Subject: Re: [osgi-dev] Dynamic persistence units Hi, I think you have similar issues as I have. We wanted also a collection of bundles that contain entity classes and several persistence units that use them. On the end our structure became (an example): - Authorization Entity Bundle - Authentication Entity Bundle - Localization Entity Bundle ... - Application A PU (Using Authorization, authentication, ...) - Application B PU (Using Localization, Authorization...) Our goal with this was that we can write helper methods to extend a JPA Criteria API with permission checks, localization resolving... In this case we have to use the same static metamodel classes from every *-core bundles. I checked Gemini and Aries JPA. We used Aries JPA with eclipselink for a while however Aries JPA had some problems that it does not catch the redeployment of datasources and does not wait until DataSourceFactory bundles are available. In short in many cases the start order of the bundles mattered. With Gemini JPA my problem is that we use JTA everywhere for transaction handling. On the end I wrote my own OSGi JPA support bundle and released it as OSS. It is more or less usable. The next question raised: - How can we use multiple persistence unites by the same *-core bundle services? I saw the subsystem and application possibilities of Aries but I think it would be like going back to WAR development. On the end I specified what we need for a blueprint container to do. I planned to start to develop our own blueprint container in July and I hope I will finish fast :). Till that I dropped up the enhancements into the OSGi bugzilla so others can review and give ideas. It is available at https://www.osgi.org/bugzilla/show_bug.cgi?id=143 Well, I do not think in dynamic PU-s and dynamic entities. I would like to have a system where if I redeploy the PU or any of the entity bundles the PU uses all the dependent bundles will be restarted as well. In the example if I redeploy the Authorization entity both application PU bundles will redeploy while if I redeploy only localization entity bundle than only Applcation B will be redeployed. After a while we moved away from EclipseLink and we moved to Hibernate as EclipseLink dies on more complex queries (generates wrong native SQL) but the logic is the same. Regards, Balazs Zsoldos Software Architect Mobile: +36-70/594-92-34 Everit Kft. https://www.everit.biz Everit OpenSource http://everit.org _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
