Thanks for the link, Robert! did use getItemOrNull too for getParent in https://issues.apache.org/jira/browse/SLING-8761 (https://github.com/apache/sling-org-apache-sling-jcr-resource/pull/5)
tell me what you think Le mer. 2 oct. 2019 à 22:51, Robert Munteanu <[email protected]> a écrit : > On Wed, 2019-10-02 at 18:47 +0200, Nicolas Peltier wrote: > > I would love this! i'm sure that ca config is not the only one to use > > getParent() and its null return value though, and wonder if it is > > "ok" to > > mask that potential AccessDeniedException to the developer that will > > make > > use of it without knowledge of its cost. > > What I was speaking of is > > https://github.com/apache/sling-org-apache-sling-jcr-resource/commit/f03954d > . Not sure if it applies to your scenario, probably. If you can see a > way we can optimise this kind of access, I'd love to hear about it. > > Thanks, > Robert > > > > > Le mar. 1 oct. 2019 à 16:06, Robert Munteanu <[email protected]> a > > écrit : > > > > > Hi, > > > > > > On Fri, 2019-09-27 at 17:47 +0200, Nicolas Peltier wrote: > > > > Hey > > > > > > > > realized on applications using caconfig that if you had read > > > > right > > > > only on > > > > /conf/<child>, and not on /conf, each (unsucessfull) lookup ended > > > > up > > > > in a > > > > quiet AccessDeniedException at jackrabbit level, ending up in a > > > > null > > > > return > > > > value. > > > > It "works", but still under performs (exceptions are expensive at > > > > that > > > > intensity). I think that in our context, we can set read rights > > > > on > > > > /conf, > > > > but i wonder if we shouldn't have "conf roots" for ca configs, or > > > > "root > > > > depth" whose lookup is done before reaching JCR. > > > > wdyt? > > > > > > I seem to recall that at some point we had a way of accessing > > > resources > > > without getting exceptions, just null back in case of problems. I > > > don't > > > recall the specifics, but maybe this API can be used for the > > > caconfig > > > as well? > > > > > > Thanks, > > > Robert > > > > > > > >
