Oliver Lietz wrote > On Monday 27 March 2017 16:02:50 Carsten Ziegeler wrote: >> Hi, > > 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. > > we already have artifacts for all repoinit statements (bundle) and > configurations. > > I had to externalize all configurations for Karaf as features only support > the > simple cfg format inline (but Sling and Oak require newer Config Admin > format): > > https://github.com/apache/sling/tree/trunk/karaf/org.apache.sling.karaf-configs/src/main/resources
Interesting. Now, I know we have talked about it and no one had time for this so far, but that should really be described through a provisioning model and then we generate the karaf feature or whatever is needed out of it. > > That said, Sling is one half only. The other half is Oak. > > Configurations are part of a feature which get installed together with its > bundles (and features) when using Sling's Karaf features. > > The missing piece for repoinit (to make statements part of a feature) is a > component which can be feed with "fragments" - similar to what we have for > service user mappings and "login administrative" white listings (it's on my > TODO). Currently all repoinit statements are executed when installing a sling- > launchpad-oak-* feature. > > https://github.com/apache/sling/tree/trunk/karaf/org.apache.sling.karaf-repoinit/src/main/resources > I'm not quiet sure how this work in practice, How do these get installed at runtime in a Karaf environment. Now, basically this is a similar idea to what I had. We describe this stuff as a separate artifact (or more than one) and somehow it gets installed. It would be good if we have this description only once in our code base and not several times and can then generate different artifacts (if needed) out of it. I think we should also split this up into a minimal set. For example I'm currently trying to get Sling running without JCR - in order to trim the dependencies down. And in that case I only need the service user mapping for some core bundles, no repo init etc. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
