[jira] [Comment Edited] (OAK-3434) Revert backwards-incompatible changes to SecurityProviderImpl

["Francesco Mari (JIRA)" <ji...@apache.org>]

    [ 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)