[
https://issues.apache.org/jira/browse/ARIES-712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Balazs Zsoldos closed ARIES-712.
--------------------------------
Resolution: Won't Fix
Closing this issue as it is not relevant for the reporter anymore and no one
else is interested in such solution.
> 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)
