[
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)
