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. 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? Regards Julian On Mon, Mar 27, 2017 at 4:02 PM, Carsten Ziegeler <cziege...@apache.org> wrote: > Hi, > > for a long time we have tried to use sensible defaults for all of our > configurations. This allows our users to run a default Sling without any > additional configuration (it should even be possible to run it without a > Configuration Admin service available - but that's another story). > > While we were pretty successful with this, we simply blew it with the > move from login administrative to service users. A lot of the (core) > modules now use service users and these require a configured mapping in > order to work properly. While for example the servlets resolver > previously did not require any configuration, it requires at least the > mapping. Which in turn means you can't simply use that module as-is. > > Switching to service users is of course a good idea but I'm wondering if > we can find a way to get back to a configurationless Sling again? > > Clearly we don't want to the mapping to be part of the bundles using the > service users. > > One possible solution would be an out of the box bundle with the > necessary repo init and configurations. This would cover the core > bundles like servlets resolver and resource resolver. > > But maybe there is a better option? > > Regards > Carsten > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org
