[
https://issues.apache.org/jira/browse/OAK-7024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16326247#comment-16326247
]
Alex Deparvu edited comment on OAK-7024 at 1/15/18 3:06 PM:
------------------------------------------------------------
Just realised the proposed approach for the consumers would not work, it
crashes due to the missing method on old services:
{code}
Set<Principal> principals = new HashSet<>();
principals.add(userPrincipal);
principals.addAll(principalProvider.getGroupMembership(userPrincipal));
principals.addAll(principalProvider.getMembershipPrincipals(userPrincipal));
return principals;
{code}
What would be needed here is a way to signal which of the 2 methods should be
called _getGroupMembership_ (old code still called due to backwards
compatibility constrains) OR _getMembershipPrincipals_ (new code, renders old
method obsolete). This could be done via a new interface
_AdvancedPrincipalProvider_ that marks the compatibility.
Any other thoughts on how this could be achieved?
[edit] Had an offline chat with [~mreutegg] and uncovered a design flaw I
missed earlier.
With the introduction of a PrincipalProvider extension we will possibly find
ourselves in the situation where implementors of this code would have to update
_twice_ due to the cycle of changes: first add a new method using
groupprincipals, second remove the old alc.group method.
The only way to avoid this situation is to branch the 2 PrincipalProviders
right away and have only a symbolic overlap (common BasePP to simplify code).
was (Author: alex.parvulescu):
Just realised the proposed approach for the consumers would not work, it
crashes due to the missing method on old services:
{code}
Set<Principal> principals = new HashSet<>();
principals.add(userPrincipal);
principals.addAll(principalProvider.getGroupMembership(userPrincipal));
principals.addAll(principalProvider.getMembershipPrincipals(userPrincipal));
return principals;
{code}
What would be needed here is a way to signal which of the 2 methods should be
called _getGroupMembership_ (old code still called due to backwards
compatibility constrains) OR _getMembershipPrincipals_ (new code, renders old
method obsolete). This could be done via a new interface
_AdvancedPrincipalProvider_ that marks the compatibility.
Any other thoughts on how this could be achieved?
[edit] has an offline chat with [~mreutegg] and uncovered a design flaw I
missed earlier.
With the introduction of a PrincipalProvider extension we will possibly find
ourselves in the situation where implementors of this code would have to update
_twice_ due to the cycle of changes: first add a new method using
groupprincipals, second remove the old alc.group method.
The only way to avoid this situation is to branch the 2 PrincipalProviders
right away and have only a symbolic overlap (common BasePP to simplify code).
> java.security.acl deprecated in Java 10, marked for removal in Java 11
> ----------------------------------------------------------------------
>
> Key: OAK-7024
> URL: https://issues.apache.org/jira/browse/OAK-7024
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: security
> Reporter: Julian Reschke
> Assignee: Alex Deparvu
> Priority: Major
> Fix For: 1.10
>
>
> See <https://bugs.openjdk.java.net/browse/JDK-8175094> and
> <https://bugs.openjdk.java.net/browse/JDK-8191138>.
> Need to understand how this affects public Oak APIs, and what to do with them
> on Java 11 (which will be an LTS release we probably need to support with Oak
> 1.10).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
