sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Lietz <>
Subject Re: [RT] Configurationless Sling?
Date Tue, 28 Mar 2017 18:08:07 GMT
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):
> > 
> >
> > 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.
> > 
> >
> > 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) 

* 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 

Currently all repoinit statements from karaf-repoinit are executed when 
installing feature sling-oak-tar:


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:

How do you want to create service users without repoinit?


> Regards
> Carsten

View raw message