Mailing-List: contact dev-help@aries.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@aries.apache.org
Date: Mon, 25 Jul 2011 08:57:10 +0000 (UTC)
From: "Balazs Zsoldos (JIRA)" <jira@apache.org>
To: dev@aries.apache.org
Message-ID: 
 <957398234.3149.1311584230517.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Created] (ARIES-712) Supporting application specific
 variables
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

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 is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira