On Tuesday 28 March 2017 14:59:04 Carsten Ziegeler wrote: > 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-co > > nfigs/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-re > > poinit/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.
Right, but I'm pretty sure I raised my concerns generating Karaf Features and Configurations (and repoinit statements) from provisioning model already. * Launchpad is _unstable_ most of the time (using snapshots mostly) while Karaf Features are _stable_ (only a few snapshots left). Launchpad is in fact the test bed for AEM, but Sling Karaf aims at good user experience and production readiness. * There are much more and finer grained features in Karaf than in Launchpad. * Every (Karaf) feature is backed by an integration test. * Testing PaxExam's options and versions are already generated from (Karaf) features. * The provisioning model does not support dependencies (yet). I guess it takes only a few hours to create templates for generating provisioning models from (Karaf) features and a few more to split into separate files, but I'm more interested in filling the missing piece regarding repoinit (and creating immutable/static instances from features with Karaf Profiles). Currently all repoinit statements from karaf-repoinit are executed when installing feature sling-oak-tar: https://github.com/apache/sling/blob/trunk/karaf/org.apache.sling.karaf-features/src/main/feature/feature.xml#L387 https://github.com/apache/sling/blob/trunk/karaf/org.apache.sling.karaf-configs/src/main/resources/org.apache.sling.jcr.repoinit.impl.RepositoryInitializer.config references=[\ "raw:classpath://org.apache.sling.karaf-repoinit/sling.txt",\ "raw:classpath://org.apache.sling.karaf-repoinit/sling-discovery.txt",\ "raw:classpath://org.apache.sling.karaf-repoinit/sling-event.txt",\ "raw:classpath://org.apache.sling.karaf-repoinit/sling-i18n.txt",\ "raw:classpath://org.apache.sling.karaf-repoinit/sling-installer-jcr.txt",\ "raw:classpath://org.apache.sling.karaf-repoinit/sling-scripting.txt",\ "raw:classpath://org.apache.sling.karaf-repoinit/sling-validation.txt",\ "raw:classpath://org.apache.sling.karaf-repoinit/sling-xss.txt"\ ] It's obvious that having a (factory) component or other mechanism which is able to execute statements in more than one batch makes sense. > 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. The minimal set in Karaf is the feature sling: https://github.com/apache/sling/blob/trunk/karaf/org.apache.sling.karaf-features/src/main/feature/feature.xml#L22 How do you want to create service users without repoinit? Regards, O. > Regards > Carsten
