karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject [Discuss] How to handle config dependent service references using DS?
Date Thu, 18 Feb 2016 12:09:34 GMT
I am currently working on the migration of decanter to DS: 

Most of the modules translate to DS quite naturally.  We have two module 
though that are a bit special - the jms and jdbc appenders.

Lets take jms:
The connection factory is specified in the config as 
"connection.factory.name" with a default of "jms/decanter".

In the Activator a ServiceTracker is created that tries to bind the 
ConnectionFactory service using a filter of:
"(&(" + Constants.OBJECTCLASS + "=" + ConnectionFactory.class.getName() 
+ ")(|(osgi.jndi.service.name=" + cfName + ")(name=" + cfName + 
")(service.id=" + cfName + ")))";
where cfName is the config value specified above.

These kinds of configuration dependent references are difficult to 
implement in both blueprint and declarative services.

I see two ways to implement this:

1. Create a ServiceTracker inside the activate method of the DS 
component with a fitler determined by the config.
This allows to keep the config format as is but the solution is quite 
verbose and completely skips the DS mechanisms.
So for example the component will be active even if the 
ConnectionFactory service is not found. Inside it would then do a 
special internal processing to only really activate itself
when the service is present.

2. Use a generic DS feature to override a target filter
In this case we reference the ConnectionFactory service using standard 
     public void setConnectionFactory(ConnectionFactory 
connectionFactory) ...
Target allows to set the default OSGi filter.
DS then allows to override this filter using a configuration property 
name like the method + ".target".
This approach needs a change in the way the module is configured but is 
much simpler to implement.
It also allows to use the scr:details command to see what service the 
Component is looking for. So this makes the system easier to diagnose by 
the administrator.

I prefer the solution 2. The change in the configuration format should 
be ok in a minor release if we properly announce it in the release notes.
I implemented it in a branch so you can look into it:

I am open to other solutions of course.


Christian Schneider

Open Source Architect

View raw message