[
https://issues.apache.org/jira/browse/OAK-9047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17099855#comment-17099855
]
Julian Sedding edited comment on OAK-9047 at 5/5/20, 1:06 PM:
--------------------------------------------------------------
{quote}[...] that's why Francesco Mari introduced the
SecurityProviderRegistration and the mandatory services in the first place.
{quote}
That seems to be a variation of the same problem discussed in this issue. The
constituent services for a functioning repository must not become available
before they are properly configured. This is inherently difficult to achieve in
OSGi.
I wonder if a better strategy to address this would be de-modularisation of the
repository startup, i.e. have a single required configuration and hook all
parts together in plain Java before registering the repository.
Clearly there is a trade-off between a stable repository startup sequence some
disadvantages, e.g. backwards compatibility with current configurations and
substituting a custom implementations for some components would not work/would
need to be done differently.
Maybe a possibility could be a repository factory service that is used by a
repository registration service. The repository registration service could be
configured to require a specific repository factory and, once available, would
call it to get a repository instance and register it. Repository factory
implementations could require a configuration to prevent eager startup or be
manually registered after checking a number of requirements, thus making sure
everything is properly available before a repository is created (similar to
SecurityProviderRegistration does today). The current status quo could become
the default implementation for the repository factory (without required
configuration). However, another factory could then use stricter checks.
{quote}[We can solve any problem by introducing an extra level of
indirection.|https://en.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering]
{quote}
On a somewhat related note: (at least in AEM) the NodeStore service is
currently explicitly hidden, which makes sense, because it is an implementation
detail. Registering the NodeStore as a service would not be required at all
with a suitable repository factory. Maybe the desire to hide this service is an
indication that the OSGi service registry is the wrong place to hook all parts
together?
was (Author: jsedding):
bq. [...] that's why Francesco Mari introduced the SecurityProviderRegistration
and the mandatory services in the first place.
That seems to be a variation of the same problem discussed in this issue. The
constituent services for a functioning repository must not become available
before they are properly configured. This is inherently difficult to achieve in
OSGi.
I wonder if a better strategy to address this would be de-modularisation of the
repository startup, i.e. have a single required configuration and hook all
parts together in plain Java before registering the repository.
Clearly there is a trade-off between a stable repository startup sequence some
disadvantages, e.g. backwards compatibility with current configurations and
substituting a custom implementations for some components would not work/would
need to be done differently.
Maybe a possibility could be a repository factory service that is used by a
repository registration service. The repository registration service could be
configured to require a specific repository factory and, once available, would
call it to get a repository instance and register it. Repository factory
implementations could require a configuration to prevent eager startup or be
manually registered after checking a number of requirements, thus making sure
everything is properly available before a repository is created (similar to
SecurityProviderRegistration does today). The current status quo could become
the default implementation for the repository factory (without required
configuration). However, another factory could then use stricter checks.
bq. [We can solve any problem by introducing an extra level of
indirection.|https://en.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering]
> Make the DefaultAuthorizableActionProvider require a configuration
> ------------------------------------------------------------------
>
> Key: OAK-9047
> URL: https://issues.apache.org/jira/browse/OAK-9047
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: security-spi
> Reporter: Konrad Windszus
> Priority: Major
>
> Currently configuring the {{DefaultAuthorizableActionProvider}} leads to
> restart of the Oak repository in the context of
> https://issues.apache.org/jira/browse/SLING-7811?focusedCommentId=16573171&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16573171.
>
> It would make sense to only start the service
> https://github.com/apache/jackrabbit-oak/blob/1f90e8c632868e658cc60b95bc5ec49182c4e173/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/user/action/DefaultAuthorizableActionProvider.java#L45
> once a mandatory configuration is in place.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
