[
https://issues.apache.org/jira/browse/OAK-3201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14695383#comment-14695383
]
angela commented on OAK-3201:
-----------------------------
i can't tell you what would be suited from an OSGi point of view. what looks a
bit awkward to me is the fact that settings of the various security related
modules get mixed in that SecurityProviderSettings.
if going with the settings approach is considered the correct solution, i would
prefer to have it separated from 'usermanagement' and 'authorization'.
alternatively, we might consider removing it from the security provider
altogether and just make them become referenced in the
{{UserConfigurationImpl}} and {{AuthorizationConfigurationImpl}} respectively.
the reason why these configurations are treated differently from the
security-module setup is the fact that most of them can be considered an
implementation detail of the module.
for example: it's just an implementation detail of the user management, that
there exists something like a {{AuthorizableNodeName}} and an
{{AuthorizableActionProvider}}... someone plugging his custom user management
implementation by just deploying another service implementing
{{UserConfiguration}} might just not have this special thingies in place.
that's why they ended up in the {{ConfigurationParamters}} associated with the
module configuration and not being regularly exposed as part of the API such as
{{UserConfiguration.getUserManager}}.
i don't feel particularly attached to having those 'special' configurations in
the {{SecurityProvider}} if there is a better way to achieve the same (or
better) result... as long as we can have the java setup I am fine.
After all that would feel more natural to me than inventing an artificial
{{SecurityProviderSettings}} that doesn't reflect the fact that those settings
are actually tied to the individual security modules and not the
{{SecurityProvider}} itself... that latter is just the 'entry point' and the
extra stuff ended up there for well... probably for not properly working it out
and my hesitation to add "@Reference" annotations to the individual security
configuration implemenations.
wdyt? would that work? wouldn't it even make more sense?
> 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
> Attachments: OAK-3201-01.patch
>
>
> {{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)
