[
https://issues.apache.org/jira/browse/OAK-3201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14736579#comment-14736579
]
Chetan Mehrotra commented on OAK-3201:
--------------------------------------
bq. Every deployment using the current version of SecurityProviderImpl is
broken anyway. Maybe the bug didn't hit them, but it's there.
Ack there is a race condition and a small potential window where security
provider is not stable. But one fix cannot break other parts. We should still
be able to come up with a fix which can address the current issue without
breaking backward compatibility and loss of current featureset. Also even with
current proposed approach it would not be possible to support multiple
restriction providers
bq. Talking about dynamism, why the relationships to those interfaces are
modeled that way? Do we really expect a RestrictionProvider or an
AuthorizableNodeName to come and go at runtime?
I cannot comment on that as I have not implemented that part. However for any
logic which supports multiple implementations (kind of multiplexing) such
problem exist
> Use static references in SecurityProviderImpl for composite services
> --------------------------------------------------------------------
>
> Key: OAK-3201
> URL: https://issues.apache.org/jira/browse/OAK-3201
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
> Reporter: Francesco Mari
> Assignee: Francesco Mari
> Fix For: 1.3.6
>
> Attachments: OAK-3201-01.patch, OAK-3201-02.patch, OAK-3201-03.patch,
> mbean-test.log
>
>
> {{SecurityProviderImpl}} has dynamic references to many other services, like
> {{RestrictionProvider}}, that represent the configuration of this component.
> Being these services dynamic, the OSGi runtime has no clear dependency
> relationship between the {{SecurityProviderImpl}} and the required services.
> Thus, it may happen that an instance of {{SecurityProviderImpl}} is published
> before the services it requires are started, creating a window where the
> {{SecurityProviderimpl}} is operating differently from the way it's
> configured.
> I suggest to turn the dynamic references in {{SecurityProviderImpl}} to
> static ones to improve the consistency of the implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
