[DS] Annotation support for target filters?

[bjhargrave]

Original bug ID: BZ#2956 From: @cziegeler Reported version: R6

[bjhargrave]

Comment author: @cziegeler

At the community event there was some feedback from several people that it would be great to have some type safe / less error prone way to define the target filter for references. I think Simon Chemouil pointed out that he had suggested this while back ago on the bnd users list (I couldn't find the reference yet). I'm not sure if there is a good way, and I guess a potential solution might only cover some use cases, but as we got the feedback we should at least discuss this.

[bjhargrave]

Comment author: @rinswind

There is a need to specify "configuration derived" target filters in a much simpler way. We have an issue with forcing our users to learn LDAP in order to reference one configuration from another.

E.g. define an HTTPS connector in one property file on disk and have that reference a keystore defined in another property file. Right now you need to add something like "keystore.target=(name=MyKeyStore)" in the HTTPS connector configuration and have "name=MyKeyStore" in the keystore configuration.

One way this can be resolved is to let the DS component developer specify which scalars from the configuration have to be combined to build up the target filter.

E.g. support parameter substitution in the "target" setting of a reference:

// In the HTTPS connector component @ Reference(service=KeyStore.class, target="(name=${keystoreName})") public void setKeystore(KeyStore store) { .... }

In the HTTPS connector configuration

keystoreName=MyKeyStore

Also if "keystore.target" is explicitly defined it overrides the expression in @ Reference and "keystoreName" can be omitted.

[bjhargrave]

Comment author: @rinswind

Also it may be beneficial to provide a compositional solution to this. E.g. register a secondary DS component that is a configuration filter or something similar. It is worrying how DS becomes ever more complex.

[bjhargrave]

Comment author: @bjhargrave

Since SCR processes only XML at runtime, first express a potential solution in the form of the XML and the runtime changes. After that, the annotations changes which support generating the XML at tool time.

(In reply to Todor Boev from comment BZ#1)

There is a need to specify "configuration derived" target filters in a much simpler way. We have an issue with forcing our users to learn LDAP in order to reference one configuration from another.

LDAP filters are a key aspect of the service layer in OSGi.

E.g. define an HTTPS connector in one property file on disk and have that reference a keystore defined in another property file. Right now you need to add something like "keystore.target=(name=MyKeyStore)" in the HTTPS connector configuration and have "name=MyKeyStore" in the keystore configuration.

One way this can be resolved is to let the DS component developer specify which scalars from the configuration have to be combined to build up the target filter.

E.g. support parameter substitution in the "target" setting of a reference:

// In the HTTPS connector component @ Reference(service=KeyStore.class, target="(name=${keystoreName})") public void setKeystore(KeyStore store) { .... }

This will generate, in the XML, the property "keystore.target=(name=${keystoreName})". So the configuration can only override this by specifying a keystore.target property whose value is a filter expression.

In the HTTPS connector configuration

keystoreName=MyKeyStore

Also if "keystore.target" is explicitly defined it overrides the expression in @ Reference and "keystoreName" can be omitted.

I am not sure I see that another layer of indirection is helpful here. You just want to tell people to set "keystoreName=MyKeyStore" in the configuraton instead of "keystore.target=(name=MyKeyStore)"? Seems a small "win" at the expense of complicating the specification and runtime implementation with parameter substitution.

There has been discussion in the past about placeholder substitution. In Blueprint, this was rejected. See bug BZ#1738 for example. I think that was similar discussions for DS. I only found bug BZ#1424 which is similar but nor quite the same. Perhaps the CPEG mail archives hold something.

I don't see adding placeholders as a good idea for DS. It complicates the spec and the runtime and does not provide enough value to justify that.

[bjhargrave]

Comment author: @rinswind

LDAP filters may be common in OSGi, but the users I refer to the end users that don't know or care that the underlying impl is OSGi. It is odd to tell them that a certain property is an LDAP filter over the properties of another configuration and point them to the RFC.

[bjhargrave]

Comment author: @cziegeler

Getting back to the original suggestion, I looked up what Simon has designed. It goes back to something similar to our new ComponentPropertyType annotation (RFC 2.2.2, section 5.10). I don't like the following approach as it has too many open ends, but just for completeness:

@ ComponentPropertyType public @ interface Fields { String foo_bar(); String xyz_field(); }

and then

@ Reference public void bindService(@ Fields(foo_bar = "*") MyService service)

which then would result in a target filter "(foo.bar = *)". If you have several annotations on the parameter they are used to create a "and" filter expression.

The idea behind additional annotations is to avoid typos in the filter expression, with the above approach you get this for the filter expression itself. But with the cost of defining your special annotation first, where you can make the typos. And then what about using different types than String and all these things.

I think it'S not worth going down this road, unless someone has a clever idea on how to make this work in an elegant (maybe totally different) way

[bjhargrave]

Comment author: @bjhargrave

OK, then lets close this. If a better idea comes along, we can reopen.