Re: [RT] Configurationless Sling?

[Carsten Ziegeler]

Carsten Ziegeler wrote
> Carsten Ziegeler wrote
>> It seems we moved one step forward with SLING-6772 and introducing a
>> default mapping for service users.
>>
>> However nearly at the same time we made a big step backwards: many of
>> our modules which use a service user now have a dependency (reference)
>> to org.apache.sling.serviceusermapping.ServiceUserMapped in order to
>> avoid that a component starts without the service user being present.
>> Unfortunately this service user is only available if a configuration for
>> that service user exists - but this is not created for the default mapping.
>>
>> Ultimately this means we've moved another big step away from a
>> configurationless Sling - which is really sad.
>>
>> Any ideas how to solve this?
>>
> 
> After an offline discussion with Karl, we came to the conclusion that this
> could be solved with a service hook that registers the ServiceUserMapped on
> demand, based on the default mapping and the requested subname.
> 
> As the service user implementation already registers these hooks anyway,
> this shouldn't be too hard.
> 

While this would work, I just realized that this totally defeats the
purpose of
those service references in the first place: the idea is that a
component only
starts if a service user is available. If we now register the mapping on
demand, this means the reference is satisfied directly and then the
component will start. However, if the installation is not using the
default mapping but a custom one  - which arrives "later" - the
component will fail nevertheless.

Regards
Carsten

 

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: [RT] Configurationless Sling?

[Carsten Ziegeler]

Carsten Ziegeler wrote
> It seems we moved one step forward with SLING-6772 and introducing a
> default mapping for service users.
> 
> However nearly at the same time we made a big step backwards: many of
> our modules which use a service user now have a dependency (reference)
> to org.apache.sling.serviceusermapping.ServiceUserMapped in order to
> avoid that a component starts without the service user being present.
> Unfortunately this service user is only available if a configuration for
> that service user exists - but this is not created for the default mapping.
> 
> Ultimately this means we've moved another big step away from a
> configurationless Sling - which is really sad.
> 
> Any ideas how to solve this?
> 

After an offline discussion with Karl, we came to the conclusion that this
could be solved with a service hook that registers the ServiceUserMapped on
demand, based on the default mapping and the requested subname.

As the service user implementation already registers these hooks anyway,
this shouldn't be too hard.

Carsten

 

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: [RT] Configurationless Sling?

[Carsten Ziegeler]

It seems we moved one step forward with SLING-6772 and introducing a
default mapping for service users.

However nearly at the same time we made a big step backwards: many of
our modules which use a service user now have a dependency (reference)
to org.apache.sling.serviceusermapping.ServiceUserMapped in order to
avoid that a component starts without the service user being present.
Unfortunately this service user is only available if a configuration for
that service user exists - but this is not created for the default mapping.

Ultimately this means we've moved another big step away from a
configurationless Sling - which is really sad.

Any ideas how to solve this?

 Thanks

Carsten

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: [RT] Configurationless Sling?

[Carsten Ziegeler]

Oliver Lietz wrote
> On Wednesday 29 March 2017 08:00:27 Carsten Ziegeler wrote:
>> Oliver Lietz wrote
>>
 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.
>>
>> Well, we decided to not use snapshot dependencies in launchpad anymore.
>> It just has not happened yet. But I think we should start directly after
>> the release of Sling 9. I didn't say we should use Launchpad as the
>> base, I said we should use the same source which probably is a
>> provisioning model. Launchpad's only purpose is to get people easily
>> started with Sling, nothing less but also nothing more.
>>
>>> * There are much more and finer grained features in Karaf than in
>>> Launchpad.
>> I don't want to be pedantic, but these things are not *in* Karaf. The
>> features are defined in Sling and can be consumed by Karaf.
> 
> Sorry, I don't get your point here.
> * in Karaf: /trunk/karaf/org.apache.sling.karaf-features/src/main/feature
>  (around 70)
> * in Launchpad:  /trunk/launchpad/builder/src/main/provisioning
> [feature name=...] (around 10)
> 
> Well, (re)usable features *for* Karaf or Launchpad instead of *in*?

I was just trying to emphasize that the source for this is not in the
Karaf project, it is in *our* svn. But I think I slightly missunderstood
you and as mentioned was too pedantic. :(

> 
>> And I don't
>> see any reason why we can't describe these things with a provisioning
>> model and a) reference it in Launchpad and b) generate a Karaf feature
>> out of it.
>>
>> The only potentially missing feature are dependencies (as you note
>> below). I'll think we should rethink the format of the provisioning
>> model anyway and with that we could add dependency handling. The Karaf
>> feature XML is unfortunately not suited for our needs as it's not
>> possible to add other artifact types and especially not possible to add
>> things like repo init.
> 
> Not sure which artifacts you have in mind, but e.g. Pax Web pulls in its 
> jetty.xml with configfile. That should be possible with repoinit files also.
> And I guess we can evolve the Karaf Feature format as we can evolve the 
> provisioning model when we say what's missing.
> 

I can provide a list of things missing:
- inheritance of features in contrast to dependencies - but maybe that
is possible in Karaf
- framework properties
- other artifacts than bundles, e.g. content packages, sub systems etc.
- additional free form sections for things like repo init or sub system
definitions etc.
- usage of the new JSON format for configurations as defined by R7

>From the top of my head, that's all

Carsten


 

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: [RT] Configurationless Sling?

[Carsten Ziegeler]

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

Re: [RT] Configurationless Sling?

[Oliver Lietz]

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?
Currently we have several bundles using one service user only, e.g. sling-
scripting oder sling-readall.

Regards,
O.

> Carsten
> 
> > Regards
> > Julian
> > 
> > On Mon, Mar 27, 2017 at 4:02 PM, Carsten Ziegeler  
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

Re: [RT] Configurationless Sling?

[Oliver Lietz]

On Wednesday 29 March 2017 08:00:27 Carsten Ziegeler wrote:
> Oliver Lietz wrote
> 
> >> 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.
> 
> Well, we decided to not use snapshot dependencies in launchpad anymore.
> It just has not happened yet. But I think we should start directly after
> the release of Sling 9. I didn't say we should use Launchpad as the
> base, I said we should use the same source which probably is a
> provisioning model. Launchpad's only purpose is to get people easily
> started with Sling, nothing less but also nothing more.
> 
> > * There are much more and finer grained features in Karaf than in
> > Launchpad.
> I don't want to be pedantic, but these things are not *in* Karaf. The
> features are defined in Sling and can be consumed by Karaf.

Sorry, I don't get your point here.
* in Karaf: /trunk/karaf/org.apache.sling.karaf-features/src/main/feature
 (around 70)
* in Launchpad:  /trunk/launchpad/builder/src/main/provisioning
[feature name=...] (around 10)

Well, (re)usable features *for* Karaf or Launchpad instead of *in*?

> And I don't
> see any reason why we can't describe these things with a provisioning
> model and a) reference it in Launchpad and b) generate a Karaf feature
> out of it.
> 
> The only potentially missing feature are dependencies (as you note
> below). I'll think we should rethink the format of the provisioning
> model anyway and with that we could add dependency handling. The Karaf
> feature XML is unfortunately not suited for our needs as it's not
> possible to add other artifact types and especially not possible to add
> things like repo init.

Not sure which artifacts you have in mind, but e.g. Pax Web pulls in its 
jetty.xml with configfile. That should be possible with repoinit files also.
And I guess we can evolve the Karaf Feature format as we can evolve the 
provisioning model when we say what's missing.

Regards,
O.

> Regards
> Carsten
> 
> > * 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-fe
> > atures/src/main/feature/feature.xml#L387
> > 
> > https://github.com/apache/sling/blob/trunk/karaf/org.apache.sling.karaf-co
> > nfigs/src/main/resources/org.apache.sling.jcr.repoinit.impl.RepositoryInit
> > ializer.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-fe
> > atures/src/main/feature/feature.xml#L22
> > 
> > How do you want to create service users without repoinit?
> > 
> > Regards,
> > O.
> > 
> >> Regards
> >> Carsten

Re: [RT] Configurationless Sling?

[Carsten Ziegeler]

Karl Pauls wrote
> On Wed, Mar 29, 2017 at 8:54 AM, Bertrand Delacretaz
>  wrote:
>> On Tue, Mar 28, 2017 at 8:08 PM, Oliver Lietz  wrote:
>>> ...Launchpad is in fact the test bed for AEM...
>>
>> you mean Sling right?
>>
>> Launchpad with snapshots is required currently IMO, to catch
>> integration failures early by building launchpad/testing on snapshots.
> 
> Given my recent struggle with the org.json replacement I'd like to add
> that it would be good if we either try to do a better job in keeping
> the SNAPSHOTS current or have a way to generate a "most recent
> snapshots" launchpad on demand.
> 
That is exactly the idea: stable has no snapshot dependencies at all and
unstable uses SNAPSHOT for all Sling dependencies. And that's automatec

Carsten

> Right now, the launchpad is a mix of stable bundles (that either have
> newer releases or snapshots with changes) and current snapshots. That
> makes it hard to know what configuration passes the integration tests
> and its somewhat painful if you want to see if you broke something
> because if you happen to update a bundle from an old version (possibly
> several) to its latest SNAPSHOT it might cause failing tests
> completely unrelated to your changes (I lost almost half a day due to
> e.g. the servlets post bundle not providing its services due to the
> update to parent 30 which had nothing to do with my commons.json
> changes).
> 
> regards,
> 
> Karl
> 
>> -Bertrand
> 
> 
> 


 

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: [RT] Configurationless Sling?

[Karl Pauls]

On Wed, Mar 29, 2017 at 8:54 AM, Bertrand Delacretaz
 wrote:
> On Tue, Mar 28, 2017 at 8:08 PM, Oliver Lietz  wrote:
>> ...Launchpad is in fact the test bed for AEM...
>
> you mean Sling right?
>
> Launchpad with snapshots is required currently IMO, to catch
> integration failures early by building launchpad/testing on snapshots.

Given my recent struggle with the org.json replacement I'd like to add
that it would be good if we either try to do a better job in keeping
the SNAPSHOTS current or have a way to generate a "most recent
snapshots" launchpad on demand.

Right now, the launchpad is a mix of stable bundles (that either have
newer releases or snapshots with changes) and current snapshots. That
makes it hard to know what configuration passes the integration tests
and its somewhat painful if you want to see if you broke something
because if you happen to update a bundle from an old version (possibly
several) to its latest SNAPSHOT it might cause failing tests
completely unrelated to your changes (I lost almost half a day due to
e.g. the servlets post bundle not providing its services due to the
update to parent 30 which had nothing to do with my commons.json
changes).

regards,

Karl

> -Bertrand



-- 
Karl Pauls
karlpa...@gmail.com

Re: [RT] Configurationless Sling?

[Carsten Ziegeler]

Bertrand Delacretaz wrote
> On Wed, Mar 29, 2017 at 8:00 AM, Carsten Ziegeler  
> wrote:
>> ...we decided to not use snapshot dependencies in launchpad anymore...
> 
> Really? I know my memory is weak for those kinds of things but I don't
> remember that, do you have a link to that decision?
> 
> What I remember is aiming to have two Launchpads, stable (no
> snapshots) and unstable.
> 
Right, that's exactly what I meant :) We have a stable launchpad (no
snapshots) and in addition the unstable one.
The "default" (if you build launchpad) will be the stable one.

Carsten

 

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: [RT] Configurationless Sling?

[Bertrand Delacretaz]

On Tue, Mar 28, 2017 at 8:08 PM, Oliver Lietz  wrote:
> ...Launchpad is in fact the test bed for AEM...

you mean Sling right?

Launchpad with snapshots is required currently IMO, to catch
integration failures early by building launchpad/testing on snapshots.

-Bertrand

