[
https://issues.apache.org/jira/browse/OAK-3434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14902733#comment-14902733
]
Francesco Mari edited comment on OAK-3434 at 9/22/15 2:43 PM:
--------------------------------------------------------------
The current implemented approach registers the new {{SecurityProvider}} with a
property {{type=default}}. This property can be used to reference the correct
{{SecurityProvider}}. I think that there are a couple of solutions to this
problem, anyway:
1. A {{policy=ConfigurationPolicy.REQUIRE}} could be added to
{{SecurityProviderImpl}} so that it will be disabled unless some OSGi
configuration is explicitly provided. {{SecurityProviderImpl}} would still be a
component, just not active by default.
2. The {{@Component}} annotation could be removed, removing any chance that
{{SecurityProviderImpl}} would hit the service registry again. While this would
not impact the backwards compatibility of {{SecurityProviderImpl}}, this would
increase the version of the exported package to {{2.0.0}}, unless we manually
implement the methods that are currently generated by the Maven SCR plugin. I
don't think that this is an option.
3. Ignore the issue on our side and fix the clients to reference the new
{{SecurityProvider}} with a filter using on the {{type}} property.
[~chetanm], if you think that the first solution would fix the problem, I can
go ahead and make the fix.
was (Author: frm):
The current implemented approach registers the new {{SecurityProvider}} with a
property {{type=default}}. This property can be used to reference the correct
{{SecurityProvider}}. I think that there are a couple of solutions to this
problem, anyway:
1. A {{policy=ConfigurationPolicy.REQUIRE}} could be added to
{{SecurityProviderImpl}} so that it will be disabled unless some OSGi
configuration is explicitly provided. {{SecurityProviderImpl}} would still be a
component, just not active by default.
2. The {{@Component}} annotation could be removed, removing any chance that
{{SecurityProviderImpl}} would hit the service registry again. While this would
not impact the backwards compatibility of {{SecurityProviderImpl}}, this would
increase the version of the exported package to {{2.0.0}}. I don't think that
this is an option.
3. Ignore the issue on our side and fix the clients to reference the new
{{SecurityProvider}} with a filter using on the {{type}} property.
[~chetanm], if you think that the first solution would fix the problem, I can
go ahead and make the fix.
> Revert backwards-incompatible changes to SecurityProviderImpl
> -------------------------------------------------------------
>
> Key: OAK-3434
> URL: https://issues.apache.org/jira/browse/OAK-3434
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security
> Reporter: Francesco Mari
> Assignee: Francesco Mari
> Fix For: 1.3.7
>
> Attachments: OAK-3434-01.patch
>
>
> OAK-3201 introduced some backwards-incompatible changes to
> {{SecurityProviderImpl}}. It should be investigated if those changes can be
> reverted to maintain the backwards compatibility of the
> {{org.apache.jackrabbit.oak.security}} package.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
