OSGi DS dynamic target filter properties

[Bryan Hunt]

Hi all,

I'm considering proposing an OSGi feature request and I wanted to run it by this list for feedback before submitting it.

I would like to propose the addition of dynamic target filter properties for declarative services. This would allow the target filter on a reference to be evaluated after the service has been configured, and the configuration properties would be available to build the target filter. For example, consider the reference:

@Component
public class Component
{
@Reference(target = "(alias = ${alias})"
public void bindService(Service service)
}

${alias} is a dynamic filter property set to the value of the "alias" property when the referencing service is configured. So if the above component was configured with "alias = primary", then the reference would evaluate to:

@Reference(target = "(alias = primary)"

I have a real-world use case where this would eliminate a lot of nasty code that manages dynamic references to hook up two services based on their property values.

Thoughts?

Bryan

[Neil Bartlett]

It's an attractive proposal. Unfortunately I think it leads to fairly
deep-level changes for the DS implementers. Service references are
bound before the component is activated, so you need to access the
component configuration before activation. Therefore this is not just
a matter of tinkering with the target filters.

The EGs will only consider including this feature after careful (read:
long) deliberation... so don't hold your breath! Nevertheless I still
like the basic idea. You should post it on the osgi-dev mailing list.

Cheers,
Neil

[Felix Meschberger]

Hi

I agree that this sound interesting.

There is already the possibility to set a config property <refname>.target to set the reference target ldap filter. In this respect that proposal looks like a simplification of this feature.

I wonder whether such a feature could in fact be folded into the targer property ?

Regards

Felix

-------- Ursprüngliche Nachricht --------
Von: Neil Bartlett <njbar...@gmail.com>
Datum:
An: bndtool...@googlegroups.com
Betreff: Re: OSGi DS dynamic target filter properties

--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Bryan Hunt]

Hi Felix,

I was unaware that this feature existed - guess I need to read the spec more closely :)  Since I'm using dynamic metatype instead of the static files, I think I can get this to work in an elegant manner.

Thanks!

Bryan

[Bryan Hunt]

Yep, that worked.  I just deleted some very ugly code.  Awesome!

Thanks again Felix.

Bryan

[Felix Meschberger]

Hi Bryan

Thanks for the feedback. Glad it soves your problem.

Regards

Felix

--

Felix Meschberger  |  Principal Scientist  |  fmes...@adobe.com

[Markus Wolf]

Hi there,

indeed this sounds interesting.

I'm kind of new to OSGi DS so I could not directly identify what to do to try it, but I would need such kind of feature (dynamically decide which reference is injected).

Can someone give me a hint on how to find some more information?

Kind regards

Markus

[Bryan Hunt]

Here how you do this ...

You set the service property key to [type].target where [type] is the type of the reference being bound - for example: "MongoClientProvider.target"

And you set the service property value to your LDAP filter - for example: "(client_id=local)"

Using the above example, the service property would look like: MongoClientProvider.target = (client_id=local)  and would be the filter for:

  public void bindMongoClientProvider(MongoClientProvider mongoClientProvider)

  {

  this.mongoClientProvider = mongoClientProvider;
}

The above bind function would only be called with an instance of MongoClientProvider that has a service property client_id = local.

Here is an example that uses this technique with dynamic metatype ...

https://github.com/BryanHunt/eMongo/blob/master/bundles/org.eclipselabs.emongo.components/src/org/eclipselabs/emongo/metatype/MongoDatabaseMetaTypeProvider.java

Hope this helps.

Bryan

[David Jencks]

As others have noted this area isn't explained all that well in one place AFAIK, and unfortunately I'm not going to fix that situation here :-)

At the moment I think that as far as DS goes the existing ability to set <ref-name>.target from config admin is all that is desirable and no changes should be made in DS.

If you need some kind of expression evaluation to set up these configuration properties I think the place to put it is in the code that feeds config admin, whether that be metatype or something else.

thanks

david jencks

ps. btw, "MongoClientProvider" in your example doesn't come from the type, it comes from removing the "bind" prefix from the bind method name bindMongoClientProvider.  If you named it bindFoo then the config property would be

Foo.target=(client_id-local)

[Raymond Auge]

Awesome! This will be handy in the future I'm sure.

I think it'd be worth documenting.

On Wed, Nov 27, 2013 at 1:08 PM, David Jencks <david.a...@gmail.com> wrote:

As others have noted this area isn't explained all that well in one place AFAIK, and unfortunately I'm not going to fix that situation here :-)

At the moment I think that as far as DS goes the existing ability to set <ref-name>.target from config admin is all that is desirable and no changes should be made in DS.

If you need some kind of expression evaluation to set up these configuration properties I think the place to put it is in the code that feeds config admin, whether that be metatype or something else.

thanks

david jencks

ps. btw, "MongoClientProvider" in your example doesn't come from the type, it comes from removing the "bind" prefix from the bind method name bindMongoClientProvider.  If you named it bindFoo then the config property would be

Foo.target=(client_id-local)

I was wondering about that very thing, because type inference would have limited the refs to one of each type.

--

Raymond Augé (@rotty3000)

Senior Software Architect

Liferay, Inc. (@Liferay)

[Neil Bartlett]

On Wed, Nov 27, 2013 at 6:08 PM, David Jencks <david.a...@gmail.com> wrote:

As others have noted this area isn't explained all that well in one place AFAIK, and unfortunately I'm not going to fix that situation here :-)

At the moment I think that as far as DS goes the existing ability to set <ref-name>.target from config admin is all that is desirable and no changes should be made in DS.

If you need some kind of expression evaluation to set up these configuration properties I think the place to put it is in the code that feeds config admin, whether that be metatype or something else.

thanks

david jencks

ps. btw, "MongoClientProvider" in your example doesn't come from the type, it comes from removing the "bind" prefix from the bind method name bindMongoClientProvider.  If you named it bindFoo then the config property would be

Foo.target=(client_id-local)

That's not quite it either. It comes from the "name" attribute of the "reference" element in the Declarative Services XML file. Exactly how the name is generated depends on the build tool. But ince DS 1.1 you can leave the name blank and then it will default to the typename of the service interface (see Compendium section 112.4.8 and Table 112.8).

Neil

[David Jencks]

Hi Neil,

Hmm, there may be some inconsistency in the spec here.  Bryan started out using the (I assume DS) @Reference annotation, and 112.13.8.1 explains

String name default “”

The name of this reference.
If not specified, the name of this reference is based upon the name of the method being annotated. If

the method name begins with bind, set or add, that is removed.

so a spec compliant build tool will end up generating Foo from bindFoo.  If you don't use the DS annotations, the rule you mention comes into play.

thanks

david jencks

[Neil Bartlett]

Thanks David. Actually I had assumed that the annotations were bnd rather than standard DS... it's not clear I suppose. In which case the "bind" prefix would have had no special meaning.

Anyway I don't believe it's an inconsistency in the spec. I interpret this as saying the build tool should generate the name attribute in the XML as specified in the section you quoted (112.13.8)... whereas the section I quoted (112.4.8) deals with behaviour of the runtime extender when the name attribute is missing from the XML -- e.g. because somebody wrote the XML by hand rather than generating from annotations.

Neil