aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Divya K Konoor <>
Subject Re: Issue with OSGi-JPA entity persistence bundling
Date Tue, 09 Jul 2013 14:23:02 GMT
Hi Christoph,

Thanks for your suggestion. I tried it and it works fine for me too !

Thanks & Regards,

From:	Christoph Gritschenberger <>
Date:	07/01/2013 10:49 AM
Subject:	Re: Issue with OSGi-JPA entity persistence bundling

Hi Divya,

[Moving this to the user-list]

Having PUs in different bundles all accessing the same DataSource works
quite well for us. We (at our company) use a setup similar to [1] for this.

The only pitfall we encountered is with transitive dependencies to
Entities in other bundles.

Example: Entitiy A has a property of Entity-Type B. EntityType C as a
reference To A.
When C is in a different bundle, the persistence.xml of that bundle has
to include the of A and B.

kind regards,


On 2013-06-28 14:25, Divya K Konoor wrote:
> Hi ,
> We are trying to figure out the best possible solution towards the below
> explained OSGI-JPA related problem.
> We use OSGi blueprint specification in WAS Liberty 8.5 version (which
> internally uses Aries) . We use JPA entities for persistence . Our
> requirement is as follows:
> 1. We have multiple JPA entities but all of them cannot be grouped
> in a single persistence bundle as different sets of JPA entities are for
> different functionality/feature and grouping them together would mean
> making them all tightly coupled .
> 2. All communication to the data source has to happen via a single
> persistence unit (PU). This means that all JPA entities should be
> associated with the same PU.
> 3. As per point 1 above, all entity classes cannot be bundled into a
> persistence bundle .The other option is to have one persistence bundle
> JPA entity class or to group JPA entities into persistence bundles based
> the functionality. Either options would mean that there are more than one
> persistence bundles and at least one Persistence Unit needs to be defined
> for each bundle but that might contradict the requirement in point 2
> a) Can more than one persistence unit talk to the same Data
> source/Database ? If this is possible , then each persistence bundle can
> define it's own PU but all of them will talk to the same back-end. Does
> this approach have any undesirable implications ?
> b) If the approach in 3a is feasible , then can a client bundle have a
> handle to more than one entity manager and perform operations using  on
> different JPA entities ? Would this cause any issues ?
> 4. To satisfy requirements 1 and 2 as stated above, we have currently
> resorted to defining one persistence bundle with one Persistence
unit .This
> also carries abstract and super class entity classes. The rest of the
> entity classes are packaged as OSGi fragments with the persistence bundle
> as the host bundle.However, this model runs us into Entity enhancement
> issues as it does not comply with OSGI 4.2 specification section 127
> talks about how OSGi JPA entities cannot be fragments .
> Looking forth to some suggestions and recommendations.
> Thanks
> Divya

View raw message