[ https://issues.apache.org/jira/browse/OAK-3346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Francesco Mari resolved OAK-3346. --------------------------------- Resolution: Fixed Resolving this issue, as the results of the analysis could be outdated or not relevant anymore. > 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)