[ https://issues.apache.org/jira/browse/OAK-7024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16324091#comment-16324091 ]
Alex Deparvu commented on OAK-7024: ----------------------------------- bq. choose an intermediate step still supporting it but marking it deprecated and log a warning if those methods are called. Makes perfect sense, and was my intention all along. The tricky part is to outline parts that need to work with both types of groups. I would distinguish 2 categories of classes: providers (various PrincipalProvider impls) and consumers, excuse the naming clash with the OSGi, I could not find a better reference. Providers: * ExternalGroupPrincipalProvider is a provider and can simply return empty on the old method, zero backwards comp obligations here * PrincipalProviderImpl - not sure it can ever see both types of groups * AbstractGroupPrincipal - does this need to implement acl.Group? * UserPrincipalProvider - again, looks like a provider so no need to handle both types Consumers: * CompiledPermissionImpl is a consumer and needs to worry about handling both types of groups * ImpersonationImpl - looks like a consumer again, needs to handle both types * AbstractLoginModule - seems like a big entry point, it looks like this needs to handle both methods, here's where the BC policy comes in * PrincipalManagerImpl - same as AbstractLoginModule, collects principals out of the PrincipalProvider and needs to handle both types So Consumers are hit worse by the changes, if there is custom code that still needs to work, it would probably interact (provide principals) to the components listed above. Now for the interesting part, how do we handle both methods in AbstractLoginModule and PrincipalManagerImpl without introducing issues in the long run? I think a good solution is to aggregate principals coming in from both methods old and new and when the time comes drop the old method. Worst case here is that we'll get some duplicates, but everything keeps working. > 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 > 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 (v6.4.14#64029)