[ 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)