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]
