karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Achim Nierbeck <bcanh...@googlemail.com>
Subject Re: [Discuss] How to handle config dependent service references using DS?
Date Sat, 20 Feb 2016 21:14:23 GMT

finally had the time to take a closer look at it.
Solution 2 sound good to me.
Regarding, the question if this change is ok for a minor release.
>From my point of view it's ok, as long as an old configuration still would
work, even though
an old entry might not be respected. It shouldn't fail on starting

regards, Achim

2016-02-18 13:38 GMT+01:00 Jean-Baptiste Onofré <jb@nanthrax.net>:

> 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


Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message