aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Balazs Zsoldos (JIRA)" <>
Subject [jira] [Created] (ARIES-712) Supporting application specific variables
Date Mon, 25 Jul 2011 08:57:10 GMT
Supporting application specific variables

                 Key: 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:


View raw message