I just found out about ResourceResolver.getThreadResourceResolver (https://issues.apache.org/jira/browse/SLING-3868 <https://issues.apache.org/jira/browse/SLING-3868>). Although this might speed up things, I am not sure on when to use this. I basically share Jörgs concerns from http://mail-archives.apache.org/mod_mbox/sling-users/201506.mbox/%3ccamzpi1o0qlkrkbxcvz0xpdix7wuh+tappkpa2xnqf7rgcl2...@mail.gmail.com%3E <http://mail-archives.apache.org/mod_mbox/sling-users/201506.mbox/%3ccamzpi1o0qlkrkbxcvz0xpdix7wuh+tappkpa2xnqf7rgcl2...@mail.gmail.com%3E>. Also a quick search for getThreadResourceResolver proved that nobody is using that within the Sling Codebase (https://github.com/apache/sling/search?utf8=%E2%9C%93&q=getThreadResourceResolver&type=Code <https://github.com/apache/sling/search?utf8=%E2%9C%93&q=getThreadResourceResolver&type=Code>). What is the idea behind that concept? Under which circumstances does a client not care about which resource resolver is returned (with which permissions)? It would be much more useful if that resource resolver would always be bound to the user’s account which triggered the request (and null if no request is behind the current thread).
> Hi Carsten, > thanks a lot for your answer. There is one question remaining though: > Given that you don’t want to pass the resource resolver from the client, > under which circumstances would you pick which one from the following two > approaches: > > a) Create a resource resolver in the activate method and release in the > deactivate (and live with the drawback that concurrent read access is then > synchronised and the session is open for a very long time, > https://issues.apache.org/jira/browse/OAK-2045 > <https://issues.apache.org/jira/browse/OAK-2045>). I have seen this pattern a > lot in the past. > b) Create the resource resolver on demand for each call. > > How big is the overhead to create new resolvers on demand? > At least in Jackrabbit 2 there is the drawback that those aren’t GCed quickly > enough due to their finalizers > (https://issues.apache.org/jira/browse/JCR-2768 > <https://issues.apache.org/jira/browse/JCR-2768>) > What about Oak? How big is the overhead there? > Thanks for your input > Konrad > > >> On 24 Jul 2015, at 08:06, Carsten Ziegeler <[email protected]> wrote: >> >> Am 23.07.15 um 18:19 schrieb Konrad Windszus: >>> For Sling Validation I just came across the issue that I need a resource >>> resolver in the implementation (e.g. for triggering a search to find the >>> validation models in the repository or to figure out the resource super >>> type). >>> Currently the API is designed that no resolver is passed when any service >>> method is called >>> (https://github.com/apache/sling/blob/trunk/bundles/extensions/validation/api/src/main/java/org/apache/sling/validation/ValidationService.java >>> >>> <https://github.com/apache/sling/blob/trunk/bundles/extensions/validation/api/src/main/java/org/apache/sling/validation/ValidationService.java>) >>> In theory there could also be validation model providers, which are not >>> using the resource resolver (maybe based on files or an OSGi >>> configuration). Therefore initially it seemed reasonable to not pass any >>> resolvers into the API calls. >>> >>> But now I am not so sure, because for the implementation I would need to >>> rely either on the admin resource resolver (which is considered bad >>> practice from a security point of view) or some service resource resolver >>> (which need to be configured). Also creating new resource resolver comes >>> with a price (therefore it is often done in the activate, which is not good >>> practice either) >>> What is you general opinion on the API design of an OSGi service, which may >>> need a resource resolver for some implementations: >>> Should those API methods always get a resource resolver (if at least one >>> implementation may use that) or should the implementation get the resource >>> resolver then on its own (through a service)? >>> >> I guess this depends :) I would go with something along these lines: >> >> If the operation must be done with the permissions of the client of your >> API, you have to pass the resource resolver as part of the api. >> If the operation could be done with the permissions of the client of >> your API, you should pass the resource resolver. >> >> In the other cases, definitely avoid login administrative and also long >> running session, and be aware that a session is not thread safe, and >> using a shared session for reading comes with a performance penalty. >> >> Getting a session is not that cheap, therefore getting a session for a >> service user within the implementation for each and every call of your >> API does not look like a good idea either. I guess here you need to make >> the trade off between a nice to use API, performance and security setup. >> If your api is called often, you might want to put the burden on the >> client to create the service user. However this might bloat the service >> user configurations. >> If it's called rarely, creating a service user within the implementation >> shouldn't be a problem. >> >> Carsten >> -- >> Carsten Ziegeler >> Adobe Research Switzerland >> [email protected] >
