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
