[DS] Allow service Property to act as generic service target acting like e.g. a whiteboard target

[bjhargrave]

Original bug ID: BZ#3067 From: @juergen-albert Reported version: R7

[bjhargrave]

Comment author: @juergen-albert

I our recent whiteboard specs, we often use the concept of a service providing a filter, telling on what service it wants to be applied. An example would be the whiteboard target filters I can add to JaxrsResource or a Servlet or the application target on a JaxrsResource.

It would be great if such a mechanism could be supported directly by DS or if possible the framework itself.

A service property could be reserved for such a mechanism e.g. "service.target".

If this could be implemented on the Framework side, the ServiceTracker could be extended to take a Map of properties, it then will check the service.target filter against if it is set.

[bjhargrave]

Comment author: @bjhargrave

Can you please be more precise? I am unclear what you mean here. I don't see how we can define a service property that means different things to different bundles. This is why each whiteboard spec must specify its services properties and what they mean to the whiteboard implementation.

[bjhargrave]

Comment author: @juergen-albert

What I have in mind is something similar to e.g. the whiteboard target.

The following scenario:

We have a shop system, that can handle multiple tenants. Every tenant gets an own PaymentHandler via config admin

@ Component(name="TentantPaymentHandler", configurationPolicy=REQUIRED) public class TentantPaymentHandler implements IPaymentHandler{

@ Reference List paymentProvider;

public void doPayment(whatever){...}

}

Now we have 2 tenant configs:

{ "TentantPaymentHandler": { "tenant": "GoldTentant", "payedFor" : "gold" } }

{ "TentantPaymentHandler": { "tenant": "SomeOtherTentant", "payedFor" : "standard" } }

Now we provide a new PaymentProvider that should only be available to tenants that payed for the golf package. Thus I could register the new PaymentProvider with the following property: service.target=(payedFor=gold) Thus only the PaymentHandler for the GoldTenant would get the service without any changes to there configuration.

[bjhargrave]

Comment author: @rinswind

Normally a service consumer can see only service providers that are type compatible with it. I.e. both provider and consumer load the same service class.

As far as I understand you want to extend this mechanism so that a service consumer can only see the service providers that "select it" via a "service.target=", where the LDAP filter is applied to the service properties of the consumer.

This is similar to how the Java Modules export services to a select set of modules, but we want to use an LDAP filter rather than module/bundle IDs. Or to the attribute matching for the import/export of packages: https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#i2480178

If this is the case you can currently implement this with a secondary filtering withing the DS component. I.e. apply the "target" filter of each provider to your component's properties to get a subset of providers that select you. This is what we do in the JAX-RS implementation.

[bjhargrave]

Comment author: @bjhargrave

(In reply to Jürgen Albert from comment BZ#2)

Thus I could register the new PaymentProvider with the following property: service.target=(payedFor=gold) Thus only the PaymentHandler for the GoldTenant would get the service without any changes to there configuration.

But I don't see how this would scale out since there could be many consumers of a service which may have different filters having different filter key names to apply. This is why each whiteboard needs to define its own service property which then defines which filter key/values are usable.

Trying to put all that on one single standard service property would not scale at all.

[bjhargrave]

Comment author: @bjhargrave

CPEG mtg: Closing as wontfix.