Re: [RT] Configurationless Sling?

[Bertrand Delacretaz]

On Wed, Mar 29, 2017 at 8:00 AM, Carsten Ziegeler  wrote:
> ...we decided to not use snapshot dependencies in launchpad anymore...

Really? I know my memory is weak for those kinds of things but I don't
remember that, do you have a link to that decision?

What I remember is aiming to have two Launchpads, stable (no
snapshots) and unstable.

Karaf features can be derived from the former, and testing from the latter.

-Bertrand

Re: [RT] Configurationless Sling?

[Carsten Ziegeler]

Oliver Lietz wrote
>> 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.

Well, we decided to not use snapshot dependencies in launchpad anymore.
It just has not happened yet. But I think we should start directly after
the release of Sling 9. I didn't say we should use Launchpad as the
base, I said we should use the same source which probably is a
provisioning model. Launchpad's only purpose is to get people easily
started with Sling, nothing less but also nothing more.

> 
> * There are much more and finer grained features in Karaf than in Launchpad.

I don't want to be pedantic, but these things are not *in* Karaf. The
features are defined in Sling and can be consumed by Karaf. And I don't
see any reason why we can't describe these things with a provisioning
model and a) reference it in Launchpad and b) generate a Karaf feature
out of it.

The only potentially missing feature are dependencies (as you note
below). I'll think we should rethink the format of the provisioning
model anyway and with that we could add dependency handling. The Karaf
feature XML is unfortunately not suited for our needs as it's not
possible to add other artifact types and especially not possible to add
things like repo init.

Regards
Carsten

> 
> * 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
> 
> 


 

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: [RT] Configurationless Sling?

[Oliver Lietz]

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",\
  

Re: [RT] Configurationless Sling?

[Tommaso Teofili]

Il giorno mar 28 mar 2017 alle ore 15:13 Bertrand Delacretaz <
bdelacre...@apache.org> ha scritto:

> On Tue, Mar 28, 2017 at 3:01 PM, Carsten Ziegeler 
> wrote:
> > Julian Sedding wrote
> >>... As a convention for service users, would it make sense to use the
> >> bundle-symbolic-name as the user-ID (or principal-name)?...
>
> > ...We could use the bundle
> > symbolic name and the sub service information. That should be enough. We
> > don't need the class name
>
> +1 and we might prefix this with bundle_ or b_ to make it clear where
> these usernames come from?
>
> I suppose in the vast majority of cases there's one service user per
> bundle, so that would remove a lot of boring configurations.
>

+1

Tommaso


>
> -Bertrand
>

Re: [RT] Configurationless Sling?

[Bertrand Delacretaz]

On Tue, Mar 28, 2017 at 3:01 PM, Carsten Ziegeler  wrote:
> Julian Sedding wrote
>>... As a convention for service users, would it make sense to use the
>> bundle-symbolic-name as the user-ID (or principal-name)?...

> ...We could use the bundle
> symbolic name and the sub service information. That should be enough. We
> don't need the class name

+1 and we might prefix this with bundle_ or b_ to make it clear where
these usernames come from?

I suppose in the vast majority of cases there's one service user per
bundle, so that would remove a lot of boring configurations.

-Bertrand

Re: [RT] Configurationless Sling?

[Carsten Ziegeler]

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.

Carsten

> 
> Regards
> Julian
> 
> 
> On Mon, Mar 27, 2017 at 4:02 PM, Carsten Ziegeler  
> 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
> 


 

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: [RT] Configurationless Sling?

[Carsten Ziegeler]

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

Re: [RT] Configurationless Sling?

[Oliver Lietz]

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

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

Those repoinit statements and configurations are used by Testing PaxExam also, 
e.g. Option slingExtensionI18n() will provision all required bundles and 
configurations and in the near future also all repoinit statements.

Regards,
O.

> But maybe there is a better option?
> 
> Regards
> Carsten

Re: [RT] Configurationless Sling?

[Julian Sedding]

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  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

[RT] Configurationless Sling?

[Carsten Ziegeler]

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