karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: [Discuss] How to handle config dependent service references using DS?
Date Thu, 18 Feb 2016 12:38:20 GMT
Hi Christian,

As discussed on IRC, I'm in favour of 2.

Yes it introduces a difference with previous cfg file content (but it's 
not a big deal as we changed version from 1.0.x to 1.1.x), maybe not as 
easier to read for users as "plain" name, but very convenient.

Regards
JB

On 02/18/2016 01:09 PM, Christian Schneider wrote:
> I am currently working on the migration of decanter to DS:
> https://issues.apache.org/jira/browse/KARAF-4344
>
> 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
> annoations:
>   @Reference(target="(osgi.jndi.service.name=jms/decanter)")
>      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".
> ConnectionFactory.target=(name=myjms)
> 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:
> https://git-wip-us.apache.org/repos/asf?p=karaf-decanter.git;h=8c3e004
>
> I am open to other solutions of course.
>
> Christian
>
>
>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Mime
View raw message