You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Konrad Windszus <ko...@gmx.de> on 2015/07/23 17:19:38 UTC
Resource Resolvers in OSGi Service APIs
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)?
Thanks for your input on that
Konrad
Fwd: Resource Resolvers in OSGi Service APIs
Posted by Konrad Windszus <ko...@gmx.de>.
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+tapPKPa2xnQF7rgcL2SQw@mail.gmail.com%3E <http://mail-archives.apache.org/mod_mbox/sling-users/201506.mbox/%3CCAMZpi1O0QLKrkbxCVz0xPDix7Wuh+tapPKPa2xnQF7rgcL2SQw@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 <cz...@apache.org> 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
>> cziegeler@apache.org
>
Re: Resource Resolvers in OSGi Service APIs
Posted by Carsten Ziegeler <cz...@apache.org>.
Am 24.07.15 um 09:08 schrieb Konrad Windszus:
> 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?
I would always go for b), it's the cleaner solution, in the end sync'ing
can be more painful than the cost of creating a session. And with long
running sessions , you need to refresh them etc.
For your other question about the thread context resource resolver: that
one allows access to the current user RR. It does not give access to an
admin or service RR. The reason behind it is, that there are some cases
where an implementation needs to run within the user contexts however
the layers / apis between that code and the code in Sling which has the
RR is not transporting the RR down.
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Resource Resolvers in OSGi Service APIs
Posted by Konrad Windszus <ko...@gmx.de>.
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 <cz...@apache.org> 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
> cziegeler@apache.org
Re: Resource Resolvers in OSGi Service APIs
Posted by Carsten Ziegeler <cz...@apache.org>.
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
cziegeler@apache.org