[jira] [Updated] (OAK-3346) Analyze the usages of AbstractServiceTracker

["Francesco Mari (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OAK-3346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Francesco Mari updated OAK-3346:
--------------------------------
    Issue Type: Improvement  (was: Bug)

> Analyze the usages of AbstractServiceTracker
> --------------------------------------------
>
>                 Key: OAK-3346
>                 URL: https://issues.apache.org/jira/browse/OAK-3346
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: core
>            Reporter: Francesco Mari
>            Assignee: Francesco Mari
>
> A quick usage search of the AbstractServiceTracker returns the following information.
> {noformat}
> Class
>     AbstractServiceTracker
> Found usages  (11 usages found)
>     Production  (11 usages found)
>         Usage in extends/implements clause  (11 usages found)
>             oak-auth-external  (2 usages found)
>                 org.apache.jackrabbit.oak.spi.security.authentication.external.impl  (2 usages found)
>                     ExternalIDPManagerImpl  (1 usage found)
>                         (39: 45) public class ExternalIDPManagerImpl extends AbstractServiceTracker<ExternalIdentityProvider> implements ExternalIdentityProviderManager {
>                     SyncManagerImpl  (1 usage found)
>                         (40: 38) public class SyncManagerImpl extends AbstractServiceTracker<SyncHandler> implements SyncManager {
>             oak-core  (9 usages found)
>                 org.apache.jackrabbit.oak.spi.gc  (1 usage found)
>                     GCMonitorTracker  (1 usage found)
>                         (29: 39) public class GCMonitorTracker extends AbstractServiceTracker<GCMonitor> implements GCMonitor {
>                 org.apache.jackrabbit.oak.spi.whiteboard  (8 usages found)
>                     WhiteboardAuthorizableActionProvider  (1 usage found)
>                         (33: 17) extends AbstractServiceTracker<AuthorizableActionProvider>
>                     WhiteboardAuthorizableNodeName  (1 usage found)
>                         (29: 17) extends AbstractServiceTracker<AuthorizableNodeName>
>                     WhiteboardEditorProvider  (1 usage found)
>                         (36: 17) extends AbstractServiceTracker<EditorProvider>
>                     WhiteboardExecutor  (1 usage found)
>                         (30: 41) public class WhiteboardExecutor extends AbstractServiceTracker<Executor>
>                     WhiteboardIndexEditorProvider  (1 usage found)
>                         (36: 17) extends AbstractServiceTracker<IndexEditorProvider>
>                     WhiteboardIndexProvider  (1 usage found)
>                         (35: 17) extends AbstractServiceTracker<QueryIndexProvider>
>                     WhiteboardRestrictionProvider  (1 usage found)
>                         (38: 17) extends AbstractServiceTracker<RestrictionProvider>
>                     WhiteboardUserAuthenticationFactory  (1 usage found)
>                         (34: 17) extends AbstractServiceTracker<UserAuthenticationFactory>
> {noformat}
> I managed to analyze some of the implementations of AbstractServiceTracker in oak-core. My findings are the following.
> *WhiteboardAuthorizableActionProvider*
>   
> It's supposed to enable usage of multiple AuthorizableActionProvider. Currently only one AuthorizableActionProvider exists in the whole stack (DefaultAuthorizableActionProvider). Anyway, this seems a good use case for a dynamic, optional, multiple reference. Why not tracking AuthorizableAction services directly?
> Potential unwanted effects: some events may not be picked up by every AuthorizableAction.
> *WhiteboardAuthorizableNodeName*
> Tracks implementations of AuthorizableNodeName. At runtime, only one implementation is used. There is a default implementation that is used if no services are registered. If a new service with a better ranking starts, it is automatically picked up by the WhiteboardAuthorizableNodeName.
> The AuthorizableNodeName seems to be used only when the node name of an authorizable entity is created. Changing this implementation at runtime wouldn't harm anyone. This seems a good candidate for a dynamic, optional, unary reference.
> Potential unwanted effects: nodes in the repository will be named with different strategies even if only one implementation of AuthorizableNodeName is started.
> *WhiteboardEditorProvider*
> Tracks implemetations of EditorProvider. Currently multiple implementations of this services exist. Editors are a critical part of the repository, and they shouldn't probably be picked up using OSGi.
> I suggest a manual instantiation of the EditorProviders, as needed, during the initialization of the repository. As an alternative, decouple this logic into a separate component.
> Potential unwanted effects: some commits will not be performed with the full configuration of editors. Moreover, the relative order of the editors is not predictable, because it is chosen by OSGi and it's unspecified.
> *WhiteboardExecutor*
> Tracks implementations of Executor. If none is available, runs the Runnables in the current thread.
> Potential unwanted effects: none. Runnables will be executed, with a gradual degradation to a single-thread environment.
> *WhiteboardIndexEditorProvider*
> Tracks implementations of IndexEditorProvider. Same considerations apply as for WhiteboardEditorProvider.
> *WhiteboardIndexProvider*
> Tracks instances of QueryIndexProvider. 
> Potential unwanted effects: none. I assume that having a dynamic, optional, multiple reference is not harming anyone, since I assume that the query planner should be able to cope with the absence of some indexes.
> *WhiteboardRestrictionProvider*
> Tracks implementations of RestrictionProvider. There is currently only one instance of this type in the system. If no implementation is available, a default implementation is used as a fallback. The default implementation throws exceptions when some methods of the API are invoked. I suggest a mandatory, unary reference to RestrictionProvider instead of using the whiteboard.
> Potential unwanted effects: the system starts with the default RestrictionProvider, throwing exceptions in some cases.
> *WhiteboardUserAuthenticationFactory*
> Tracks implementations of UserAuthenticationFactory. There is currently only one implementation in the system. If no implementation is found, the system falls back to the default implementation. The funny aspect of this is that the default, fallback implementation (UserAuthenticationFactoryImpl) is also the only implementation exposed as a service so, no matter what happens, nothing changes.
> Is the configurability of UserAuthenticationFactory still relevant?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)