Hi Marius, AFAICS, what you describe below is exactly my @ServiceUser annotation, just different names and a different syntax for the ACLs :)
Cheers, Alex On 08.12.2015, at 08:09, Marius Petria <[email protected]> wrote: > I do not have a precise use case right now other than obtaining a “content > access contract” that can be used by tools. Basically, I just wanted to > emphasize that service requirements in code and install instructions in the > provisioning model are two sides of the same coin and we might need both. > > Alexander Klimetschek’s ServiceUser annotation is something close to what I > call service requirements but it goes too concrete by embedding ACL commands > like (allow /content/dam jcr:read) and by looking to define service users > rather than services. A similar annotation @ServiceRequirement could be used > for expressing requirements. > > @ServiceRequirement(permissions = { "/content/mystuff jcr:read”}) > private static final String SERVICE_NAME = “my-service"; > Session session = repository.loginService(SERVICE_NAME, null); > > Then something like the permissionChecker can be called at activate time, or > just in webconsole when listing the service user mappings. These annotations > can be also used to auto generate service users and ACLs but that should not > be automatically installed (except for testing) as the actual users and ACLs > should be installed explicitly by the provisioning model. > > Now, imagine I have a bundle that is annotated with @ServiceRequirements then > I can just install it in two ways: > - for testing, I install it with a flag autoGenerateServiceUser=true. This > will eliminate the need of defining any additional service user installation > in a provisioning model just for that test and the bundle is standalone. > - for production, I install with autoGenerateServiceUser=false and maybe > validateServiceUser=true which will validate against the actual mapping and > repository. > I am not sure how these switches will be specified though this is just a high > level wish :). > > > > Marius >
