[
https://issues.apache.org/jira/browse/OAK-3201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari updated OAK-3201:
--------------------------------
Attachment: OAK-3201-04.patch
[~chetanm], I started outlining a possible solution in [^OAK-3201-04.patch],
but I found very difficult to retrofit the current version of
{{SecurityProviderImpl}} - and related classes - to the solution.
In particular, many classes require a {{SecurityProvider}} to be injected. They
usually save the injected instance of {{SecurityProvider}} in an instance
variable and use it for their purposes. In example, see {{ConfigurationBase}},
the base class of many configuration classes.
IMO this approach is wrong if there are multiple implementations of
{{SecurityProvider}} around using the same configurations. Do you have any idea
about how to solve this problem without refactoring the internal APIs?
> 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,
> OAK-3201-04.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)
