[ 
https://issues.apache.org/jira/browse/ARIES-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14630966#comment-14630966
 ] 

Christian Schneider commented on ARIES-712:
-------------------------------------------

I am not sure if it is a good idea to support this. It makes the code much more 
complicated and is only needed very seldomly.

> Supporting application specific variables
> -----------------------------------------
>
>                 Key: ARIES-712
>                 URL: https://issues.apache.org/jira/browse/ARIES-712
>             Project: Aries
>          Issue Type: Brainstorming
>          Components: Blueprint, JPA
>            Reporter: Balazs Zsoldos
>
> Starting with OSGI I met a problem that I could not solve in any general way 
> till now: I would like to use the same module from different "applications" 
> but with slightly different configuration.
> More specifically: I would like to create a bundle that contains persistence 
> services. I would like to use this bundle from several applications but with 
> different database which means I would like to use different persistence 
> units.
> Currently I can use <jpa:context ...> to define a container managed 
> EntityManager in my service beans. It is a very nice way however I cannot 
> make the unit-name dynamic in this tag. My database schema is used as part of 
> many different application (schema to handle permissions).
> I am thinking since days and it seems to me that a solution like the 
> following would solve my problem:
> - Having a service called ApplicationService. This has methods: 
> setApplicationParameter(String paramName, Object value); 
> getApplicationParameter... The parameters of the current application are 
> stored in a thread local variable.
> - Having a new blueprint tag: <app:parameter name="someName" ref="..." />. 
> This tag does the followings:
>    - Works the same as PropertyPlaceHolderConfigurer to eliminate possible 
> duplicate configurations
>    - Wraps all services in the way that when a function is called on them the 
> application parameters are set and when it returns the olda application 
> parameters are re-set (if there were any)
> - Having a possibility inside <jpa:context .../> where the unit-name comes 
> from application parameters. With that the bundle is re-usable while many 
> different applications can use it with their database.
> - Better would be not to define unit-name but entity manager factory itself 
> as an application parameter as it makes it necessary that the persistence 
> unit exists when the bundle that contains the application parameters is 
> deployed.
> Note that I do not talk here about the Aries EBA solution. I would like to 
> have as less jars in my JVM as it is possible. Please let me know if you like 
> this kind of approach as in that case I will check if I have time to 
> implement it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to