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]
