Hi, I think that if you have the classes in a bundle different from the bundle containing the persistence.xml runtime enhancement is unlikely to work reliably. Whether you can get anything else to work is to me an open question.
I'd like to suggest that since the user already has to modify their bundle to list the classes in the persistence.xml it might be simpler all around to just have them pull in the classes too (e.g. using bnd) and not import them from anywhere else. I think this is likely to work much more reliably than any multi-bundle approach and if you only have a few classes per module it won't make a significant size difference. thanks david jencks On May 28, 2012, at 9:49 PM, Balázs Zsoldos wrote: > Hi, > > thanks for the tips. My use case is really different from ordinary ones. We > develop OSS modules that can be re-used in different projects. A good example > is authorization where there are about 3-4 Entity classes only. When someone > wants to use the the authorization solution and works with the same > technology stack (JPA-OSGI) the only thing that he has to do is take the > classes into his/her PU. This means the following in practice: > > We have bundle AUEntity that contains entity classes for the Authorization. > We have bundle LOCEntity that contains Entity classes for Localization. If > someone has an APP_PU bundle that contains the persistence.xml file all he > has to do is to import the packages from the first two Entity bundles and > list the classes from them. After that in the application code authorization > and localization extensions can be used. A very important feature is that > when someone writes a JPA Criteria Query it can be extended with > authorization checks by one Util function call. > > There may be multiple applications that use the same Entity bundles for their > PU. These applications may use different Persistence Providers. For example > if App1 loads the entity jar with Hibernate and App2 uses OpenJPA I will meet > the problem that App1 already loaded the classes and OpenJPA cannot enhance > them. > > I think I will check the compile time enhancement. The following questions > came into my mind: > Shall import-package used for a bundle that has OpenJPA compile time > enhancement? > If an Entity class is enhanced by OpenJPA, can it be used in multiple > Persistence Units? > A class enhanced by OpenJPA can be used with other technologies like > Hibernate? > An enhanced class needs OpenJPA present in the runtime even if we use it with > a different provider like Hibernate or EclipseLink? Practically if > import-package is necessary, could it be optional? > If anybody knows the answer to these questions please let me know! I think I > will have to read a bit about the enhancement of OpenJPA what it does exactly > and how it does it. > > Thanks and regards, > Balazs Zsoldos > > > > On Mon, May 28, 2012 at 2:47 AM, James Carman <[email protected]> > wrote: > Is compile-time enhancement not an option? > > Sent from tablet device. Please excuse typos and brevity. > > On May 27, 2012 5:06 PM, "Balázs Zsoldos" <[email protected]> wrote: > Hi, > > thanks for the quick response. However I was interested in a slightly > different question. I had the following specific exception: > > <openjpa-2.2.0-r422266:1244990 nonfatal user error> > org.apache.openjpa.persistence.ArgumentException: This configuration > disallows runtime optimization, but the following listed types were not > enhanced at build time or at class load time with a javaagent: " > > If the Entity bundle is started before the JPA container picks it up OpenJPA > will not really work. I found an interesting paragraph in the documentation > of Gemini-JPA that is a hack to solve this problem at > http://wiki.eclipse.org/Gemini/JPA/Documentation/OtherTopics. It refreshes > the entity bundle if it is already resolved when Gemini JPA Container picks > it up. Well it sounds a bit sick but at least it may work... Does the aries > container do tricks like this? > > This is not that urgent to me as I was on EclipseLink before until I found > out that it cannot handle more difficult SQL queries. Hibernate could however > it uses solutions (storing the classes in static maps as cache). A couple of > days ago someone on this mail list (or the dev one) noted that OpenJPA is > more OSGI friendly that is why I thought it would be worthy to have a look on > it. > > Regards, > Balazs Zsoldos > Software Architect > Mobile: +36-70/594-92-34 > > Everit Kft. > https://www.everit.biz > > > > > On Sun, May 27, 2012 at 10:30 PM, James Carman <[email protected]> > wrote: > If you're using Aries' JPA support, then it won't start up an entity > manager for your bundle until a JPA provider (like OpenJPA) is > available for it. > > On Sun, May 27, 2012 at 4:04 PM, Balázs Zsoldos > <[email protected]> wrote: > > Hi, > > > > I checked the OpenJPA-OSGI possibilities and the following question came > > into my mind: > > > > - Is it a requirement for OpenJPA that the OpenJPA bundle has to start > > before the one that contains Entity classes? > > > > I know in live OSGI containers admins can play with start levels however it > > makes life very hard if we have to always think in which order we want to > > start our bundles. I did not have these problems with EclipseLink and > > Hibernate (I had different ones :)). > > > > Is there any possibility that OpenJPA-OSGI relationship will be enhanced > > somewhen in the way that no start ordering will matter and nor OpenJPA > > specific compilation neither javaagent usage will be necessary? > > > > Regards, > > Balazs Zsoldos > > Software Architect > > Mobile: +36-70/594-92-34 > > > > Everit Kft. > > https://www.everit.biz > > > > > >
