Oliver Lietz wrote > On Tuesday 28 March 2017 15:01:47 Carsten Ziegeler wrote: >> Julian Sedding wrote >> >>> Hi Carsten >>> >>> I fully agree with the intention of your email. >>> >>> As a convention for service users, would it make sense to use the >>> bundle-symbolic-name as the user-ID (or principal-name)? If we can >>> detect the class name of the service that's creating the >>> Session/ResourceResolver, we could even use the fully qualified >>> classname. Not sure that there is a way other than inspecting the call >>> stack, however. >> >> Yes, I guess that is maybe somehow doable. We could use the bundle >> symbolic name and the sub service information. That should be enough. We >> don't need the class name. It's very unlikely that users with that name >> exist out of the box. That would free us from most of the mapping >> configurations. >> >> What do others think? >> >>> IIUC the service user mapping is only one part of the story. The other >>> part are the permissions required by a service user. I suppose >>> permissions are also a kind of configuration? So how would we go about >>> having a working default permission setup? Without that, a convention >>> for service users becomes kind of pointless. Or am I missing >>> something? >> >> Yes, we need the repoinit stuff for this, actually we need repoinit for >> two things: setting up a user (we shouldn't do this automatically) and >> setting up the ACLs. > > Having a service user per bundle shifts away the amount of configuration from > service user mapping to repoinit only, right?
That would only be the default configuration, you can still deploy the current configurations mapping several bundles to the same service user. And - and that's my use case - think about running Sling without JCR, in that case repoinit is not needed anyway. Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
