Hi Jorge Yes, that has changed with OAK-10135<https://issues.apache.org/jira/browse/OAK-10135> for consistency reasons.
Instead of casting to a spi class (ImmutableAcl) or checking for that one, I would suggest you verify that the given effective policy is a JackrabbitAccessControlPolicy. This is the interface that provides the getPath() method. see https://github.com/apache/jackrabbit-oak/blob/trunk/oak-jackrabbit-api/src/main/java/org/apache/jackrabbit/api/security/JackrabbitAccessControlPolicy.java#L38 This way you don't rely on some implementation detail and it will work for all types of policies provided by any kind of authorization model. hope that helps Angela ________________________________ From: Jorge Flórez <jorgeeduardoflo...@gmail.com> Sent: Wednesday, May 31, 2023 18:50 To: oak-dev@jackrabbit.apache.org <oak-dev@jackrabbit.apache.org> Subject: Re: Moving to Oak 1.50 or newer EXTERNAL: Use caution when clicking on links or opening attachments. Hi, it would seem there is a difference, when I have to get the node paths that have an entry with a specific privilege for a user. I am getting a java.lang.ClassCastException: class org.apache.jackrabbit.oak.spi.security.authorization.accesscontrol.ReadPolicy cannot be cast to class org.apache.jackrabbit.oak.spi.security.authorization.accesscontrol.ImmutableACL Using JackrabbitSession jcrSession = (JackrabbitSession) session; JackrabbitAccessControlManager acMgr = (JackrabbitAccessControlManager) jcrSession.getAccessControlManager(); AccessControlPolicy[] policies = acMgr.getEffectivePolicies(Collections.singleton(userPrincipal)); for (AccessControlPolicy policy : policies) { p = (ImmutableACL) policy; path = p.getPath(); //... } The getEffectivePolicies method returns objects of type ImmutableACL and an object of type ReadPolicy. I guess I will just have to check before casting, right? Jorge El mar, 23 may 2023 a las 8:24, Jorge Flórez (<jorgeeduardoflo...@gmail.com>) escribió: > Hi Marcel, > thank you for your reply. Regarding MongoDB, it looks like we are covered. > I need to make some changes in my source code regarding the tika and > tika-parsers version. And I got some warnings in the server log like > > WFLYSRV0003: Could not index class com/google/common/io/Closer.class > WFLYSRV0003: Could not index class > com/google/common/util/concurrent/AbstractListeningExecutorService.class > WFLYSRV0003: Could not index class > org/apache/jackrabbit/guava/common/io/Closer.class > > But besides that, it seems it will work :) > I will let you all know if something comes up. > > Best Regards. > Jorge > > El lun, 22 may 2023 a las 3:26, Marcel Reutegger > (<mreut...@adobe.com.invalid>) escribió: > >> Hi Jorge, >> >> On 16.05.23, 20:37, "Jorge Flórez" <jorgeeduardoflo...@gmail.com> wrote: >> > we are planning to update our oak dependencies, from 1.12.0 to 1.50.0 >> > (or maybe 1.52.0). We are aware that we need to use Java 11 (already >> > using it) and update our Mongo servers. It seems it will be to version 6 >> > (not my decision). If I have existing repositories created and filled >> > using 1.12.0, should I do something additional to make them work with >> > the latest version of Oak? >> >> From a DocumentNodeStore perspective, I'm not aware of anything you need >> to do for the update. The MongoDB Java driver is compatible with MongoDB >> 6.0, but please note, our automated tests currently do not exercise this >> combination. I suggest you properly test and report back if you identify >> any issues on MongoDB 6.0. >> >> Regards >> Marcel >> >
