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