[
https://issues.apache.org/jira/browse/SLING-6014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15551619#comment-15551619
]
David Bosschaert commented on SLING-6014:
-----------------------------------------
Just adding my 2c to this issue...
While service blacklisters can certainly be done using OSGi Service Hooks, and
they give you a lot of possibilities, there are reasons to think twice before
this is done in a widely used environment.
1. The hooks need to be installed before anything else, otherwise clients can
get an inconsistent view of a certain service. So let's say a client bundle B
comes online before the blacklister. Then a service S is registered. Client B
will see S. If the blacklister is installed at this point and intends to hide S
from B, B will not receive any service events for S any more, so even if S is
unregistered B will not know anything about it any more.
2. More importantly, the system becomes harder to understand. If someone is
troubleshooting the system and tries to understand why a given client cannot
see a certain service, it becomes impossible to see what services are hidden by
just looking at the webconsole and the troubleshooting becomes very hard. So
*if* something like a ServiceBlacklister is implemented I would recommend that
it would come with a Web Console extension that makes it very clear what
services are being hidden from whom.
> [ServiceBlacklister] Allow to blacklist OSGi services given generic criteria
> to prevent finding them in OSGi container
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: SLING-6014
> URL: https://issues.apache.org/jira/browse/SLING-6014
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
> Reporter: Arek Kita
>
> h3. Case study
> The OSGi container gives an ability for specific {{InterfaceAB}} to find a
> service that implements given interface. Sometimes more services might
> implement and satisfy this interface, i.e. {{ServiceA}} and {{ServiceB}}.
> Based on service ranking (if present) services are used in specific order.
> h3. The purpose
> The goal of service blacklister is to *exclude* i.e. {{ServiceB}} from
> finding in OSGi container so always {{ServiceA}} gets used no matter what
> service ranking is specified.
> h3. Typical use cases
> Imagine that {{ServiceB}} gets deprecated and it should be no longer used and
> referenced, however it is widespread and there is no easy way of identifying
> its bundle (multiple bundles or in other words bundles with different
> symbolic names may provide it) or it can be installed using many ways and for
> existing Sling instances there no easy way of disabling it by changing
> service ranking or uninstalling unknown bundle.
> The service blacklister idea accepts the fact that the service might live
> still in OSGi container but using a service-related (service-oriented)
> generic criteria and
> [FindHook|https://osgi.org/javadoc/r4v42/org/osgi/framework/hooks/service/FindHook.html]
> API the service might be excluded from OSGi service find operations which
> effectively prevents this service from being referenced.
> h3. The idea
> The idea would be to create a generic *{{ServiceBlacklister}}* OSGi component
> that allows to specify OSGi configurations through configuration factory
> defining a generic criteria (i.e. LDAP-like search query criteria) for
> blacklisting services.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
