You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Christoph Gritschenberger <ch...@gmail.com> on 2013/07/01 07:19:27 UTC
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,
Christoph
[1] https://github.com/openengsb/openengsb/tree/master/infrastructure/jpa
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 together
> 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 single
> persistence bundle .The other option is to have one persistence bundle per
> JPA entity class or to group JPA entities into persistence bundles based on
> 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 above.
>
> 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 which
> talks about how OSGi JPA entities cannot be fragments .
>
> Looking forth to some suggestions and recommendations.
>
> Thanks
> Divya
>
>
Re: Issue with OSGi-JPA entity persistence bundling
Posted by Divya K Konoor <di...@in.ibm.com>.
Hi All,
I have few queries in lines with the discussion below.
How many persistence units are recommended for a product ? Is there any
specific disadvantage of having many persistence bundles (each with its
own persistence unit defined), such all of them point to the same
database ?
If we follow the model that Christoph has explained below, we will have
more than 10 persistence OSGi bundles such that most of them will have
transitive dependencies on other bundles . Including the dependencies in
the persistence.xml ensures that the relationship /mapping is maintained
and its all working fine but I am not sure if there are any specific
performance overheads or disadvantages having as many persistence bundles
as we need (because in future the bundles might keep growing) and adding
dependencies into each others persistence.xml as discussed
Thanks
Divya
From: Christoph Gritschenberger <ch...@gmail.com>
To: user@aries.apache.org,
Cc: dev@aries.apache.org
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,
Christoph
[1] https://github.com/openengsb/openengsb/tree/master/infrastructure/jpa
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
together
> 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
single
> persistence bundle .The other option is to have one persistence bundle
per
> JPA entity class or to group JPA entities into persistence bundles based
on
> 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
above.
>
> 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
which
> talks about how OSGi JPA entities cannot be fragments .
>
> Looking forth to some suggestions and recommendations.
>
> Thanks
> Divya
>
>
Re: Issue with OSGi-JPA entity persistence bundling
Posted by Divya K Konoor <di...@in.ibm.com>.
Hi Christoph,
Thanks for your suggestion. I tried it and it works fine for me too !
Thanks & Regards,
Divya
From: Christoph Gritschenberger <ch...@gmail.com>
To: user@aries.apache.org,
Cc: dev@aries.apache.org
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,
Christoph
[1] https://github.com/openengsb/openengsb/tree/master/infrastructure/jpa
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
together
> 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
single
> persistence bundle .The other option is to have one persistence bundle
per
> JPA entity class or to group JPA entities into persistence bundles based
on
> 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
above.
>
> 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
which
> talks about how OSGi JPA entities cannot be fragments .
>
> Looking forth to some suggestions and recommendations.
>
> Thanks
> Divya
>
>