jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Francesco Mari (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (OAK-3346) Analyze the usages of AbstractServiceTracker
Date Fri, 04 Sep 2015 07:42:46 GMT

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

Mime
View raw message