Re: Multi-version support in bundles installer - experimental?

[Dominik Süß]

I don't mind - yet just to clarify: This feature doesn't add scenarios that
couldn't arise before as clarified in the docs.
Apache Felix supports (and since quite a long time supported) having
multiple versions of bundles installed - we just didn't provide install
options (beyond feature launcher or custom code) that would install it that
way.
The "new" behavior is eliminating a lot of the upgrade and state handling
magic we had before that did break before and could corrupt installer
states quite easily.

The most prominent always repeated case of concurrent packages did always
exist as the BSN doesn't have anything to do with the packages that are
exported - different versions of bundles may export different packages and
different bundles may export the same packages. Therefore this feature
doesn't open a new problem space yet it makes it more likely to hit you
early in the face were those issues were often missed in first place in the
past and led to unexpected behavior.

Cheers
Dominik

On Wed, Mar 18, 2020 at 9:12 PM Georg Henzler  wrote:

> +1 for adding „experimental“ to the property name
>
> (I‘m both excited about future possibilities and worried about
> consequences when lightheartedly being turning on)
>
> -Georg
>
> >
> > On 18. Mar 2020, at 16:35, Bertrand Delacretaz 
> wrote:
> >
> > Hi,
> >
> > There was a discussion about this in
> > https://issues.apache.org/jira/browse/SLING-9172
> >
> > For now I have marked this feature as being experimental at
> >
> https://sling.apache.org/documentation/bundles/osgi-installer.html#multi-version-support
> >
> > Carsten rightly notes that if we consider it experimental we might
> > want to rename to service property that activates it to
> >
> >  sling.installer.experimental.multiversion=true
> >
> > Is anyone opposed to adding that "experimental" qualifier in the
> property name?
> >
> > This helps avoid people using it without being aware of its status.
> >
> > -Bertrand
>

Re: [VOTE] Accept the donation of the Sling Packager tool, SLING-8584

[Dominik Süß]

Hi all ,

Being a fresh committee to Jackrabbit I certainly can’t speak for the rest
but historically we seperated out as much as possible concerning the http
communication.

Toby being the main developer behind vault also spent a significant time to
decouple the whole ‚frontend‘ & communication part from packagemanager &
the vault plugin when contributing.

Also the release scheme and cross dependencies wouldn’t be a good fit -
Sling is IMVHO the right home for this and if the contribution comes with
the commitment to maintain I see no real reasons to reject it.
Contributions in contrib are anyhow rather like in the incubator and time
will tell if it’s a useful tool with interest beyond the contributor or not.

Cheers
Dominik

Robert Munteanu  schrieb am Di. 27. Aug. 2019 um 17:00:

> Hi Konrad,
>
> On Tue, 2019-08-27 at 14:55 +0200, Konrad Windszus wrote:
> > For me the situation looks a bit slightly different: I raised a
> > concern in
> >
> https://lists.apache.org/thread.html/7699b02a090d0397d661721f47a6d70b72fb83ff372fafb7d45e6f5e@%3Cdev.sling.apache.org%3E
> >   > 0b72fb83ff372fafb7d45e6f5e@%3Cdev.sling.apache.org%3E> and Ruben
> > answered and I unfortunately never really followed-up on that one.
> > Still for me we haven't really reached consensus back then. I was
> > rather a bit surprised that Robert started the VOTE without
> > commenting on the mailing list thread first.
>
> I did not intend to move this quicker than people expected. I thought
> that the discussion settled down and there were no objections.
>
> The way I view this is that we cannot direct a contribution to another
> project. The contributors have received feedback that another project
> may be better suited, and decided to submit it to Sling nonetheless.
>
> Right now, as a project, we may either accept or reject the
> contribution. If we reject it, it is their choice on whether to go to
> Jackrabbit or not.
>
> My personal opinion is that there are arguments for both Sling and
> Jackrabbit hosting the contribution, but turning it down is not a good
> start :-) We have experience in migrating modules cross projects, so if
> it comes to that we should be well equipped for it.
>
> Thanks,
>
> Robert
>
>

Re: [Feature Analyser] Usage scenario gap

[Dominik Süß]

Sounds good to me - would you suggest to make this a default behavior of
the analyser or making this an explicit external extension?
Depending on this I'd either add that to the whiteboard or a PR to the
existing analyser artifact.

Cheers
Dominik

On Thu, May 16, 2019 at 10:55 AM Karl Pauls  wrote:

> You don't need a standalone CLI nor add the analyser capabilites to
> the feature launcher. You should be able to create a launcher
> extension that you can hook into the launcher to act as an analyser. I
> added that possibility in SLING-8386.
>
> In sort, you use the feature launcher and provide a
> org.apache.sling.feature.launcher.spi.Launcher via the ServiceLoader.
> That should in turn be able to run the analyser with the assembled
> feature.
>
> regards,
>
> Karl
>
> On Thu, May 16, 2019 at 10:44 AM Dominik Süß 
> wrote:
> >
> > Hi Carsten, hi David,
> >
> > basically, there are 2 scenarios (where I currently primarily focus on
> > scenario 1)
> > 1)  we have a set of base features developed by one party and have
> another
> > party developing a "customer" feature that is running on top of base
> > feature.  Both features have their own lifecycle and may change
> > independently - the customer feature may be rebuilt (and effectively is)
> > each time that the base feature is updated. At this point of time, I need
> > to validate that changes of the base feature work together with the
> > customer feature(s). As I am rebuilding the customer feature I would have
> > the "option" to run it in the maven build process but effectively we want
> > to validate two versions of ready built features before we start up the
> > instance. Running via maven would by the setup we have where the customer
> > feature is rebuilt via maven anyhow just a potential fallback if easier
> to
> > solve)
> > 2) a consuming feature should probably be validated against updating
> > baseline features when being developed - this scenario is solved
> > differently for our product and there is no direct access to the invidual
> > features at build time - so it is rather a theoretical scenarios where at
> > least we currently don't have an active usecase that wouldn't be covered
> by
> > scenario 1
> >
> > I hope this makes it a bit clearer.
> > Can you clarify why you prefer to have a standalone CLI tool over adding
> > analyser capabilities to the feature launcher. Key for my question is the
> > necessary duplication of binaries? Or maybe the launcher could be used as
> > the sidecar for the analyser jar to make sure all the libaries are on the
> > class path - WDYT?
> >
> > Cheers
> > Dominik
> >
> > On Thu, May 16, 2019 at 8:57 AM David Bosschaert <
> david.bosscha...@gmail.com>
> > wrote:
> >
> > > I can also see the benefit of running the Analyser outside of a Maven
> > > context, which can be especially useful if you are in an environment
> where
> > > you don't have a Maven cache around. E.g. in a Docker environment.
> Running
> > > Maven in such a context can be very time and network consuming as the
> Maven
> > > cache needs to be built up from scratch, which is really not great if
> all
> > > you want to do is run the Analyser.
> > >
> > > I also think that making it part of the launcher unnecessarily couples
> > > these two. I can see many use cases where they should be run at
> separate
> > > times. If someone wants to run them together it would be as simple as
> > > calling them in sequence or putting them together in a shell script.
> So I
> > > would think option b is the cleanest here too.
> > >
> > > Cheers,
> > >
> > > David
> > >
> > > On Thu, 16 May 2019 at 07:39, Carsten Ziegeler 
> > > wrote:
> > >
> > > > My tendency is towards option b) - keeping things separate and
> allowing
> > > > to develop/release them separately.
> > > >
> > > >  From your options I'm not sure what exactly your use case is as
> they go
> > > > in all possible directions :) But in many use cases you want to
> validate
> > > > as early as possible - and the launcher is the last resort. I can
> > > > totally see use cases where you want to validate features
> independent of
> > > > a maven project and independent from launching, that's why I think we
> > > > should have that as a separate cli.
> > > >
> > > > That was the initial idea of the Main class; we just removed it
> because
> &g

Re: [Feature Analyser] Usage scenario gap

[Dominik Süß]

I just noticed that I missed to add details why using the maven build
failed for me - at this build time I only have the cachefolder available as
"local repository" - the way that the repository goal produces this cache
folder doesn't generate/download the pom.xml files for the artifacts. I
first was trying to use install:install-file to make the external feature
addressable which did work, but the analyzer subsequently fails as when
running in the maven context the analyzer only supports reading artifacts
via maven.

So this opens another option to solve the problem, which is adding support
for a local cache folder "bypassing" the maven lookup (e.g. configuring a
local cache folder would bypass maven lookup).

Cheers
Dominik

On Thu, May 16, 2019 at 10:34 AM Dominik Süß 
wrote:

> Hi Carsten, hi David,
>
> basically, there are 2 scenarios (where I currently primarily focus on
> scenario 1)
> 1)  we have a set of base features developed by one party and have another
> party developing a "customer" feature that is running on top of base
> feature.  Both features have their own lifecycle and may change
> independently - the customer feature may be rebuilt (and effectively is)
> each time that the base feature is updated. At this point of time, I need
> to validate that changes of the base feature work together with the
> customer feature(s). As I am rebuilding the customer feature I would have
> the "option" to run it in the maven build process but effectively we want
> to validate two versions of ready built features before we start up the
> instance. Running via maven would by the setup we have where the customer
> feature is rebuilt via maven anyhow just a potential fallback if easier to
> solve)
> 2) a consuming feature should probably be validated against updating
> baseline features when being developed - this scenario is solved
> differently for our product and there is no direct access to the invidual
> features at build time - so it is rather a theoretical scenarios where at
> least we currently don't have an active usecase that wouldn't be covered by
> scenario 1
>
> I hope this makes it a bit clearer.
> Can you clarify why you prefer to have a standalone CLI tool over adding
> analyser capabilities to the feature launcher. Key for my question is the
> necessary duplication of binaries? Or maybe the launcher could be used as
> the sidecar for the analyser jar to make sure all the libaries are on the
> class path - WDYT?
>
> Cheers
> Dominik
>
> On Thu, May 16, 2019 at 8:57 AM David Bosschaert <
> david.bosscha...@gmail.com> wrote:
>
>> I can also see the benefit of running the Analyser outside of a Maven
>> context, which can be especially useful if you are in an environment where
>> you don't have a Maven cache around. E.g. in a Docker environment. Running
>> Maven in such a context can be very time and network consuming as the
>> Maven
>> cache needs to be built up from scratch, which is really not great if all
>> you want to do is run the Analyser.
>>
>> I also think that making it part of the launcher unnecessarily couples
>> these two. I can see many use cases where they should be run at separate
>> times. If someone wants to run them together it would be as simple as
>> calling them in sequence or putting them together in a shell script. So I
>> would think option b is the cleanest here too.
>>
>> Cheers,
>>
>> David
>>
>> On Thu, 16 May 2019 at 07:39, Carsten Ziegeler 
>> wrote:
>>
>> > My tendency is towards option b) - keeping things separate and allowing
>> > to develop/release them separately.
>> >
>> >  From your options I'm not sure what exactly your use case is as they go
>> > in all possible directions :) But in many use cases you want to validate
>> > as early as possible - and the launcher is the last resort. I can
>> > totally see use cases where you want to validate features independent of
>> > a maven project and independent from launching, that's why I think we
>> > should have that as a separate cli.
>> >
>> > That was the initial idea of the Main class; we just removed it because
>> > no one needed it at that time and it was the quickest fix. We should
>> > also make sure that the Main class is really just parsing the command
>> > line options and has no other logic. Everything else can be delegated to
>> > another class. This makes it easier to embed this logic somewhere else.
>> >
>> >
>> > Regards
>> >
>> > Carsten
>> >
>> >
>> > Dominik Süß wrote
>> > > Hi all,
>> &

Re: [Feature Analyser] Usage scenario gap

[Dominik Süß]

Hi Carsten, hi David,

basically, there are 2 scenarios (where I currently primarily focus on
scenario 1)
1)  we have a set of base features developed by one party and have another
party developing a "customer" feature that is running on top of base
feature.  Both features have their own lifecycle and may change
independently - the customer feature may be rebuilt (and effectively is)
each time that the base feature is updated. At this point of time, I need
to validate that changes of the base feature work together with the
customer feature(s). As I am rebuilding the customer feature I would have
the "option" to run it in the maven build process but effectively we want
to validate two versions of ready built features before we start up the
instance. Running via maven would by the setup we have where the customer
feature is rebuilt via maven anyhow just a potential fallback if easier to
solve)
2) a consuming feature should probably be validated against updating
baseline features when being developed - this scenario is solved
differently for our product and there is no direct access to the invidual
features at build time - so it is rather a theoretical scenarios where at
least we currently don't have an active usecase that wouldn't be covered by
scenario 1

I hope this makes it a bit clearer.
Can you clarify why you prefer to have a standalone CLI tool over adding
analyser capabilities to the feature launcher. Key for my question is the
necessary duplication of binaries? Or maybe the launcher could be used as
the sidecar for the analyser jar to make sure all the libaries are on the
class path - WDYT?

Cheers
Dominik

On Thu, May 16, 2019 at 8:57 AM David Bosschaert 
wrote:

> I can also see the benefit of running the Analyser outside of a Maven
> context, which can be especially useful if you are in an environment where
> you don't have a Maven cache around. E.g. in a Docker environment. Running
> Maven in such a context can be very time and network consuming as the Maven
> cache needs to be built up from scratch, which is really not great if all
> you want to do is run the Analyser.
>
> I also think that making it part of the launcher unnecessarily couples
> these two. I can see many use cases where they should be run at separate
> times. If someone wants to run them together it would be as simple as
> calling them in sequence or putting them together in a shell script. So I
> would think option b is the cleanest here too.
>
> Cheers,
>
> David
>
> On Thu, 16 May 2019 at 07:39, Carsten Ziegeler 
> wrote:
>
> > My tendency is towards option b) - keeping things separate and allowing
> > to develop/release them separately.
> >
> >  From your options I'm not sure what exactly your use case is as they go
> > in all possible directions :) But in many use cases you want to validate
> > as early as possible - and the launcher is the last resort. I can
> > totally see use cases where you want to validate features independent of
> > a maven project and independent from launching, that's why I think we
> > should have that as a separate cli.
> >
> > That was the initial idea of the Main class; we just removed it because
> > no one needed it at that time and it was the quickest fix. We should
> > also make sure that the Main class is really just parsing the command
> > line options and has no other logic. Everything else can be delegated to
> > another class. This makes it easier to embed this logic somewhere else.
> >
> >
> > Regards
> >
> > Carsten
> >
> >
> > Dominik Süß wrote
> > > Hi all,
> > >
> > > https://issues.apache.org/jira/projects/SLING/issues/SLING-8102 led to
> > > removal of the Main class of the feature analyser making it no longer
> > > usable standalone (taking away option b for the scenarios described
> > below)
> > >
> >
> https://github.com/apache/sling-org-apache-sling-feature-analyser/commit/58c986c276531843dd6f63bea31aa38d9884a4a8#diff-3d3e2bf9a1e1b1aa8086b62179fe5154
> > >
> > > Afaict the analyser currently can only run in maven context which
> creates
> > > some trouble where a validation is supposed to run in isolation based
> on
> > > built and released features (checking if given features work
> together). I
> > > initially tried to work around with the maven plugin but the analyser
> > only
> > > can run on the features it builds and won't allow me to refer external
> > > artifacts - copying in the other artifacts in the project also doesn't
> > work
> > > as the check of the maven plugin fails for groupid & artifact id.
> > >
> > > Here are the options I currently see:
> > > a) the

[Feature Analyser] Usage scenario gap

[Dominik Süß]

Hi all,

https://issues.apache.org/jira/projects/SLING/issues/SLING-8102 led to
removal of the Main class of the feature analyser making it no longer
usable standalone (taking away option b for the scenarios described below)
https://github.com/apache/sling-org-apache-sling-feature-analyser/commit/58c986c276531843dd6f63bea31aa38d9884a4a8#diff-3d3e2bf9a1e1b1aa8086b62179fe5154

Afaict the analyser currently can only run in maven context which creates
some trouble where a validation is supposed to run in isolation based on
built and released features (checking if given features work together). I
initially tried to work around with the maven plugin but the analyser only
can run on the features it builds and won't allow me to refer external
artifacts - copying in the other artifacts in the project also doesn't work
as the check of the maven plugin fails for groupid & artifact id.

Here are the options I currently see:
a) the analyse mojo of slingfeature-maven-plugin is improved to be able to
analyse against adhoc merged features and also supports injecting external
artifacts (optimally both maven coordinates or file location) - this would
allow to validate the combination of features intended to be used in the
launcher

b) add a standalone analyser as it was present before - here I could think
of not embedding the features but rather produce a sidecar jar with all the
dependencies that could be set on the classpath for execution, eliminating
the trouble addressed via SLING-8102 in a sligthly different way while
still keeping the option to validate in a pre launcher phase via CLI tool

c) adding validation capabilities to the launcher to be able to run the
analyser tasks via cli through the launcher

My personal tendency is that a & c might both be quite reasonable to have
around (a giving quick roundtrip times during development cycles/build
phase - while c rather matches operational validation where the build of
the features happens decoupled from the final aggregation/combination). b
rather feels like a workaround of c if we don't want to have the analyser
being part of the launcher to keep it as slim as possible.

Btw. I don't suggest to make analysis a mandatory step in the launcher but
at least an option.

WDYT?

Cheers
Dominik

Re: Sling CP 2 FM Converter: multi-package projects

[Dominik Süß]

Hi Andy

I did face a similar challenge and we added the magic ${{filename}}
placeholder which is replacing with the inputfilename (w/o the .zip
extension)
The converter now also takes 1..n packages as input which it processes
after ordering them to be able to extract service users and their ACL setup
into repoinit statements (the ordering by dependency happens to be able to
find/detect the service users before the acls as only those are currently
processed in repoinit - groups and normal users have further challenges
like group memberships and acl inheritance which is why at least acl
processing for those doesn’t match exactly with what repoinit allows.

Anyhow service users are s fundamental precondition for code to act at all
and in contrast to groups are a must have at repository startup - as in
composite nodestorescenarios the content outside of apps smd libs might be
changes ‚later‘ repoinit sounded like the right choice to guarantee this
tho be processed.

I hope this clarifies the latest changes applied by Simo.

Cheers
Dominik


Andreas Schaefer  schrieb am Mi. 8. Mai 2019 um
00:59:

> Hi
>
> I am working on migrating a multi-package project from a traditional Sling
> deployment to a feature model based system. What I want to do is to launch
> the project and Sling together into a full fledge application using the
> converted FM models together with the Sling FM models.
>
> In order to deploy through the Feature Model Launcher the group and the
> artifact need to be the same in all the FM models.
>
> For my Sling conversion which I also will use here to setup Sling I use I
> am going to use an Model ID like this:
>
>
> "${project.groupId}:${project.artifactId}:slingosgifeature:composum_composum-console:${project.version}”
>
> The only fixed part is the component / package name. These models come
> from a provisioning file but should work the same with packages.
>
> Anyhow I cannot use placeholders like '${project.groupId}' as the tool is
> not resolving them and hence fails when checking this as Maven Id.
>
> In addition when using the actual package name the ‘classifier’ is only
> used for the run modes.
>
> I tried to use the ‘-m’ option together with all packages in one call and
> it still does place all packages into their own model file.
>
> Cheers - Andy

Re: Sling Content Package to Feature Model Issue

[Dominik Süß]

Hi Andy,

the behavior you describe supports my hypothesis - as no maven properties
are inlined this falls back to the scenario where the converter extracts
the details on a best-effort basis from the osgi metadata (which might
divert in reality but for the launcher the converter anyways manually
prefills the cache so differences to the "original" GAV are acceptable as
long as the cache is kept as source of truth and not thrown away.

Cheers
Dominik

On Sat, May 4, 2019 at 9:40 PM Andreas Schaefer 
wrote:

> Created a ticket here:
>
> https://issues.apache.org/jira/browse/SLING-8396
>
> I actually have a content package that did not have any not-provided
> bundles in the dependencies and with that the core was added.
>
> - Andy
>
> > On May 4, 2019, at 8:26 AM, Dominik Süß  wrote:
> >
> > Hi Andreas,
> >
> > if looks like you found a bug in there due to the embedded jars:
> > [INFO] Processing bundle core-1.0.0-SNAPSHOT.jar...
> > [INFO] Reading 'core-1.0.0-SNAPSHOT.jar' bundle GAV from
> > META-INF/maven/com.madplanet.sling.cp2sf/core/pom.properties...
> > [INFO] Reading 'core-1.0.0-SNAPSHOT.jar' bundle GAV from
> > META-INF/maven/commons-lang/commons-lang/pom.properties...
> >
> > In fact the referred
> > commons-lang:commons-lang:2.6 bundle in that IS the core bundle as it
> takes
> > the last pom.properties  if found and uses those to install the artifact.
> > Simo already fixed a case where missing pom.properties caused trouble, in
> > this case, I'm not sure how that is supposed to work exactly.
> >
> > Please open a corresponding bug - Simo will most certainly address this
> by
> > Monday as he is far deeper in the maven specifics.
> >
> > Cheers
> > Dominik
> >
> > Andreas Schaefer  schrieb am Fr. 3. Mai 2019
> um
> > 17:38:
> >
> >> Hi
> >>
> >> I have a content package with an embedded Bundle in it (ui.apps ->
> core).
> >> When running the latest Content Package to Feature Model Converter the
> >> bundle is extracted from the package as well as removed from the
> filter.xml
> >> file but it is not added to the feature model json file.
> >>
> >> Here is a demo project for it:
> >> https://github.com/schaefa/sling-content-2-feature-issue
> >>
> >> This is the FM json file:
> >>
> >>
> https://github.com/schaefa/sling-content-2-feature-issue/blob/master/fm.out/ui.apps.json
> >>
> >> When I add the System Console I do not see the bundle. In order to make
> it
> >> install I had to add it to the ui.apps.json file:
> >>
> >>  "bundles":[
> >>{
> >>  "id":"commons-lang:commons-lang:2.6",
> >>  "start-order":"20"
> >>},
> >>{
> >>  "id":"com.madplanet.sling.cp2sf:core:jar:1.0.0-SNAPSHOT",
> >>  "start-order":"20"
> >>},
> >>
> >> Is this done on purpose?
> >>
> >> Cheers - Andy Schaefer
>
>

Re: Sling Content Package to Feature Model Issue

[Dominik Süß]

Hi Andreas,

if looks like you found a bug in there due to the embedded jars:
[INFO] Processing bundle core-1.0.0-SNAPSHOT.jar...
[INFO] Reading 'core-1.0.0-SNAPSHOT.jar' bundle GAV from
META-INF/maven/com.madplanet.sling.cp2sf/core/pom.properties...
[INFO] Reading 'core-1.0.0-SNAPSHOT.jar' bundle GAV from
META-INF/maven/commons-lang/commons-lang/pom.properties...

In fact the referred
commons-lang:commons-lang:2.6 bundle in that IS the core bundle as it takes
the last pom.properties  if found and uses those to install the artifact.
Simo already fixed a case where missing pom.properties caused trouble, in
this case, I'm not sure how that is supposed to work exactly.

Please open a corresponding bug - Simo will most certainly address this by
Monday as he is far deeper in the maven specifics.

Cheers
Dominik

Andreas Schaefer  schrieb am Fr. 3. Mai 2019 um
17:38:

> Hi
>
> I have a content package with an embedded Bundle in it (ui.apps -> core).
> When running the latest Content Package to Feature Model Converter the
> bundle is extracted from the package as well as removed from the filter.xml
> file but it is not added to the feature model json file.
>
> Here is a demo project for it:
> https://github.com/schaefa/sling-content-2-feature-issue
>
> This is the FM json file:
>
> https://github.com/schaefa/sling-content-2-feature-issue/blob/master/fm.out/ui.apps.json
>
> When I add the System Console I do not see the bundle. In order to make it
> install I had to add it to the ui.apps.json file:
>
>   "bundles":[
> {
>   "id":"commons-lang:commons-lang:2.6",
>   "start-order":"20"
> },
> {
>   "id":"com.madplanet.sling.cp2sf:core:jar:1.0.0-SNAPSHOT",
>   "start-order":"20"
> },
>
> Is this done on purpose?
>
> Cheers - Andy Schaefer

Re: Feature Model Deployment Example

[Dominik Süß]

Hi Andreas,

Sling Feature Model "Launcher" is built primarily for building immutable
instances from scratch. The feature model definition itself doesn't mandate
any runtime behavior in particular but is supposed to describe a target
state, so it is up to any implementation to take care of establishing this
target state. If you want to make full use of the feature model and the
existing tooling (checking for coherence etc.) the target state as feature
model would be kept by what ever keeps track of the system state. The
direction we took with feature launcher is to always build it from scratch
and decouple the application and content part (libs + osgi state vs
all other content parts) with the help of composite node store in Oak which
allows to build throw away instances to be used on persisting mutable node
storage.

documentation of the feature model is here:
https://github.com/apache/sling-org-apache-sling-feature/blob/master/readme.md

But I agree the launcher section - refers to the readme of the launcher
which mostly points back to the generic documentation - so it could get
some love.
Some indicator about use can be found in the parseArgs section:
https://github.com/apache/sling-org-apache-sling-feature-launcher/blob/org.apache.sling.feature.launcher-1.0.0/src/main/java/org/apache/sling/feature/launcher/impl/Main.java#L83-L93

HTH
Dominik

On Fri, Apr 5, 2019 at 5:33 PM Andreas Schaefer 
wrote:

> Hi
>
> I am looking into the Sling Feature Model to deploy content packages in a
> custom sling build similar to the sling provisioning.
>
> Is there an example or documentation on:
> - how to deploy a feature module into a running sling instance?
> - how to create a custom sling build with feature models?
>
> Cheers - Andreas Schaefer

Re: [VOTE] Release Apache Sling Feature 1.0.0 and Feature IO 1.0.0

[Dominik Süß]

+1 non binding :)

Cheers
Dominik

On Wed, Jan 30, 2019 at 9:19 AM  wrote:

> Here's my +1
>
> David
>
> On Tue, 29 Jan 2019 at 15:27,  wrote:
>
> > Hi all,
> >
> > I would like to call the 1.0.0 release of the following components:
> >
> > org.apache.sling.feature 1.0.0
> > fixed issues:
> > https://issues.apache.org/jira/projects/SLING/versions/12344550
> >
> > org.apache.sling.feature.io 1.0.0
> > fixed issues:
> > https://issues.apache.org/jira/projects/SLING/versions/12344551
> >
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachesling-2044/
> >
> > You can use this UNIX script to download the release and verify the
> > signatures:
> > http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
> >
> > Usage:
> > sh check_staged_release.sh 2044 /tmp/sling-staging
> >
> > Please vote to approve this release:
> >
> >   [ ] +1 Approve the release
> >   [ ]  0 Don't care
> >   [ ] -1 Don't release, because ...
> >
> > This majority vote is open for at least 72 hours.
> >
> > Best regards,
> >
> > David Bosschaert
> >
> >
> >
>

Re: [feature-model] Removing features after installation

[Dominik Süß]

Hi Karl,
On Mon, Dec 10, 2018 at 3:15 PM Karl Pauls  wrote:

> Yeah, fwiw, that was the underlying idea - there are no restarts
> anymore. I guess we might want to consider emphasising this by making
> it the default to clear the cache on restarts so that you always start
> from a clean state.
>

I don't know if this really is the case. You might want to preprovision the
immutable state and still stop & start without any state change.
This does allow extremely quickly roling out clones of an immutable
instance in a containerized environment.

Cheers
Dominik

Re: Failing with internal release for packageinit

[Dominik Süß]

Yes - is this also generated when you generated when you build the javadoc
via javadoc:jar ?
It somehow isn't for me.

Cheers
Dominik


On Wed, Oct 17, 2018 at 10:48 AM Robert Munteanu  wrote:

> On Mon, 2018-10-15 at 20:06 +0200, Dominik Süß wrote:
> > Hi Robert,
> >
> > I had the feeling that it’s related to dirctly invoking javadoc:jar
> >
> > If you crosscheck the javadoc of your release does it actually
> > contain the
> > license information?
>
> $ jar tf
> target/org.apache.sling.jcr.packageinit-0.0.1-SNAPSHOT-javadoc.jar | grep
> -e LICENSE -e NOTICE
> META-INF/NOTICE
> META-INF/LICENSE
>
> Is this what you were looking for?
>
> Robert
>
>

Re: Failing with internal release for packageinit

[Dominik Süß]

Hi Robert,

I had the feeling that it’s related to dirctly invoking javadoc:jar

If you crosscheck the javadoc of your release does it actually contain the
license information?

Cheers
Dominik

Robert Munteanu  schrieb am Mo. 15. Okt. 2018 um 15:37:

> Hi Dominik,
>
> On Wed, 2018-10-10 at 15:06 +0200, Dominik Süß wrote:
> > Hi everyone,
> >
> > Karl somehow managed to get
> > https://github.com/apache/sling-org-apache-sling-jcr-packageinit/ up
> > and
> > running and added the codebase from whiteboard.
> > But when I tried to create an internal release I failed with
> >
> > [ERROR] Failed to execute goal
> > org.codehaus.mojo:ianal-maven-plugin:1.0-alpha-1:verify-legal-files
> > (verify-legal-files) on project org.apache.sling.jcr.packageinit:
> > Artifact
> > does not contain any legal files:
> > org.apache.sling.jcr.packageinit-0.0.1-T20181010134901-51674eb-
> > javadoc.jar
> >
> > The problem is that the META-INF directory in the javadoc.jar in
> > contrast
> > to the jar and sources.jar doesn't contain
> > the maven-shared-archive-resources (which also contain the LICENSE
> > file).
> >
> > Does anyone have an idea what's going on? I have nothing javadoc
> > specific
> > in and have no clue how to fix this.
>
> I have tried to run
>
>   mvn clean install -Papache-release
>
> which works just fine for me. I have no idea where your problem is
> coming from, sorry.
>
> Robert
>
>

Re: Failing with internal release for packageinit

[Dominik Süß]

Update:
This seems to fail in other locations as well - no clue how this works in
releases but:
mvn clean javadoc:jar source:jar install
org.codehaus.mojo:ianal-maven-plugin:verify-legal-files
on https://github.com/apache/sling-org-apache-sling-installer-core

Leads to the same problem.

Cheers
Dominik

On Wed, Oct 10, 2018 at 3:06 PM Dominik Süß  wrote:

> Hi everyone,
>
> Karl somehow managed to get
> https://github.com/apache/sling-org-apache-sling-jcr-packageinit/ up and
> running and added the codebase from whiteboard.
> But when I tried to create an internal release I failed with
>
> [ERROR] Failed to execute goal
> org.codehaus.mojo:ianal-maven-plugin:1.0-alpha-1:verify-legal-files
> (verify-legal-files) on project org.apache.sling.jcr.packageinit: Artifact
> does not contain any legal files:
> org.apache.sling.jcr.packageinit-0.0.1-T20181010134901-51674eb-javadoc.jar
>
> The problem is that the META-INF directory in the javadoc.jar in contrast
> to the jar and sources.jar doesn't contain
> the maven-shared-archive-resources (which also contain the LICENSE file).
>
> Does anyone have an idea what's going on? I have nothing javadoc specific
> in and have no clue how to fix this.
>
> Cheers
> Dominik
>

Failing with internal release for packageinit

[Dominik Süß]

Hi everyone,

Karl somehow managed to get
https://github.com/apache/sling-org-apache-sling-jcr-packageinit/ up and
running and added the codebase from whiteboard.
But when I tried to create an internal release I failed with

[ERROR] Failed to execute goal
org.codehaus.mojo:ianal-maven-plugin:1.0-alpha-1:verify-legal-files
(verify-legal-files) on project org.apache.sling.jcr.packageinit: Artifact
does not contain any legal files:
org.apache.sling.jcr.packageinit-0.0.1-T20181010134901-51674eb-javadoc.jar

The problem is that the META-INF directory in the javadoc.jar in contrast
to the jar and sources.jar doesn't contain
the maven-shared-archive-resources (which also contain the LICENSE file).

Does anyone have an idea what's going on? I have nothing javadoc specific
in and have no clue how to fix this.

Cheers
Dominik

Re: How to manage repoinit language + implementation evolutions?

[Dominik Süß]

Hi Jörg,

As you can imagine I disagree as users might have used the statement
already to delete service users and depend on that behavior.

Replacing the commands by new variations with refined behavior sounds to me
like a fair compromise. We could even deprecate the old syntax and spawn a
warning that usage of those commands is discouraged due to being not
descriptive enough of their impact.

My 2 cents
Dominik

Jörg Hoh  schrieb am Mi. 3. Okt. 2018 um
13:24:

> Hi,
>
> Am Di., 2. Okt. 2018 um 07:46 Uhr schrieb Karl Pauls  >:
>
> > Can’t we stay BC and just introduce a new command that has the new
> behavior
> > and keep the old one as is?
> >
> > Something like:
> >
> > DELETE REAL USER
> >
> > or similar would be consistent with the service user delete at least.
> >
>
> So you would add some additional commands to the language, which finally do
> what the original version promised to do?
>
> * DELETE USER foo -> removes both real and service users (as today)
> * DELETE SERVICE USER foo -> removes both real and service users (as today)
> * DELETE REAL USER foo -> would delete only a real user?
> * DELETE REAL SERVICE USER foo -> would delete only a service user?
>
> Looks absurd to me. I agree the backward-compatibility is highly important,
> but here it prevents to fix bugs. Also I haven't found any documentation
> which clearly explains the operations in detail, so I had to guess from the
> repoinit examples what the operations are supposed to do. So the current
> implementation does not contradict the documentation or specification
> because there is none. But it contradicts the expectation I got from
> reading the command. If there is a "DELETE USER" and a "DELETE SERVICE
> USER" command, there must be different implementation behind it (otherwise
> there would be only 1 command), and the obvious difference is the the
> "DELETE SERVICE USER" deletes a service user.
>
> I would also assume that any user of repoinit, who started based on the
> existing documentation has the impression as I have and used the commands
> in the same way; but I would question even that, because then this flaw in
> the implementation would have been found much earlier.
>
> So my proposal is to fix the bug, change the implementation in the
> incompatible way (maybe add some log messages for the cases where the old
> implementation would done the wrong thing) and document it properly. And
> that's it.
>
>
> --
> Cheers,
> Jörg Hoh,
>
> http://cqdump.wordpress.com
> Twitter: @joerghoh
>

Re: [hackathon] flagging sling modules as deprecated/contrib

[Dominik Süß]

Hi Jason,

What beyond the ‚engine‘ is actually required?
And even the engine is not required to use some sling bundles.

Sling follows a service oriented architecture thst is very loosely coupled
and expresses minimal depencies. We shouldn’t try to establish wrong
expectations by naming which is why I really don’t like core & controb or
extensions.

The functional aspect is very personal and Sling starter is just one
reasonable combination of modules.

The axis of interest are maintenance commitment (indicating commitment of
active commiters for module - staring as contribution and ending orphaned)
and maturity (experimental, alpha, beta, production ready/ stable ,
deprecated, maybe discontinued)


For maturity:
Experimental ( intended for poc - might be quick & dirty)
Alpha (active development to cover a full productive scenario)
Beta (full coverage for intended use case - feedback cycles might lead to
refactorings of smaller parts)
Stable (versions > 1.0.0 indicating stable semantic versioning and
behavioral stability)
Deprecated (better alternatives around or no longer actively updated to
work optimally with latest platform)
Discontinued (only archival of latest shipped source)

For the maintenance commitment I am personally interested how many active
willing commiters are around: 0, 1, 2-3, 4+) indicating how likely someone
can start to help in case of trouble with module

Cheers
Dominik

Jason E Bailey  schrieb am Mo. 24. Sep. 2018 um 15:13:

> I still feel like we are missing an axis. One that groups the various
> bundles by functionality.
>
> Maybe: Required, Extension, Optional
>
> Required are the minimal bundles you need, Extensions are alternatives or
> specific implementations of Required, and Optional is just that.
>
>
> - Jason
>
> On Tue, Sep 18, 2018, at 9:46 AM, Bertrand Delacretaz wrote:
> > On Tue, Sep 18, 2018 at 3:38 PM Jason E Bailey  wrote:
> > > ...I'll throw "community" and/or "community supported" into the ring
> for consideration as well. For those bundles that aren't supported...
> >
> > I like it, as a way to indicate that the PMC expects the community to
> > take care of those bundles, on a best effort basis, as opposed to the
> > core bundles which the PMC commits to maintaining and keeping in sync
> > with the latest evolutions.
> >
> > That doesn't prevent any community member from working on core bundles
> > of course, again it's just an indication of PMC committment.
> >
> > So we might go for these two axes:
> >
> > Code maturity axis: experimental, alpha, beta, product-ready.
> >
> > PMC committment axis: core, community and whiteboard
> >
> > -Bertrand
>

Re: Sling Hackathon Sept. 13th, 2018 in Berlin

[Dominik Süß]

+1 - will be available as well and happy to contribute esp. in the area of
deployments (feature model & content-deployment improvements I was lately
prototyping/implementing and already partially contributing to JCRVLT)

I guess some of that also relates to the topics Eugen brought up (how to
deploy sling, how to build up application content)

Cheers
Dominik

On Mon, Aug 13, 2018 at 4:59 PM Robert Munteanu  wrote:

> These sound like great additions, would be nice to see you at the
> hackathon.
>
> Robert
>
> On Mon, 2018-08-13 at 12:51 +0300, Eugen Stan wrote:
> > Hi,
> >
> > I'm working on deploying Sling + Karaf in production so I think I
> > will
> > focus on this part:
> >
> > - making it easy to quick-start Sling for production use
> >
> > - some comon strategies on how to work with content
> >
> > - fix some issues around tooling and the process - right now I get a
> > lot
> > of error messages in the logs, some of them should not be there
> >
> > Regards,
> >
> >
> > On 13.08.2018 11:58, Robert Munteanu wrote:
> > > Hi Eugen,
> > >
> > > On Sat, 2018-08-11 at 20:44 +0300, Eugen Stan wrote:
> > > > Hi,
> > > >
> > > > I'm booking my flight and accomodations for Adapt.to and would
> > > > like
> > > > to
> > > > know a shedule for the hackathon so I can plan better.
> > > >
> > > > I have flight options from Berlin Schönefeld @ 18:15 on 13.09 and
> > > > another, next day.
> > > >
> > > > Would love to stay another day if I can find a good reason :).
> > >
> > > The Hackathon agenda is whatever the participants make it to be :-)
> > >
> > > So feel free to join and propose subjects - that simply happens on-
> > > site. I for one don't know yet what I want to hack on, but if you
> > > think
> > > it helps we can set up a wiki page and register participants and
> > > topics
> > > of interested, in a manner similar to [1].
> > >
> > > Robert
> > >
> > > [1]: https://wiki.apache.org/jackrabbit/Oakathon%20March%202018
> > >
> >
> >
>
>
>

Re: SLING-7613 - un-deprecating loginAdministrative

[Dominik Süß]

I understand this position and can emphasize while it may lead to a wrong
sense of security. Even service users require severe attention wrt their
permissions and can be similarly dangerous if they can write code into
executable locations (and expand the attack by being able to potentially
use loginadmin).

I personally still think we should get an option to retrieve a session
and/or resourceResolver where we further constrain  what the user can do in
this particular session - processing malicious data in such a session
couldn’t do harm outside of the case for which the session is built.

Maybe someone with a deeper security aspect background of the oak team can
share about their thoughts of how to deal with those cases best.

Cheers
Dominik

Bertrand Delacretaz  schrieb am Sa. 28. Juli 2018
um 12:06:

> On Sat, Jul 28, 2018 at 10:23 AM Carsten Ziegeler 
> wrote:
> > ...Today you can just look at the
> > code and you know whether admin is used or not...
>
> I share this concern, any mechanism that magically makes something
> admin is dangerous as it can easily be overlooked.
>
> If changes are really needed I think they should keep the current
> "it's obvious what admin is" visibility.
>
> -Bertrand
>

Re: SLING-7613 - un-deprecating loginAdministrative

[Dominik Süß]

+1 - instead of whitelisted calls of the loginadmin call the mapping to
admin could be whitelisted. Btw.the very early versions of servicemapping
did allow to map to any user including admin which was used as temporary
bridge until all the initial hiccups with service users were sorted out (at
least by developers aware of that option - just remember because those
admin mappings had thento be removed to be able to eliminate this option.

Cheers
Dominik

Jörg Hoh  schrieb am Fr. 27. Juli 2018 um
17:17:

> Hi
>
> 2018-07-27 16:41 GMT+02:00 Jason E Bailey :
>
> > I may be off base here since I haven't spent much time with service users
> > but couldn't  this be handled by extending the Service User so that for
> > specific services, the user returned is the literal admin user.
> >
> > i.e. rather then whitelisting the services that can use
> > loginAdministrative the service user that these whitelisted services
> would
> > get would be the Administrator user.
> >
>
> That means, that instead of the service-user you can configure to receive
> the admin-user? I guess, that it won't change much... Instead of creating a
> new service-user lazy people will use the admin. One could argue, that it's
> still to easy to use an admin session. But harmonizing both approaches
> would definitley help, because then a switch from a service-user to an
> admin-user and vice-versa would be just a configuration change, but no code
> change.
>
> Jörg
>
> --
> Cheers,
> Jörg Hoh,
>
> http://cqdump.wordpress.com
> Twitter: @joerghoh
>

Re: Initial prototype of Sling Feature model API Region support

[Dominik Süß]

Hi David,

just having backward compatibility and potential further evolution in mind.
Would it make sense for regions to follow some namespace concept an reserve
a certain namespace. So even if the future brings new scenarios where we
might need new reserved regions we could have some "system" namespace or
so. Additionally it is easier to layer different "owners" on top and
explicitly declare the ownership (e.g. vendor customer scenario where we
would want to check weather customers hook into regions that are supposed
to be internal).

Cheers
Dominik

Cheers
Dominik

On Fri, Jul 13, 2018 at 12:20 PM David Bosschaert <
david.bosscha...@gmail.com> wrote:

> Hi Bertrand,
>
> On Fri, 13 Jul 2018 at 12:08, Bertrand Delacretaz 
> wrote:
>
> > Hi David,
> >
> > On Fri, Jul 13, 2018 at 11:54 AM David Bosschaert
> >  wrote:
> > > ...Yes, 'global' is the magic name for the region available to
> everyone.
> > This
> > > includes bundles that are in different regions or bundles that are in
> no
> > > region at all
> >
> > Ok, so IIUC "global" is the only reserved region name, and other names
> > can be selected freely?
> >
>
> Yep, it's defined as a constant at [2]. All other names can be selected at
> will.
>
>
> > If I'm correct it might be good to mention that at [1], for clarity.
> >
>
> Good point - I've updated [1] for this.
>
> Also (while I'm in nitpicking mode ;-) how about using "API Controller
> > and API Regions" as the title of that document? It speaks more about
> > regions than about the controller itself.
> >
>
> Also good point - I've changed this too (I didn't change the file name as I
> didn't want to break any links).
>
> Best regards,
>
> David
>
>
> > Thanks for this, it looks quite useful!
> >
> > -Bertrand
> >
> > [1]
> >
> https://github.com/apache/sling-org-apache-sling-feature/blob/master/apicontroller.md
>
>
> [2]
>
> https://github.com/apache/sling-whiteboard/blob/master/featuremodel/feature-whitelist/src/main/java/org/apache/sling/feature/whitelist/WhitelistService.java#L24
>

Re: [Sling Feature Model] Expanded requirements

[Dominik Süß]

Hi David,

I would challenge
SFM460 - The feature model should provide an externally accessible API for
reading and writing feature files

The model itself doesn't provide any API nor would it mandate any
implementation detail. I rather see this partially  as refinement of
SFL012 - Tooling must provide a way to add new features to an existing
application.
and it also might be some tooling for remote editing and distribution of
features & application state.

My thought for this was to implement something like a deployment manager
which is a tool to compose and build up new features and queue up for the
next deployment. So instead of dynamically installing bundles & content one
would have a tool (which should be built with API-first in mind) to
a) build up a new feature based on available artifacts (bundles, packages,
configs, repoinit commands)
b) compose an application based on installed application state (features as
deployed in last deployment) and new features
c) queue up an application state for deployment & trigger deployment
(defining the interface to the operational details such as the launcher or
in containerized environments the coordinating system)

The bullet points ahead account for local deployments (in instance
preparation & triggering) - as well as for remote execution where some
coordinating system would be use to centrally coordinate application state
of n instances and distribute the results accordingly.

We should properly split up the modeling (deployment manager) from the
operations details (feature model distribution) so we can plug the
distribution system according to the operational details (local,
distributed topology, multi topology system) while reusing the same
mechanism for adjusting a versionable model (which can distribution wise
map to 1 or n systems).

Cheers
Dominik



On Fri, Mar 16, 2018 at 10:48 AM, David Bosschaert <
david.bosscha...@gmail.com> wrote:

> Hi all,
>
> In the mean time some additional requirements surfaced, which I added in
> [1].
>
> I also updated the feature model format, mostly based on existing
> requirements. It can be found at [2]. Once it's matured we should create a
> JSON Schema for it (or something similar)...
>
> Main additions are:
> * Support for variables
> * Comments can now also be put in the document by using a key that starts
> with a hash '#'. This is because most JSON editors don't support the JSMin
> (/* */ and //) style comments and show these as errors.
> * Some small additions that make it possible to 100% roundtrip between the
> provisioning and the feature model which is especially important during the
> phase where users are migrating.
>
> Best regards,
>
> David
>
> [1]
> https://github.com/apache/sling-whiteboard/commit/
> 2dcab0e45866ce51f732ac525ebf100a82737099
> [2]
> https://github.com/apache/sling-whiteboard/blob/master/
> featuremodel/design/feature-model.json
>

Re: [ANN] New committer: David Bosschaert

[Dominik Süß]

Congratulations! :)

Cheers
Dominik

Chris Millar  schrieb am So. 11. März 2018 um 21:57:

> Welcome! Always love your talks on IoT and containerization! Well deserved!
>
> On Fri, Mar 9, 2018 at 2:36 AM Carsten Ziegeler 
> wrote:
>
> > The Project Management Committee (PMC) for Apache Sling
> > has invited David Bosschaert to become a committer and we are pleased
> > to announce that he has accepted.
> >
> > Please welcome David.
> >
> > David, you might want to introduce yourself.
> >
> > Being a committer enables easier contribution to the
> > project since there is no need to go via the patch
> > submission process. This should enable better productivity.
> > Being a PMC member enables assistance with the management
> > and to guide the direction of the project.
> >
> > Regards
> > Carsten
> > --
> > Carsten Ziegeler
> > Adobe Research Switzerland
> > cziege...@apache.org
> >
>

Problematic condition for OptimizeAliasResolution in upgrade cases

[Dominik Süß]

Hi All,

I am just checking a troublesome behavior of
https://github.com/apache/sling-org-apache-sling-resourceresolver/blob/org.apache.sling.resourceresolver-1.5.36/src/main/java/org/apache/sling/resourceresolver/impl/mapping/MapEntries.java#L193

It turns out that under certain conditions (which we try to eliminate) the
corresponding index isn't available at startup and the query is executed in
a blocking way.

So my question would be:
1. Shouldn't we make filling the alias cache asynchronous?
2. In case we know that a query will be available eventually make the query
wait for index to be complete before firing?

wrt 1 - should be doable but would require some rewrite because
getAliasMap(parentPath) would need to do minitraversals when no entry is
present and search didn't complete yet as the current implementation always
assumes that aliasmap is fully initialized

wrt 2 - oak doesn't provide a corresponding service for completion but
there are ways to work with marker nodes and block with a query - I'd
suggest to make this an external service that this may be waiting for so we
can just replace this to not make resourceResolver being bound to an
implementation detail of the underlying search (while the service we
"might" be waiting for can).

WDYT?

Cheers
Dominik

P.S. a workaround certainly is to disable optimized lookup temporary until
index is there and resourceresolver as soon as available (uglyness that
this requires restart of the RR which has quite some impact).

Re: [Sling Feature Model] Expanded requirements

[Dominik Süß]

Good point - I just had to think of star imports that make it impossible to
declare the dependency vector purely based on the metadata

Cheers
Dominik

Oliver Lietz  schrieb am Mi. 21. Feb. 2018 um 16:07:

> On Tuesday 20 February 2018 16:48:08 David Bosschaert wrote:
> > Hi all,
>
> Hi David,
>
> > Over the recent past some additions have been made to the requirements of
> > the Sling Feature Model. The updated requirements can be found here:
> >
> https://github.com/apache/sling-whiteboard/blob/master/featuremodel/readme.m
> > d
> >
> > Any additional requirements, let us know!
>
> the readme says in section "Requirements and Capabilities of Artifacts":
>
> "The feature model does not allow to explicitly list requirements or
> capabilities for artifacts. An artifact, for example a bundle, contains
> this
> information as part of its metadata."
>
> Some bundles (from Sling and Oak also) do not provide proper metadata and
> it
> would be quite useful to add missing capabilities in the model until the
> artifacts are fixed (if that ever happens).
>
> Regards,
> O.
>
> > I'm hoping to start contributing to the implementation of some of these
> in
> > the near term and was wondering - is there a reason why the feature model
> > still in the sling-whiteboard? Or would it make sense to put it in its
> own
> > Sling git repo or repos?
> >
> > Best regards,
> >
> > David
>
>

Re: [feature model] Format of text section - repoinit and others

[Dominik Süß]

Hi,

I personally think 1 & 2 have their advantages - externalizing rather
complex repoinit setups with dozens of statements might make sense to keep
the feature model overall better readable. So I would personally opt for
both options.

Cheers
Dominik

On Mon, Jan 8, 2018 at 2:11 PM, Carsten Ziegeler 
wrote:

> Hi,
>
> good point, I don't like the second option as I prefer having everything
> in a single file. The third option would introduce a special format per
> extension which then might need special rules/implementation for merging
> two modules or handling inheritance/includes.
>
> Which leaves us with the first option :)
>
> I think parsing this is easy: if it's in array simply concat the values
> and apply newlines in between. In the same way we could write out a text
> value: we split the text by newlines and create an array out of it.
>
> Regards
>
> Carsten
>
>
> Robert Munteanu wrote
> > Hi,
> >
> > While working some more with the feature model I realized that text
> > sections can not contain newlines - this is a limitation of JSON.
> >
> > This makes it very hard to work with repoinit sections. I end up with
> > (literally) 10k characters on a single line. Diffs are going to be
> > interesting with such formats :-)
> >
> > I think it would help adoption a lot if we have a more friendly format
> > for text entries.
> >
> > One option would be to have lines stored as an array, e.g.
> >
> >   "repoinit:TEXT|false": [
> >   "create path (sling:Folder) /libs",
> >   "create path (sling:Folder) /apps",
> >   "create path (sling:Folder) /tmp"
> >   ]
> >
> > Not that nice, but it keeps the file self-contained.
> >
> > Another option would be to keep a secondary text file around and
> > introduce a new field type, file:
> >
> >   "repoinit:FILE": "./repoinit.txt"
> >
> > This has the disadvantage of no longer having the configuration be
> > self-contained, but on the other hand it's a text file, which the
> > repoinit format was built for.
> >
> > The third option - for the sake of being complete - is to have a
> > structured JSON format for repoint, but IMO that's overkill. Something
> > like:
> >
> >   "repoinit": {
> >   "paths": [
> >   "/libs (sling:Folder)",
> >   "/apps (sling:Folder)",
> >   "/tmp (sling:Folder)"
> >   ]
> >}
> >
> > Thoughts? I think the feature model approach is great, but we need to
> > improve on the usability of text sections.
> >
> > Thanks,
> >
> > Robert
> >
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

Re: Contribute Slick?

[Dominik Süß]

Hi Nicolas,

we "could" have Azure quickstart Templates or similar that make it pretty
easy to roll out a predefined sling enviroment (see
https://github.com/Azure/azure-quickstart-templates for tons of existing
examples).

Cheers
Dominik

On Tue, Oct 24, 2017 at 10:55 AM, Nicolas Peltier  wrote:

> Could we have hosting as well? (dreaming out loud)
>
> 2017-10-24 10:50 GMT+02:00 Ioan Eugen Stan :
> > Hi,
> >
> > I second that. What sling needs most is a big community that can create
> > a marketplace like Wordpress has.
> >
> > A place where you can publish plugins and modules that users can install
> > and that work out of the box.
> >
> > Having a comunity and a marketplace is a big step forward for adoption
> > by non-developers.
> >
> > Regards,
> >
> >
> > On 24.10.2017 01:53, Carsten Ziegeler wrote:
> >> I think it would be a great contribution and it's definitely welcome.
> >> Thanks for offering. I would assume that the contribution to Sling might
> >> get you even more feedback and contributors.
> >>
> >> What I personally would love to have, is splitting Slick up into some
> >> modules. For example, your front page to change the admin password could
> >> be of general interest for any Sling based installation. Same is for the
> >> UI to create users. This could be shared between different demos. I
> >> always planned to have something like this for the Slingshot sample, but
> >> never got to it.
> >>
> >> But this is just dreaming and not really required for the contribution
> >> itself.
> >>
> >> Regards
> >>
> >> Carsten
> >>
> >>
> >> Chris Millar wrote
> >>> At AdaptTo, I had a few conversations about contributing Slick [0] to
> >>> Apache Sling. Is this something the community is interested in? If so,
> I'd
> >>> like to start that process. Whether it be part of a contrib project or
> a
> >>> sample project.
> >>>
> >>> There would be things I would like to clean up before hand. Some
> >>> auto-generated try / catches, add unit tests, and get the Sling 9
> version
> >>> thoroughly tested are just a few.
> >>>
> >>> If you have thoughts on this, please share them.
> >>>
> >>> Thanks!
> >>> Chris
> >>>
> >>> [0] https://github.com/auniverseaway/slick-2
> >>>
> >
> >
>

Re: [RT] Updates to the provisioning model

[Dominik Süß]

Hi Carsten,

can you provide some insights on timing wrt Felix Snapshot dependencies.
When we plugged together the demo we still had a few dependencies on
unreleased artifacts for the OSGi R7 work.

I would rather see this change happening yesterday than tomorrow to start
working on how the model can be maintained and operated over time and add
the corresponding missing pieces for this as touched in the presentation
(e.g. Deployment Admin & optimizations of installer and packagetransformer
for Sling). As some of that specifically should work properly hand-in-hand
with the builder and analyzer part I would want to avoid working against a
heavily moving target (assuming that SNAPSHOT is not settled at all).

Cheers
Dominik

On Thu, Oct 5, 2017 at 4:10 PM, Julian Sedding  wrote:

> Hi Bertrand
>
> I suppose it would be
>
> cat provisioning-model | jsmin | jq .
>
> I have not tested this, however.
>
> Regards
> Julian
>
>
> On Thu, Oct 5, 2017 at 3:39 PM, Bertrand Delacretaz
>  wrote:
> > On Thu, Oct 5, 2017 at 11:39 AM, Julian Sedding 
> wrote:
> >> ...lets stick with JSON + comments...
> >
> > Is that format accepted by JSON tools? Can I for example do
> >
> >   cat provisioning-model | jq .
> >
> > ?
> >
> > Otherwise I fear the format combines the worst of both worlds: hard
> > for humans to read and write (JSON) and not directly suitable for
> > machine processing. In which case I suggest rediscussing the comments
> > format/schema to make sure the result is pure JSON - maybe with
> > _comment_ elements that tools can easily ignore.
> >
> > -Bertrand
>

Re: [VOTE][CANCEL] Release Apache Sling Installer Core version 3.8.4

[Dominik Süß]

Konrad,  I just anonymized one of the sequences (of dozens):

*WARN* [OsgiInstallerImpl]
org.apache.sling.installer.core.impl.PersistentResourceList Removing stale
resource
TaskResource(url=launchpad:resources/install/0/content-package-a-1.1.0.zip,
entity=content-package:groupx:packagenamex, state=UNINSTALL,
attributes=[org.apache.sling.installer.api.tasks.ResourceTransformer=:25:22:1170:,
package-id=groupx:packagenamex:1.1.2, sph-option=INSTALL,
Bundle-Version=1.1.2], digest=11), overwritten by
TaskResource(url=launchpad:resources/install/0/content-package-a-1.1.0.zip,
entity=content-package:groupn:content-package-a, state=INSTALL,
attributes=[org.apache.sling.installer.api.tasks.ResourceTransformer=:25:22:1170:,
package-id=groupn:content-package-a:1.1.0, Bundle-Version=1.1.0],
digest=11)
*INFO* [OsgiInstallerImpl] org.apache.sling.audit.osgi.installer
Uninstalled content package
TaskResource(url=launchpad:resources/install/0/content-package-a-1.1.0.zip,
entity=content-package:groupx:packagenamex, state=UNINSTALL,
attributes=[org.apache.sling.installer.api.tasks.ResourceTransformer=:25:22:1170:,
package-id=groupx:packagenamex:1.1.2, sph-option=INSTALL,
Bundle-Version=1.1.2], digest=11)

AFAICT this is a package with one subpackage (groupx:packagenamex)

Cheers
Dominik

On Fri, Feb 17, 2017 at 1:16 PM, Karl Pauls <karlpa...@gmail.com> wrote:

> Yeah, this is not good. I'll herby cancel this release.
>
> I will rollback the commit in question, reopen the original issue, and
> cut a new release candidate without this change for now.
>
> regards,
>
> Karl
>
> On Fri, Feb 17, 2017 at 1:11 PM, Dominik Süß <dominik.su...@gmail.com>
> wrote:
> > @kwin - sorry I cannot add logs as this is confidential information -
> yet I
> > could trace back this to the case where packages contain subpackages
> which
> > within the resource tranformer cause subsequent InstallTasks having the
> > same URL. - This migth be a bug but needs to fixed along for this to be
> > applicable.
> >
> > Cheers
> > Dominik
> >
> > On Fri, Feb 17, 2017 at 1:08 PM, Konrad Windszus <konra...@gmx.de>
> wrote:
> >
> >> Can you provide the logs? The change in SLING-6392 will always log in
> case
> >> it changes something (see https://svn.apache.org/viewvc/
> >> sling/trunk/installer/core/src/main/java/org/apache/
> >> sling/installer/core/impl/PersistentResourceList.java?
> >> r1=1765129=1783196=1783196). So I am wondering which package
> >> is actually detected as stale?
> >> The according log entry should start with "Removing stale resource ..."
> >> Thanks,
> >> Konrad
> >>
> >> > On 17 Feb 2017, at 13:04, Dominik Süß <dominik.su...@gmail.com>
> wrote:
> >> >
> >> > Reverting to -1. Subsequential integration testing on product on top
> of
> >> > this did show that SLING-6392 does fail with content-packages that
> >> > partially end up uninstalled instead of installed.
> >> >
> >> > Reverting SLING-6392 only including SLING-5457 succeeds.
> >> >
> >> > On Fri, Feb 17, 2017 at 1:00 PM, Stefan Seifert <
> sseif...@pro-vision.de>
> >> > wrote:
> >> >
> >> >> +1
> >> >>
> >> >>
> >>
> >>
>
>
>
> --
> Karl Pauls
> karlpa...@gmail.com
>

Re: [VOTE] Release Apache Sling Installer Core version 3.8.4

[Dominik Süß]

@kwin - sorry I cannot add logs as this is confidential information - yet I
could trace back this to the case where packages contain subpackages which
within the resource tranformer cause subsequent InstallTasks having the
same URL. - This migth be a bug but needs to fixed along for this to be
applicable.

Cheers
Dominik

On Fri, Feb 17, 2017 at 1:08 PM, Konrad Windszus <konra...@gmx.de> wrote:

> Can you provide the logs? The change in SLING-6392 will always log in case
> it changes something (see https://svn.apache.org/viewvc/
> sling/trunk/installer/core/src/main/java/org/apache/
> sling/installer/core/impl/PersistentResourceList.java?
> r1=1765129=1783196=1783196). So I am wondering which package
> is actually detected as stale?
> The according log entry should start with "Removing stale resource ..."
> Thanks,
> Konrad
>
> > On 17 Feb 2017, at 13:04, Dominik Süß <dominik.su...@gmail.com> wrote:
> >
> > Reverting to -1. Subsequential integration testing on product on top of
> > this did show that SLING-6392 does fail with content-packages that
> > partially end up uninstalled instead of installed.
> >
> > Reverting SLING-6392 only including SLING-5457 succeeds.
> >
> > On Fri, Feb 17, 2017 at 1:00 PM, Stefan Seifert <sseif...@pro-vision.de>
> > wrote:
> >
> >> +1
> >>
> >>
>
>

Re: [VOTE] Release Apache Sling Installer Core version 3.8.4

[Dominik Süß]

Reverting to -1. Subsequential integration testing on product on top of
this did show that SLING-6392 does fail with content-packages that
partially end up uninstalled instead of installed.

Reverting SLING-6392 only including SLING-5457 succeeds.

On Fri, Feb 17, 2017 at 1:00 PM, Stefan Seifert 
wrote:

> +1
>
>

Re: [VOTE] Release Apache Sling Installer Core version 3.8.4

[Dominik Süß]

FYI - I could reproduce the issue only by deploying the jar via webconsole
and not performing a package refresh. If I either deploy the bundle via the
installer itself or manually trigger refresh packages the installer works
quite fine.

Cheers
Dominik

On Fri, Feb 17, 2017 at 9:59 AM, Dominik Süß <dominik.su...@gmail.com>
wrote:

> Hi Dan,
>
> can you crosscheck if the same happens for a previous version of Sling
> Installer to be deployed (e.g. installing 3.8.2 when an older version was
> deployed before). I can't see any chance that this fix introduces new
> issues into restart behavior of bundle and therefore would opt to move on
> and open a new issue for the found restart condition.
>
> +1 nonbinding
>
> Cheers
> Dominik
>
> On Fri, Feb 17, 2017 at 6:00 AM, Daniel Klco <dk...@apache.org> wrote:
>
>> Hi Karl,
>>
>> I was checking the integration tests and noticed that
>> org.apache.sling.installer.core 3.8.4 cannot be installed into a running
>> Sling instance. Once you restart the instance it's fine, but when you
>> first
>> install the bundle, it causes a number of other bundles to fail. Is this a
>> known problem?
>>
>> Please find logs from Sling & the failed integration tests below:
>>
>> https://gist.github.com/klcodanr/4984b27cb54719ce069d6347b4298647
>>
>> Thanks,
>> Dan
>>
>> On Thu, Feb 16, 2017 at 10:27 AM, Robert Munteanu <romb...@apache.org>
>> wrote:
>>
>> > On Thu, 2017-02-16 at 16:21 +0100, Karl Pauls wrote:
>> > > Please vote to approve this release:
>> >
>> > +1
>> >
>> > Robert
>>
>
>

Re: [VOTE] Release Apache Sling Installer Core version 3.8.4

[Dominik Süß]

Hi Dan,

can you crosscheck if the same happens for a previous version of Sling
Installer to be deployed (e.g. installing 3.8.2 when an older version was
deployed before). I can't see any chance that this fix introduces new
issues into restart behavior of bundle and therefore would opt to move on
and open a new issue for the found restart condition.

+1 nonbinding

Cheers
Dominik

On Fri, Feb 17, 2017 at 6:00 AM, Daniel Klco  wrote:

> Hi Karl,
>
> I was checking the integration tests and noticed that
> org.apache.sling.installer.core 3.8.4 cannot be installed into a running
> Sling instance. Once you restart the instance it's fine, but when you first
> install the bundle, it causes a number of other bundles to fail. Is this a
> known problem?
>
> Please find logs from Sling & the failed integration tests below:
>
> https://gist.github.com/klcodanr/4984b27cb54719ce069d6347b4298647
>
> Thanks,
> Dan
>
> On Thu, Feb 16, 2017 at 10:27 AM, Robert Munteanu 
> wrote:
>
> > On Thu, 2017-02-16 at 16:21 +0100, Karl Pauls wrote:
> > > Please vote to approve this release:
> >
> > +1
> >
> > Robert
>

Re: What all changes does ResourceChangeListener are interested in

[Dominik Süß]

For me one of the most interesting filters for "native" filtering would be
based on ResourceType (& RT changes). Optimally we would even have the
option to filter by ResourceType and its SubTypes - but detecting the
subtypes is something that would go beyond a hint (basically preprocessing
a hint to "unfold" it into all of the subtypes to watch out for).

I guess within the ResourceTypes the best practice would go into the
direction of SubTyping whenever the group covered is too generic and needs
to be treated differently.

Cheers
Dominik


On Sat, Oct 15, 2016 at 8:54 AM, Carsten Ziegeler 
wrote:

> Chetan Mehrotra wrote
> > On Thu, Oct 13, 2016 at 6:18 PM, Carsten Ziegeler 
> wrote:
> >> The listeners we have are really just interested in paths
> >
> > Path is one aspect. There must be other aspect like change in specific
> > property name like sling:alias etc.
> >
>
> I think the most expensive one at the moment is the MapEntries listener
> in resource resolver which checks for vanity path and alias properties.
> So this is listening on add/remove/change of those properties.
>
> The other use case is where a listener is interested in a resource type
> - but that can't be done on Oak level as you would need to know the
> resource type hierarchy and other logic to detect the resource type.
>
> So, if we want to do this, we might add a hint for property names.
> I wouldn't go with a general filter string, like LDAP filter - as this
> creates problems on both sides: these filters are not rocket science but
> it's a little bit hard to write them, especially if they get long. And a
> provider implementation needs to parse and handle them.
> I would rather go with a "property names filter hint" - and if we detect
> other use cases we add another property for that.
>
>  Carsten
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>
>

Re: [Context Aware Configs] Merging?

[Dominik Süß]

Hi everyone,

I personally see a tooling based approach complicated due to the ownership
scenarios. We are talking about context aware configuration that typically
would be applied by some runtime user that might have limited write access
(just for a specific context). The assumption that who writes to the
inheriting configuration node also has write access to the subsequent
levels is something we cannot and should not make here. I know multiple
customer scenarios where a central site (including global configuration)
was maintained by a central marketing organization while the markets owned
their own sites - so they declare inheritance (pull) instead of having the
global one pushed.

The one thing in between that I could imagine might work sufficiently is
referencing (by path to property) instead of inheritance. This still
provides the lookup of "inheritance" at runtime where changes are reflected
in the lookup immediately but at the same time gets rid of magic
inheritance rules.

Just a thought about an alternative in between.

Cheers
Dominik

On Mon, Aug 1, 2016 at 8:36 AM, Carsten Ziegeler 
wrote:

> >> ... if you have merging (or inheritance) then you change the
> >> attribute of a parent and this influences all childs and you
> >> have no idea what happens there...
> >
> > We can create a felix console plugin that shows for a given
> > context path and config name the value of the property and the
> > path from where it was taken - that way both developers and ops
> > can quickly check what's going wrong if results are unexpected.
> >
> >> I personally think this comes all down to tooling ...
> >
> > So this could mean e.g. an additional maven plugin, which handles
> > merging of configurations and then the runtime can work without
> > merging. The problem I see with that is that
> > * you end up having two similar configuration model types (one in
> >   the source code that supports merging and one effective one for
> >   the runtime) - this makes the mechanism harder to understand
> >   for everyone
> > * the tooling has to be created and IMHO it'll not be easier/less
> >   code than creating a smarter runtime (even if we take into
> >   account that we have to create the felix console plugin to make
> >   it traceable)
> >
> First of all, you need tooling anyway. It would be foolish to make
> these configurations without any tooling by hand. Tooling can easily
> be customized to anyones needs without tampering the implementation.
> The implementation at runtime can be simply and effective.
>
> We had similar discussions while starting the work for the OSGi
> Configurator which allows you to put OSGi configurations into a bundle
> which then get applied at runtime. My initial proposal had all the
> things requested here as well (merging, inheritance etc.). It turned
> out that this messed up the specification and made the implementation
> extraordinary complicated. While moving this into the tooling which
> creates the bundles in the first place solves all the problems.
>
> Just think of all the different cases you have to solve once you
> start support merging. And not to mention the runtime implications as
> you have to do the merging dynamically at runtime as well, or you
> start introducing all kinds of caching again. All of this is not
> required if you move this to the tooling level.
>
>  Regards
>
> Carsten
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>
>

Re: [RT] Handling resource (provider) changes

[Dominik Süß]

Hi everyone,

as I get the point that having a broadcasted event for each any any change
in the ResourceTree I fear that this comes at a high price. I think it
would be good to have some mechanisms to
a) toggle of eventing for specific subtrees completely
b) just create an event for a specific subtree whenever sth changed in a
given interval
c) being able to register interest for specific paths / properties and
therefore just send event if there is any listener that claims to have
interest
For the existing behavior a listener could just register for "everything"
but it would be possible to tweak all eventlisteners in a way that reduces
the amount of events that are fired significantly (which would probably
allow to further narrow down what kind of observation we need in oak)

The oak team has tweaked in the area quite a lot to provide better scaling
of eventing - it would be a shame if our sling eventing wouldn't make use
of this or even eliminates the benefits of this.

Cheers
Dominik


On Thu, Nov 5, 2015 at 2:23 PM, Carsten Ziegeler 
wrote:

> Am 05.11.15 um 14:01 schrieb Oliver Lietz:
> > On Wednesday 04 November 2015 18:45:00 Carsten Ziegeler wrote:
> >> The current active model for observation event for resources through
> >> OSGi events is modelled after JCR observation which means that for
> >> changes to a tree you might only get an event for the root of that tree.
> >> Especially when a whole tree is deleted, you get a single event.
> >> I assume, the same could in theory be true for adding.
> >>
> >> The question is, whether we want to keep this model for the observation
> >> API we're about to implement. Especially as there are some additional
> >> things to consider:
> >>
> >> 1. With Oak we could register observation listener which provide the
> >> information about every node removed/added/changed. So we can send out
> >> detailed events. Other resource provider implementations could simply
> >> follow that concept.
> >
> > One event per resource makes implementing depending systems more
> > straightforward, e.g. adding/removing data for a resource from a search
> index.
>
> While this sounds nice, I guess in practice you can't solely rely on
> observation for this. You might miss events as your listener is
> registered "too late", is updated, uninstalled etc.
>
> > So +1.
> >
> >> 2. We have three events for resources: added/removed/changed but also
> >> two events for resource providers. Obviously, if a resource provider is
> >> mounted at some path and is unregistered, the whole tree is removed.
> >> Again, we just send out a single event.
> >>
> >> For 2. we definitely don't want to send out an event for every resource
> >> of that provider as that would be way too expensive.
> >>
> >> For 1. we might start sending out too many events as well and I assume
> >> code is already prepared for that case.
> >
> > What does that mean? _too_ many for whom? Can we process _too_ many
> events
> > reliable?
> That's a good question - I guess with good filtering by the listener
> registrations we should be able to do so.
>
> >
> >> I think we should keep the optimization (and make this clear in the new
> >> observation API) and we probably should collapse the two special
> >> resource provider events into resource events: instead of sending out a
> >> resource provider added/removed, we send out a resource added/removed.
> >> Listeners right now usually handle all five events, and we could reduce
> >> this to three events, making everything compacter, nicer and easier to
> >> understand.
> >>
> >> WDYT?
> >
> > hm, added/removed resources and added/removed resource providers are
> from some
> > aspects totally different use cases which I think should be seen as such.
>
> It depends on your point of view I think - for someone interested in
> whether a resource has been added or removed, there is no difference
> whether a resource has been removed or the resource provider who
> provided this. It's the same. And observation listeners are interested
> to find out about resource changes, therefore whether something happened
> because of a change in the database or a provider change is not relevant.
>
> > I would like to differ between added/removed resources and added/removed
> > resource providers. But having events for all resources added/removed
> when a
> > resource provider is added/removed is also helpful. -1 for collapsing.
> Can you give some use cases where you want to know about a provider
> being added or removed - in contrast to the resource it provides?
>
> >
> > How rich are these events? Can a listener determine the provider for a
> > resource? Can a listener determine if a resource was added/removed
> because its
> > provider was added/removed? - forgive my ignorance, hadn't time to look
> into
> > the new APIs so far.
>
> The current API is quiet simple - if a provider is added or removed, we
> send out a provider add/remove event with the mount path of the 

Debugging Implementation when running ITs

[Dominik Süß]

Hi everybody,

I currently want to hook in a debugger to the implementation of the
installer when running the corresponding ITs as I want to inspect the
implementation behavior and see if I could add a patch that helps in
upgrade scenarios.

Yet I had no success getting the IT start in a way that I could hook in a
remote debugger.
If I get the documentation right it should be

mvn test
-Djar.executor.vm.options="-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=8000"

(picked up from
https://sling.apache.org/documentation/development/sling-testing-tools.html)

Yet the tests just run through (and just fyi failed for
BundleInstallStressTest.testSemiRandomInstall) without waiting for a remote
connection.

Cheers

Dominik

Re: Debugging Implementation when running ITs

[Dominik Süß]

Thanks Konrad & Bertrand,

Bertrands commands for the Pax Exam tests worked for me as well :)

Cheers
Dominik

On Tue, Oct 6, 2015 at 12:26 PM, Bertrand Delacretaz <bdelacre...@apache.org
> wrote:

> Hi,
>
> On Tue, Oct 6, 2015 at 10:59 AM, Dominik Süß <dominik.su...@gmail.com>
> wrote:
> > ...I currently want to hook in a debugger to the implementation of the
> > installer when running the corresponding ITs...
>
> The sling/installer/it module uses Pax Exam and runs the tests with
> surefire.
>
> A simple way to debug the server-side code is to disable surefire
> forking so that the MAVEN_OPTS are used to configure the jvm
> debuggging:
>
>   $ export MAVEN_OPTS="-Xmx1G  -XX:MaxPermSize=256m
> -agentlib:jdwp=transport=dt_socket,address=30303,server=y,suspend=y"
>
>   $ mvn -o clean test -Dtest=BundlePrioritiesTest -DforkCount=0
>
> You can then connect to the VM on port 30303 to debug the
> OsgiInstallerImpl, for example. And of course replace the
> BundlePrioritiesTest name with whatever makes sense.
>
> -Bertrand
>

Re: Suggestion: Implement specific getParent for JcrNodeResource

[Dominik Süß]

Hi Joel,

your idea is close to what I was thinking of before but the issue is that
the ResourceProvider interface is does not provide this mechanism and the
ResourceResolverImpl therefore does not pass the BaseResource to the
ResourceProviders but as you stated calculate the path.

This is why I thought of having some kind of minicache (more a prefetching
mechanism) for resourceproviders bound to the resourceResolver (and
therefore living and dying with the resourceResolver). So this is a cache
that should auto clean up and should not do any harm.

+1 anyways for some benchmark project to have a reliable, trackable
measurement in sling for any solution applied.

Cheers
Dominik

On Thu, Apr 9, 2015 at 10:12 AM, Joel Richard joelr...@adobe.com wrote:

 Hi,

 Yesterday evening I had another idea which might be easier to implement.
 But first a few observations:

 jcrNode.getParent() is about 10 times faster than resource.getParent().
 The same is true for getChild() vs getNode(). The difference will become
 less as soon as we have fixed some other issues, but since even
 jcrSession.getNode(parentPath) is about 3.5 times slower than
 jcrNode.getParent(), it is unlikely that resource.getParent() will ever be
 as fast as jcrNode.getParent() without changing the implementation.

 getChild is implemented with getResourceResolver().getResource(this,
 relPath) and getParent could be implemented with getResource(this, ..).
 The interesting thing here is that getResource allows to pass the base
 resource to the ResourceResolver.

 At the moment this is only used to compute the absolute path. If the base
 resource was passed to ResourceProviderEntry#getInternalResource and from
 there to the JcrResourceProvider, then the JcrResourceProvider could first
 check whether the resource is an instance of JcrItemResource and whether
 the paths are related. In this case it could simply get the property/node
 and use node.getParent/node.getNode as an optimisation.

 With this approach no additional caches would have to be implemented and
 different resource providers would work together as today.

 - Joel


 On 09/04/15 06:55, Carsten Ziegeler cziege...@apache.org wrote:

 Am 09.04.15 um 08:06 schrieb Dominik Süß:
  Hi Carsten, hi Joel,
 
  AFAIU the cost intensive part is the call of createResource() at [0]
 that
  will do a look up by path but not utilize the node of the resource
 issuing
  this lookup through getParent (indirected via resourceResolver lookup by
  the AbstractResource).
 
  What would you think about caching the parentNode when getParent() is
  called for the ResourceProvider so that as the resourceResolver consults
  the JCRResourceProvider in the follow up call the parentNode is already
  present.
 
  As we most probably don't have an extremely wild mix of different
  resourceProviders this caching should only render unnecessary in the
 rare
  cases where we have a different ResourceProvider at a higher level
 without
  doing any harm but a little bit of memory consumption (feature could be
  implemented with a on-off switch ;) )
 
 
 Well, in general I'm against adding small caches all over the place as
 this
 will most likely turn into pain over time. And usually it works in one
 use case but fails (or turns into worse performance) in other use cases.
 This might not be the case here.
 
 I think, before we do any changes we should have test cases where we can
 check the results against. I trust Joel's analysis, however we don't
 have any benchmarks in the Sling project and it's very hard atm for the
 Sling community to see the problem and to verify the implications of
 a change - being it good or bad.
 
 Therefore, let's create a benchmark project first and use that for
 improvements.
 
 Regards
 Carsten
 --
 Carsten Ziegeler
 Adobe Research Switzerland
 cziege...@apache.org

Re: Suggestion: Implement specific getParent for JcrNodeResource

[Dominik Süß]

Hi Carsten, hi Joel,

AFAIU the cost intensive part is the call of createResource() at [0] that
will do a look up by path but not utilize the node of the resource issuing
this lookup through getParent (indirected via resourceResolver lookup by
the AbstractResource).

What would you think about caching the parentNode when getParent() is
called for the ResourceProvider so that as the resourceResolver consults
the JCRResourceProvider in the follow up call the parentNode is already
present.

As we most probably don't have an extremely wild mix of different
resourceProviders this caching should only render unnecessary in the rare
cases where we have a different ResourceProvider at a higher level without
doing any harm but a little bit of memory consumption (feature could be
implemented with a on-off switch ;) )

WDYT?
Dominik

[0]
https://github.com/apache/sling/blob/trunk/bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrResourceProvider.java#L154

On Wed, Apr 8, 2015 at 4:57 PM, Carsten Ziegeler cziege...@apache.org
wrote:

 Am 08.04.15 um 16:50 schrieb Joel Richard:
  Hi,
 
  I have noticed that on some “resource intensive” pages up to 24% of the
  rendering time is spent in AbstractResource.getParent(). One of the
  reasons for this is because the ParentHidingHandler traverses for each
  resource to the root (see SLING-4568).
 
  This could be improved with a getParent implementation which is specific
  to JcrNodeResource and uses getNode().getParent() directly to create a
 new
  JcrNodeResource. I have implemented such a getParent method (see attached
  experimental patch) and it reduces the time for getParent from 24% to 5%
  on this specific page.
 
  Did I miss something or is this is a legitimate change? If so, wouldn’t
  this also be a possible improvement for getChild and listChildren?
 
 I think this is not a good idea. You don't know whether the parent or
 any child resource is backed by JCR. It could be that the parent is
 delivered by a different resource provider or that child nodes are a
 combination of resource providers. So all traversal has to go through
 the resource resolver.

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

Re: [RT] Ideas for a multi-tenant and multi-module content model

[Dominik Süß]

Hi Bertrand,

ok the way how you describe it you'd actually do something above the
existing ResourceResolution. I'm not really sure if we win so much with
that - a lock in of the resourceType  might be absolutely sufficient and
wouldn't add further complexity to understand resolution mechanisms.

So we would have something that would define

a) Tenant /content/xyz would be bound to assembly_a (for now skipping the
question of versioned lookup that could be searchpath sepecific or another
mechansism)
b) this binding would force the resourceResolver to resolve resources
underneath /content/xyz only if they are located underneath
searchpath/assembly_a
c) the apps folder of assembly_a would contain the rendering resources or
have the assembly specific servlets mapped to. Every servlet or script used
within the assembly app would have a representation there which could as
minimum just have a resourceSuperType that points to the modules
resourceType and therefore expose the plain feature. Assembly specific
overlays can be applied to these mapping nodes at any time without impact
on third assemblies (unless we allow chained assemblies)

The beauty of that would be that it just requires addition of mapping logic
and the constraints in the resourceResolver but no further addition.

Sidenote:
- I'm leaving out details like static inclussions with predefined
resourceTypes within scripts the assembly where we would have to clarify if
those are ok or if we completely abandon mapping beyond superType
resolution to enforce a unique way of declaring mapped Types within an
assembly.

Cheers
Dominik


On Thu, Jan 29, 2015 at 3:03 PM, Bertrand Delacretaz bdelacre...@apache.org
 wrote:

 Hi Dominik,

 On Thu, Jan 29, 2015 at 2:52 PM, Dominik Süß dominik.su...@gmail.com
 wrote:
  ...I had a chance to look at that model yesterday and absolutely think
 this is
  a great way since it is not too far away from what we have right now...

 Yeah, we might even be able to run an existing Sling instance with
 /libs and /apps as a legacy tenant on this new model by moving the
 existing content around a bit, to provide a smooth transition.

  ...The detail about the constraint to just use an assembly would
 therefore be
  a constraint on the resourceType Path that would be evaluated by the
  resourceResolver and ignores resourceType not being part of the
 assembly

 I was thinking a bit differently, resource types just need to start
 with the module path like blog/post for the blog module.

 Then, the script resolver only considers /assemblies/T where T is the
 tenant ID, looks for a script or servlet reference resolution for
 blog/post under there, and remaps that to the actual module script
 based on which modules the assembly points to.

 All this needs to be proved by some working code if we want to
 seriously kick the tires of this new model.

 -Bertrand

Re: [RT] Ideas for a multi-tenant and multi-module content model

[Dominik Süß]

Hi Bertrand,

I had a chance to look at that model yesterday and absolutely think this is
a great way since it is not too far away from what we have right now and
what could be seen as best practice for compositing and customizing
applications based on Sling and other propietary modules.

I think visualizing your blog  example with some boxes and lines would help
others that yet had not a chance to discuss this to understand how this
could work out.

What is a bit hard to read from that model is what kind of changes would
need to be done in Sling to make that work (just the high level changes not
the implementation detail).

The detail about the constraint to just use an assembly would therefore be
a constraint on the resourceType Path that would be evaluated by the
resourceResolver and ignores resourceType not being part of the assembly.
The mapping to functionality/resourceTypes out of the underlying modules
would be realized through those mappin resources with the resourceSuperType
(which then could point out of the assembly).

I hope my addition helps a bit to clarify the base idea of the assembly
pattern and does not create more confusion.

Best regards,
Dominik

On Tue, Jan 27, 2015 at 6:55 PM, Bertrand Delacretaz bdelacre...@apache.org
 wrote:

 Hi,

 I've been thinking a lot about a content model that would help Sling
 applications be naturally friendly to multi-tenancy and to continuous
 deployment where multiple versions of modules need to coexist.

 I have now written those thoughts down at

 https://cwiki.apache.org/confluence/display/SLING/Ideas+for+a+multi-tenant+and+multi-module+content+model

 Feedback is welcome but please keep in mind that this is mostly just
 thinking outloud at this point.

 Credit goes to Dominik Suess for the assemblies idea, it looks like
 this intermediate routing layer might help make sense of complex
 multi-T and multi-M systems.

 -Bertrand

Re: ResourceWrapper issue with ResourceMetadata

[Dominik Süß]

Hi Carsten,

thanks for your quick feedback - yes it works without functional
degradations but it actually spams the error.log with INFO messages which
is not acceptable in productive Code. Do you see a way to workaround this
issue and/or give an estimation when this issue could be fixed? I'd help
myself but this part was tweaked a lot in the mentioned ticket and I'd fear
to break things.

A minor fix would be to add a try catch block for contentlenght and skip it
if this exception occurs (don't know if there is other logic relying on
contentlenght that would break).

Best regards,
Dominik

On Tue, Oct 28, 2014 at 8:48 PM, Carsten Ziegeler cziege...@apache.org
wrote:

 This is the ugly code trying to get the content length for a resource. I
 think this code is unchanged, it's now just invoked different and maybe
 the reporting of the exception is new. However, the exception is
 swalled, so your provider should still work.

 But maybe we have to revisit the code in order to properly avoid the
 exception if possible.

 Carsten

 Am 28.10.14 um 14:46 schrieb Dominik Süß:
  Hi everybody,
 
  I might have found a bug related to the changes of SLING-3848.
  Due to some requirements some properties of a resource had to be moved
 to a
  third location for the resources of one very specific contentbranch. Now
 I
  do have a ResourceProvider that does nothing more then creating a
  ResourceWrapper in the original location hiding the JCRNodeResource
  underneath. As proposed by Carsten in another thread (see [0]) I solve
 the
  problem of the locked JCRNodeResourceMetadata via creating a new Metadata
  object and setting the entries via putAll() in the constructor of the own
  Wrapper. At this point I get an exception caused by a
 node.getPrimaryItem()
  call in JCRNodeResourceMetadata ([1] Line 164).
 
  ---
  org.apache.sling.jcr.resource.internal.helper.jcr.JcrNodeResource
  setMetaData: Problem extracting metadata information for
  /etc/mypath/jcr:content
  javax.jcr.ItemNotFoundException: No primary item present on node
  getPrimaryItem
  ---
 
  I verified that this happens on oak based and jcr 2 based instances. I
  don't know the exact mechanism of SLING-3848 [2], how that node is
 supposed
  to behave and what the goal of that codefragment exactly is, but I expect
  other consumers to fail as well since SuperImposingResource [3] actually
 is
  doing the same (although in an own resource not a ResourceWrapper, but
 that
  shouldn't be a difference in the constructor.
 
  Any ideas what's going on here?
 
  Best regards
  Dominik
 
  [0] http://markmail.org/thread/ortcft2vjjs2ukga
  [1]
 
 http://svn.apache.org/viewvc/sling/trunk/bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResourceMetadata.java
  [2] https://issues.apache.org/jira/browse/SLING-3848
  [3]
 
 https://github.com/apache/sling/blob/trunk/contrib/extensions/superimposing/src/main/java/org/apache/sling/superimposing/impl/SuperimposingResource.java#L44
 


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

ResourceWrapper issue with ResourceMetadata

[Dominik Süß]

Hi everybody,

I might have found a bug related to the changes of SLING-3848.
Due to some requirements some properties of a resource had to be moved to a
third location for the resources of one very specific contentbranch. Now I
do have a ResourceProvider that does nothing more then creating a
ResourceWrapper in the original location hiding the JCRNodeResource
underneath. As proposed by Carsten in another thread (see [0]) I solve the
problem of the locked JCRNodeResourceMetadata via creating a new Metadata
object and setting the entries via putAll() in the constructor of the own
Wrapper. At this point I get an exception caused by a node.getPrimaryItem()
call in JCRNodeResourceMetadata ([1] Line 164).

---
org.apache.sling.jcr.resource.internal.helper.jcr.JcrNodeResource
setMetaData: Problem extracting metadata information for
/etc/mypath/jcr:content
javax.jcr.ItemNotFoundException: No primary item present on node
getPrimaryItem
---

I verified that this happens on oak based and jcr 2 based instances. I
don't know the exact mechanism of SLING-3848 [2], how that node is supposed
to behave and what the goal of that codefragment exactly is, but I expect
other consumers to fail as well since SuperImposingResource [3] actually is
doing the same (although in an own resource not a ResourceWrapper, but that
shouldn't be a difference in the constructor.

Any ideas what's going on here?

Best regards
Dominik

[0] http://markmail.org/thread/ortcft2vjjs2ukga
[1]
http://svn.apache.org/viewvc/sling/trunk/bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResourceMetadata.java
[2] https://issues.apache.org/jira/browse/SLING-3848
[3]
https://github.com/apache/sling/blob/trunk/contrib/extensions/superimposing/src/main/java/org/apache/sling/superimposing/impl/SuperimposingResource.java#L44

Re: [RTC] ThreadLocal for getting current request in sling

[Dominik Süß]

Hey everybody,

thinking about this again I also realized that changing the Adaptable
Interface or having another one creates more issues then solving.  In fact
it would be way easier to have some generic Wrapperclass  that can hold the
request and another object and implementing Adaptable.

This would require some change for the Use semanticts of Sightly to wrap
request and resource (currentResource by default but could be overriden by
parameter) and the Models implementation would use this adaptable instead
of request _or_ resource.

WDYT?

Dominik

On Fri, Oct 24, 2014 at 3:34 PM, Justin Edelson jus...@justinedelson.com
wrote:

 Hi Stefan,

 On Fri, Oct 24, 2014 at 7:53 AM, Stefan Seifert sseif...@pro-vision.de
 wrote:
 
 Personally, I don't quite see the use case -- if your AdapterFactory
 (whether it is generated by Sling Models or hand-coded) needs
 request-based context, the adaptable is the request.
 
  to shed some more light on my usecase an example:
 
  - a sightly template calls a controller model, which adapts from the
 current request
  - this model wants to output an object structed based on a complex data
 structure (e.g. a list of nodes with subnodes)
  - this data structure cannot be used directly for output, but some
 properties need some special processing
  - so we build a set of models for this data structures adapting to a
 resource for each node, injecting each other for @ChildResource for the
 hierarchy
  - each of this resource models does post processing on some attributes,
 e.g.
- resolving a media asset reference to a set of externalized image
 URLs for responsive imaging
- externalizing an URL respecting sling short URL mapping
- injecting dummy images or links for invalid references - but only if
 the edit mode of the CMS is active.
  - this post processing is done with further models that implement the
 business logic to solve this centrally
 
  it is an implementation details of the post processing business models
 that they need a request for some part of their job (e.g. distinguish
 between edit and preview mode). the caller of the initial adaption is not
 necessary aware of this and should not care of it in my point of view.

 This is all just an implementation choice. Nothing is forcing you do
 to the post processing in an object which doesn't have the request.
 You can just as easily (probably better) do that post processing in an
 object which has direct access to the request. Or, as Alex suggested,
 provide the request to those objects once they are adapted.

 And of course the caller has to be aware that the request is
 necessary. It is part of the context of that the execution of that
 post processing.

  if you call and OSGi service you do not have to know what services this
 has bound internally, OSGi takes care that all are resolved or the service
 is not available.

 I don't think this is the right analogy. You aren't talking about
 service dependencies, you are talking about the API. If I have a
 method called getFoo(Object context) and the context object is
 required for proper execution. If I pass null as the context object,
 then I shouldn't expect to get a valid response.

 
  i'm not a fan of the proposals to extend the adaptTo() semantic for this
 usecase. not only because its difficult to do it without breaking existing
 code (or leads to an interface like Adaptable2), the caller should not have
 to now the implementation details for such cross-cutting concern models
 that are required deeper in the model structure. for the same reason
 extending the sling models factory interface or having additional
 setRequest() methods on the models are no fitting solutions - the model
 that is adapted initially is not the problem, but those further down the
 hierarchy.
 
  having an interface like RequestScope is basicall going into the right
 direction - but who should detect this interface and inject the request?
 the sling models implementation? than we have the same problem not able to
 geht the request objects if it's not the adaptable. and sling models does
 not need such interfaces, its solely based on @Inject annotations.

 As I said, this has nothing to do with Sling Models. It is a general
 problem with adapters.

 Justin

 
  this is getting a long thread, i'll write a summary to lead to a
 decision.
 
  stefan
 

Re: [RTC] ThreadLocal for getting current request in sling

[Dominik Süß]

Hi Justin,

it is not true that no change in sightly would be required sightly use just
tries to adapt resource or request, not any other objects (see
ClassUseProvider L65 ff as to be found in the contribution zip).

I'm currently searching for the option to solve the case with the least
modifications and least impact but this is the constraint that I couldn't
eliminate.

Cheers
Dominik

On Fri, Oct 24, 2014 at 4:32 PM, Justin Edelson jus...@justinedelson.com
wrote:

 Hi Dominik,

 Anyone is free to define their own objects which implement Adaptable
 and their own model classes which can be adapted from those adaptable
 classes. This doesn't require any additions to any part of Sling nor
 any changes to Sightly.

 Regards,
 Justin

 On Fri, Oct 24, 2014 at 10:20 AM, Dominik Süß dominik.su...@gmail.com
 wrote:
  Hey everybody,
 
  thinking about this again I also realized that changing the Adaptable
  Interface or having another one creates more issues then solving.  In
 fact
  it would be way easier to have some generic Wrapperclass  that can hold
 the
  request and another object and implementing Adaptable.
 
  This would require some change for the Use semanticts of Sightly to wrap
  request and resource (currentResource by default but could be overriden
 by
  parameter) and the Models implementation would use this adaptable instead
  of request _or_ resource.
 
  WDYT?
 
  Dominik
 
  On Fri, Oct 24, 2014 at 3:34 PM, Justin Edelson 
 jus...@justinedelson.com
  wrote:
 
  Hi Stefan,
 
  On Fri, Oct 24, 2014 at 7:53 AM, Stefan Seifert sseif...@pro-vision.de
 
  wrote:
  
  Personally, I don't quite see the use case -- if your AdapterFactory
  (whether it is generated by Sling Models or hand-coded) needs
  request-based context, the adaptable is the request.
  
   to shed some more light on my usecase an example:
  
   - a sightly template calls a controller model, which adapts from the
  current request
   - this model wants to output an object structed based on a complex
 data
  structure (e.g. a list of nodes with subnodes)
   - this data structure cannot be used directly for output, but some
  properties need some special processing
   - so we build a set of models for this data structures adapting to a
  resource for each node, injecting each other for @ChildResource for the
  hierarchy
   - each of this resource models does post processing on some
 attributes,
  e.g.
 - resolving a media asset reference to a set of externalized image
  URLs for responsive imaging
 - externalizing an URL respecting sling short URL mapping
 - injecting dummy images or links for invalid references - but only
 if
  the edit mode of the CMS is active.
   - this post processing is done with further models that implement the
  business logic to solve this centrally
  
   it is an implementation details of the post processing business models
  that they need a request for some part of their job (e.g. distinguish
  between edit and preview mode). the caller of the initial adaption is
 not
  necessary aware of this and should not care of it in my point of view.
 
  This is all just an implementation choice. Nothing is forcing you do
  to the post processing in an object which doesn't have the request.
  You can just as easily (probably better) do that post processing in an
  object which has direct access to the request. Or, as Alex suggested,
  provide the request to those objects once they are adapted.
 
  And of course the caller has to be aware that the request is
  necessary. It is part of the context of that the execution of that
  post processing.
 
   if you call and OSGi service you do not have to know what services
 this
  has bound internally, OSGi takes care that all are resolved or the
 service
  is not available.
 
  I don't think this is the right analogy. You aren't talking about
  service dependencies, you are talking about the API. If I have a
  method called getFoo(Object context) and the context object is
  required for proper execution. If I pass null as the context object,
  then I shouldn't expect to get a valid response.
 
  
   i'm not a fan of the proposals to extend the adaptTo() semantic for
 this
  usecase. not only because its difficult to do it without breaking
 existing
  code (or leads to an interface like Adaptable2), the caller should not
 have
  to now the implementation details for such cross-cutting concern models
  that are required deeper in the model structure. for the same reason
  extending the sling models factory interface or having additional
  setRequest() methods on the models are no fitting solutions - the
 model
  that is adapted initially is not the problem, but those further down the
  hierarchy.
  
   having an interface like RequestScope is basicall going into the
 right
  direction - but who should detect this interface and inject the request?
  the sling models implementation? than we have the same problem not able
 to
  geht the request objects if it's

Re: [RTC] ThreadLocal for getting current request in sling

[Dominik Süß]

Hi everyone,

didn't follow the whole discussion so I might have missed some poin but if
I get it right the case where it gets problematic is when I essentially
want to adapt to from a resource (that is not the currentResource) without
losing the request scope.

While request.adaptTo(Target.class) would enable an AdapterFactory to get
hold of the currentResource there is no chance to get the the custom
resource.

To get around that I was thinking if it wouldn't be a good idea to add a
further adaptTo() signature which would allow to add a generic payload
which could contain contextobjects that an adapterFactory could use for
construction.In case of SlingModels everything in this payload could be
injected if there is a matching property to inject those.

I know its a bold idea but much less magic then ThreadLocals.

Cheers
Dominik

On Thu, Oct 23, 2014 at 8:22 AM, Carsten Ziegeler cziege...@apache.org
wrote:

 Am 22.10.14 um 23:21 schrieb Alexander Klimetschek:
  On 22.10.2014, at 01:22, Stefan Seifert sseif...@pro-vision.de wrote:
  i propose to add a new feature to the Sling API and Sling Engine to
 access to the current request via an OSGi service, using a servlet filter
 and a thread local internally.
 
  -1
 
  a proposal for such an implementation is currently part of sling models
 trunk, but should be renamed and moved to a more central part if we agree
 if it is a good idea. interface [1], impl [2].
 
  Why? This looks like a hack to me, and will lead to people not designing
 their APIs properly (e.g. passing the request through). I see ThreadLocal
 as a workaround when you don't have influence on the API but still need to
 pass things around. But in this case (sling models and the wcm.io config,
 below) there is full control over the API.
 
  A class like SlingObjectInjectorRequestContext sound very much like
 anti-patterns from Spring et al.
 
  we have already a comparable threadlocal concept for resource resolver
 [3]
 
  Broken window :D

 Well, it's easy to judge on a high level without knowing the details.
 We're all aware of the dangers of thread locals, but matter of fact is,
 there are use cases where you need the resource resolver and there are
 tons of layers in between the code using the resource resolver and where
 it is available. In some cases the api is not even created in Sling, so
 there is absolutely no way to pass the resolver down to the code other
 than using a thread local.

 And instead of creating an island solution for every use case, so we end
 up with dozens of thread locals and filters and whatnot, having a
 general single solution is imho preferable.

 However, I see/have use cases for the resource resolver, I'm not 100%
 about the request yet :)

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

Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy

[Dominik Süß]

Hi everyone,

just added my comment to the mentioned usecase page at [0]. Please note
that the solutions I've extracted that from were partially ui driven so I
had to abstract quite a lot to get generic requirements out of those. This
also means that it might still be a bit ui oriented which I would really
try to avoid and focus on the reading part first.

Anyways the editing process from a pure data (not ui) perspective might
create some constraints that need to be thought of for the final api.

Best regards
Dominik

[0]
https://cwiki.apache.org/confluence/display/SLING/Context-specific+configuration+use+cases?focusedCommentId=47384290#comment-47384290

On Fri, Oct 17, 2014 at 2:31 PM, Bertrand Delacretaz bdelacre...@apache.org
 wrote:

 Hi Stefan,

 On Fri, Oct 17, 2014 at 2:08 PM, Stefan Seifert sseif...@pro-vision.de
 wrote:
  ...the alternative storing at /conf is already implemented [1] - it's up
 to
  the system configuration which persistence provider is used...

 Ok, now I remember reading this earlier in this thread. Sorry about
 the noise, it's a long thread ;-)

 -Bertrand

Re: [RTC] ThreadLocal for getting current request in sling

[Dominik Süß]

Hi Alex,

adding some contexobject is IMHO not hidding anything. There are cases
where you would want to have the context for creation of a model (or any
other adaptable) - so at construction time which disqualifieds some method
to be called afterwards.
What't the issue with someresource.adaptTo(MyClass.class, request)  (or as
bertrand mentioned any other payload) which could be used by the
AdapterFactory?
In case of Scripting languages as sightly we cannot easily create wrapper
objects that are used for adaption that could hold the real adaptable and
the additional context object(s). Therefore I would love to have this
option and extend the Sightly use to be able to hand over an additional
object and/or by default trying to add the request object if adapted from a
model. The Sling Model or adaptable could then utilize this request object
or simply ignore it where not necessary.

Best regards
Dominik

On Thu, Oct 23, 2014 at 10:50 PM, Alexander Klimetschek aklim...@adobe.com
wrote:

 On 23.10.2014, at 01:04, Dominik Süß dominik.su...@gmail.com wrote:
 
  While request.adaptTo(Target.class) would enable an AdapterFactory to get
  hold of the currentResource there is no chance to get the the custom
  resource.

 Why not have a setter?

 MyModel model = resource.adaptTo(MyModel.class)'
 model.setRequest(slingRequest);

 or just pass it along with the methods you call, if you only need it in
 some calls:

 model.doSomething(foo, slingRequest);


 IMO it is very important that devs using code are aware that they are
 using the request object and are in a request scope or not, so hiding it is
 not something you want to strive for.

 Cheers,
 Alex

Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling, Multitenancy

[Dominik Süß]

Hi everyone,

I guess people yet just had no chance to dig into the proposal since there
are a lot of scenarios adressed throught this proposal. As far as I
understood the API  SPI the main driver for this proposal is the massive
multisite scenario as described in the mentioned wiki page. Key aspects
seem to be to get an aggregated context specific view for a configuration
while lookup aspects (such as where to look up the configs and how
inheritance is solved) are designed in a pluggable way that allows to
implement application specific behavior.

From offlist discussions I know that there might be some confusion around
how the scoping should work so I just wanted to highlight the mentioned
link [3] that might eliminate confusion around the wording (especially
appliation).

IMHO it would be an extremely valuable addition providing sufficient
flexiblity to solve all the cases I do have in mind while establishing one
unified methodology to deal with all the non osgi configuration without
rewriting casespecific lookup (boilerplate) code over and over again.

Best regards,
Dominik

[3] http://wcm.io/config/api/terminology.html



On Sat, Oct 4, 2014 at 1:55 AM, Stefan Seifert sseif...@pro-vision.de
wrote:

 p.s. url [1] is wrong - it should be
 https://cwiki.apache.org/confluence/x/So2uAg

 -Original Message-
 From: Stefan Seifert [mailto:sseif...@pro-vision.de]
 Sent: Saturday, October 04, 2014 1:54 AM
 To: dev@sling.apache.org
 Subject: [PROPOSAL] Context-specific configuration for Apache Sling,
 Multitenancy

 this proposal is about context-specific configuration, that means
 configuration that cannot be stored as OSGi configurations. OSGi
 configurations are always system-wide, so they are not well-suited for
 storing configurations per context e.g. site, region or tenant. this is
 related to the multitenancy discussion on this list, see [1] for a summary
 of the past discussion.

 we've implementation a solution for this and are currently thinking about
 donating it to Apache Sling. a documentation of what is currently
 implemented is at [2]. the most relevant pages you should read are [3],
 [4], [5], [6]. the implementation is based on the requirements from [7],
 although not all that is listed on that page is implemented currently (but
 a good deal of it). source code is at [8], a sample application at [9].

 the current implementation is targeted to a specific sling-based CMS - but
 besides the configuration editor and the parameter persistence provider it
 does not depend on the CMS API but only on the Sling APIs, being
 technically suited to be donated to Apache Sling. it's already published
 under apache license 2.0.

 i'm interested if there is more need in the community for solving the
 requirements i've listed, and the solutions we have implemented for it. and
 if there are other sling committers who want to take part in its
 development and enhancement as well. although we're using the current
 implementation from wcm.io already in our projects nothing of it's
 current architecture is carved in stone and i'm open to broaden the scope
 of requirements it should support.

 WDYT?

 stefan


 [1] https://cwiki.apache.org/confluence/x/zJBcAg
 [2] http://wcm.io/config/
 [3] http://wcm.io/config/api/terminology.html
 [4] http://wcm.io/config/api/usage-api.html
 [5] http://wcm.io/config/api/usage-spi.html
 [6] http://wcm.io/config/editor/usage.html
 [7] https://wcm-io.atlassian.net/wiki/x/HIAH
 [8] https://github.com/wcm-io/wcm-io/tree/master/config
 [9] http://wcm.io/samples/config-sample-app/

Re: Updates to the Slingstart Model

[Dominik Süß]

Hi Carsten,

I probably just struggle with the naming but I guess runModes should
provide similar capabilities as runmodes currently do (with the
config.runmode options and so on).
Therefore I wonder if it really reasonable to splitt runmodes or to better
have the second one and potentially assign configurations, settings and
artifacts to multiple runmodes. As soon as one of the runmodes is active
this would be activated (basically runmodes would be used as toggles for
the fragments).

Or did I get this completely wrong?

Cheers
Dominik

On Wed, Oct 1, 2014 at 12:44 PM, Carsten Ziegeler cziege...@apache.org
wrote:

 So what do people think?

 Should we rather go with

 [runMode name=jackrabbit]
 [artifacts startLevel=1]
..artifacts for level 1
 [artifacts startLevel=5]
   ..artifacts for level 5
 [configurations]
   ..configurations
 [settings]
   .settings

 or

 [artifacts startLevel=1 runMode=jackrabbit]
..artifacts for level 1
 [artifacts startLevel=5 runMode=jackrabbit]
   ..artifacts for level 5
 [configurations runMode=jackrabbit]
   ..configurations
 [settings runMode=jackrabbit]
   .settings

 The latter is easier to read/understand but requires more typing.

 WDYT?

 Please note that this only affects the textual representation, the object
 model is still tree based.

 Carsten

 2014-09-30 17:48 GMT+02:00 Carsten Ziegeler cziege...@apache.org:

  Hi Robert,
 
 
  2014-09-30 17:22 GMT+02:00 Robert Munteanu romb...@apache.org:
 
  I haven't looked very much in depth at this, but I like where this is
  heading. A couple of questions/nitpicks:
 
  1. Attaching additional information to artifacts currently looks like
 this
 
org.apache.commons/commons-math/2.2/jar {sha1=2353750701ABE}
 
  How will multiple attributes look like? We can have a CSV list, e.g.
  {att1=val1,att2=val2} or multiple space-separated groups, e.g.
  {att1=val1} {att2=val2} . I think the first one looks better but needs
  to define escaping.
 
 
  Also, when I see a '{' '}' block I immediately think of code. Perhaps
  it would be more intuitive to have these attributes enclosed in
  parenthesis, e.g. '(sha1=CAFEBABE)'.
 
  While writing the parser I noticed that { } is not the best option
  anyway, as we also use this for variables ${var}
  So I changed to '[', ']' and multiple attributes would be
  [att1=val1,att2=val2]. Whitespaces within the block are ignored.
  Right now, no escaping is supported and simply assumed that neither the
  attribute name nor the value contain a = :)
  But that would be easy to fix.
 
  2. One of the example OSGi configs has a string value quoted and also
  escaped
 
  # A plain configuration
  org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService
  name=Default\ NodeStore
  repository.home=sling/oak/repository
 
  Would it not be simpler to have the value be Default NodeStore ?
 
  This is how the Apache Felix CA Implementation writes the stuff out. I
  think that's a bug in the implementation and a space should not be
 escaped.
  However, you can write:
  name=Default NodeStore and this is correctly read. But once config
 admin
  writes the configuration out, the space is escaped.
 
 
  3. Runmode configuration needs an additional section, and is ( I think
  ) the only case where we have nested sections. Would it simplify the
  model and make the file easier to understand by including them as
  attributes to various sections ? I think this model looks somewhat
  flat - which is a good thing - but is not very good at expressing deep
  nesting like XML/JSON.
 
  [artifacts startLevel=15 runModeName=jackrabbit]
  org.apache.derby/derby/10.5.3.0_1/jar
 
 
 org.apache.sling/org.apache.sling.jcr.jackrabbit.server/2.1.3-SNAPSHOT/jar
 
 
  Yes, this is the area where I'm not 100% sure either. We have a nested
  model: feature - run modes - artifact groups (aka start level).
  If you're not using run modes nor start levels, then it's nicely flat and
  looks good. As soon as you're using one of it or even in combination it
  gets worse (this is where all tree based approaches shine).
  We could do what you're suggesting, but that requires repeating the same
  stuff over and over, e.g if you have two start levels for a runmode, you
  have to specify the run mode name twice etc.
 
  Carsten
 
 
  Thanks,
 
  Robert
 
  
   Regards
   Carsten
  
   2014-09-30 8:11 GMT+02:00 Carsten Ziegeler cziege...@apache.org:
  
   Hi,
  
   2014-09-29 15:36 GMT+02:00 Carsten Ziegeler cziege...@apache.org:
  
   Hi Bertrand,
  
  
   2014-09-29 14:42 GMT+02:00 Bertrand Delacretaz 
  bdelacre...@apache.org:
  
  
   Can we call this startup model BTW? It's more descriptive than
   slingstart.
  
   I'm fine with nearly any name, I just picked the first thing
 running
   through my brain...
   While startup model is more descriptive, the model can also be
 used
  to
   describe partial systems (being it a subsystem etc.), therefore
  startup
   is slightly missleading.
   The same goes 

Re: Sling content editor tool needed?

[Dominik Süß]

Hi everyone,

here my 2 cents about changes that I would like to see (had a short chat
with Sandro at adaptTo() about that):
* rename it and get rid of JCR in the name since it effectively is a
resourceTreeBrowser
* make sure to be compatible with all ResourceProviders through CRUD API
(and blend out operations not available for ResourceProviders not
supporting it)
* get rid of the Selectorbased ResourceDecorator pattern for the browser
but implement a ResourceProvider which does the decorationion to make sure
code can be properly secured for production instances and does not impact
rendering of 3rd code at all.

If all of those points are met I guess this could really be something
useful (especially when not basing on commercial varations that provide a
browser) which can be included without having to worry that it actually
interfers with the application.

Cheers
Dominik

On Wed, Oct 1, 2014 at 3:06 PM, Sandro Boehme sandro.boe...@gmx.de wrote:

 Hi Bertrand,

 Am 01.10.14 14:43, schrieb Bertrand Delacretaz:

 Hi Sandro,

 On Wed, Oct 1, 2014 at 2:36 PM, Sandro Boehme sandro.boe...@gmx.de
 wrote:

 ...To provide Apache Sling with a content editor like the JCRBrowser I
 would
 like to know what is needed to contribute the JCRBrowser to Sling. I
 could
 for example understand if more features are needed...


 IIUC your JCRBrowser is read-only at the moment?

 beside showing content the Sling JCRBrowser can rename nodes and delete
 single nodes and a list of selected nodes.

  If yes adding create/update/delete functionality would be nice of
 course, but I'm in favor of accepting your contribution in its present
 state so that you can benefit from this community's feedback to evolve
 it.

 As you're not a committer for now you'd need to submit patches to
 expand it, but that's the best way to become a committer, by showing
 us how you work and communicate based on a real project.

 I'm absolutely fine with submitting patches.


 So IMO we should accept this contribution now (in contrib - not core
 for now) - what do others think?

 -Bertrand


 Best,

 Sandro

Re: [ANN] New Apache Sling Committer: Stefan Seifert

[Dominik Süß]

Gratulations!
Glad to see all the new Commiters and hope too see more of those great
contributions :)

Best regards
Dominik



On Mon, Sep 8, 2014 at 10:07 PM, Mike Müller mike...@mysign.ch wrote:

 Welcome on board Stefan!

 Best regards
 mike

  -Original Message-
  From: Stefan Seifert [mailto:sseif...@pro-vision.de]
  Sent: Monday, September 08, 2014 9:21 PM
  To: dev@sling.apache.org
  Subject: RE: [ANN] New Apache Sling Committer: Stefan Seifert
 
  thank you very much!
 
  a few introductory words about me:
 
  i'm living (and was born) in berlin. i'm closely attached with apache
 projects since nearly 15 years now. in the first years
  that was primarily the apache cocoon framework, but since 2009 my focus
 lies at apache sling and felix. i've touched a
  lot of areas of sling in the past, currently i'm involved in the sling
 models and testing subprojects. a new area where i see
  the need for adding important features to the sling frameworks is multi
 tenancy and configuration support. i'm looking
  forward to further support sling in the future!
 
  stefan
 
  p.s. btw. my company is the host and sponsor (together with adobe) of
 the yearly conference for Sling  Friends in
  Berlin: http://adapt.to
 
 
  -Original Message-
  From: Carsten Ziegeler [mailto:cziege...@apache.org]
  Sent: Monday, September 08, 2014 6:21 PM
  To: dev@sling.apache.org
  Subject: [ANN] New Apache Sling Committer: Stefan Seifert
  
  Hi
  
  it's my pleasure to announce that the Apache Sling PMC has invited
 Stefan
  Seifert as a new Sling committer...and Stefan accepted.

adaptTo 2014 - The final countdown...

[Dominik Süß]

Hi community,

adaptTo is about to start in less then two weeks. If you yet haven't
registered this might be your chance to get one of the remaining tickets
and join us for this great opportunity to learn from each other, share
experiences and drive the evolution of Apache Sling itself as part of the
community.

We have a great mix of talks that should have content for attendees of
various skill levels and various topics related to this project.
Additionally we try to give you a plattform that allows to come together
work together or just drink free beer and enjoy the buffet at the end of
day 2.

We really hope to see all of you here in Berlin.

Best regards
Dominik

Re: Sling Request Filter filtering

[Dominik Süß]

To be honest, for me it currently is the main reason. And the code I'm
refering to is owned by a vendor and getting hotfixes can take way to long.

Aditionally right now writting working code is pretty easy but there is no
support that helps to write proper skipping (cheap and early) of filters
and therefore to write well performing and low impact filters. Giving some
OOTB features for such a mighty extensionpoint as Filters seems like a good
idea making it easy to write good code.

As shown with the ColumnCtrlFilter developers sometimes do simply not
realize that they might be way to intrusive because in the current state of
applications the filters do no harm.

Dominik


On Mon, Aug 18, 2014 at 10:25 PM, Carsten Ziegeler cziege...@apache.org
wrote:

 Well, so the main argument is badly written code?


 2014-08-18 19:35 GMT+02:00 Dominik Süß dominik.su...@gmail.com:

  Hi Carsten,
 
  I've played around with filters a lot and the problem with them really is
  that they often have way to much impact and are not constrainted as they
  would need to be. Even those filters skipping often create a lot of
  overhead because they do not skip fast and with cheap evaluations but
  instanciate expensive objects and so on.
 
  Therefore some easy but well performing mechanisms to perform checks in
  first place would really help to avoid uncessary overhead in the request
  livecycle.
 
  Additionally the option to block filters in specific cases without
  deployment would be really something that would help a lot in production
  where waiting for some vendor to fix a filter might take way to long ;)
 
  Cheers
  Dominik
 
  On Mon, Aug 18, 2014 at 1:17 PM, Carsten Ziegeler cziege...@apache.org
  wrote:
 
   Do we really really need this? At least path based filtering can be
 done
   with plain servlet filters already.
  
   What are the use cases for this?
  
   Carsten
  
  
   2014-08-18 13:07 GMT+02:00 Felix Meschberger fmesc...@adobe.com:
  
Hi
   
I am not sure, whether we should go down that route.
   
A filter ist something which is a cross-cutting concern that the
application places on the request processing. As such it is
 transparent
   to
the client and it should not be client adressable. Otherwise
 unexpected
behaviour is guaranteed.
   
Regards
Felix
   
Am 18.08.2014 um 11:32 schrieb Bertrand Delacretaz 
   bdelacre...@apache.org
:
   
 Hi,

 On Mon, Aug 18, 2014 at 11:23 AM, Felix Meschberger 
   fmesc...@adobe.com
wrote:
 ... * filter.resourceType: The Filter is only called if the
   resourceType
   of the current Resource
 (SlingHttpServletRequest.getResource)
   matches any of the given resource types...

 I've long been thinking that we should allow Sling's script/servlet
 resolution logic to be used for more than finding request
 processing
 servlets.

 Is it something that would apply here?

 I'm not sure how that could work, but as an initial experiment we
 could add a SLING-FILTER selector to the request, resolve that to a
 servlet and expect that to be a Filter. And if that works define
 that
 better as presented like this it's quite a hack ;-)

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



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

Re: Sling Request Filter filtering

[Dominik Süß]

Hi Carsten,

I've played around with filters a lot and the problem with them really is
that they often have way to much impact and are not constrainted as they
would need to be. Even those filters skipping often create a lot of
overhead because they do not skip fast and with cheap evaluations but
instanciate expensive objects and so on.

Therefore some easy but well performing mechanisms to perform checks in
first place would really help to avoid uncessary overhead in the request
livecycle.

Additionally the option to block filters in specific cases without
deployment would be really something that would help a lot in production
where waiting for some vendor to fix a filter might take way to long ;)

Cheers
Dominik

On Mon, Aug 18, 2014 at 1:17 PM, Carsten Ziegeler cziege...@apache.org
wrote:

 Do we really really need this? At least path based filtering can be done
 with plain servlet filters already.

 What are the use cases for this?

 Carsten


 2014-08-18 13:07 GMT+02:00 Felix Meschberger fmesc...@adobe.com:

  Hi
 
  I am not sure, whether we should go down that route.
 
  A filter ist something which is a cross-cutting concern that the
  application places on the request processing. As such it is transparent
 to
  the client and it should not be client adressable. Otherwise unexpected
  behaviour is guaranteed.
 
  Regards
  Felix
 
  Am 18.08.2014 um 11:32 schrieb Bertrand Delacretaz 
 bdelacre...@apache.org
  :
 
   Hi,
  
   On Mon, Aug 18, 2014 at 11:23 AM, Felix Meschberger 
 fmesc...@adobe.com
  wrote:
   ... * filter.resourceType: The Filter is only called if the
 resourceType
 of the current Resource (SlingHttpServletRequest.getResource)
 matches any of the given resource types...
  
   I've long been thinking that we should allow Sling's script/servlet
   resolution logic to be used for more than finding request processing
   servlets.
  
   Is it something that would apply here?
  
   I'm not sure how that could work, but as an initial experiment we
   could add a SLING-FILTER selector to the request, resolve that to a
   servlet and expect that to be a Filter. And if that works define that
   better as presented like this it's quite a hack ;-)
  
   -Bertrand
 
 


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

Re: Sling Request Filter filtering

[Dominik Süß]

Hi Justin,
I'm not talking about global disable because the filter often is extremely
necessary but to be able to disable it for dedicated cases. I just remember
some obscure ColumnControlFilter only checking for the Pathending colctrl
and autorewriting the node underneath. Turning off that filter would break
a lot of funcitonality but it did mess around with nodes with a specific
resourcetype, so I was missing an option to deactivate it for this very
specific resourceType.

Best regards
Dominik


On Mon, Aug 18, 2014 at 7:33 PM, Justin Edelson jus...@justinedelson.com
wrote:

 Hi,

 On Mon, Aug 18, 2014 at 1:30 PM, Dominik Süß dominik.su...@gmail.com
 wrote:
  Hi Felix,
 
  you probably remember our discussion - I checked and found out that
  resourceresolution is done with adminsession anyways and
 superTypeHierarchy
  being cached (at least from what I remember) therefore this shouldn't add
  much overhead.
 
  IMHO an important point is that it needs to be possible to add rules
  without deployment. What I have in mind is some kind of blacklisting of
  filters that by accident act in a situation where they shouldn't. In an
  ideal world a dev directly can fix that, in reallity the filter might be
  owned by a third party and cannot be directly fixed and therefore be a
  blocker.

 Assuming this is all done by service registration properties, it is
 all configurable. Just set the filter.ignore property to true. Whether
 or not this counts as a deployment is up to you I suppose :)

 Regards,
 Justin

 
  Cheers
  Dominik
 
 
  On Mon, Aug 18, 2014 at 1:06 PM, Felix Meschberger fmesc...@adobe.com
  wrote:
 
  Hi
 
  Am 18.08.2014 um 12:08 schrieb Jeff Young j...@adobe.com:
 
   Hi Felix,
  
   I think to reduce the unexpected you'd need filter.resourceType to
 match
   on the resource's supertype hierarchy too.
 
  Yeah, match could be ResourceUtil.isA(). But it should not be adding to
  much overhead for the request processing.
 
  Regards
  Felix
 
  
   Cheers,
   Jeff.
  
  
   On 18/08/2014 10:23, Felix Meschberger fmesc...@adobe.com wrote:
  
   Hi all
  
   I had various discussions around execution of Servlet API Filters in
 the
   Sling Engine.
  
   To recap: Currently all filters are always called. The
 service.ranking
   (or filter.order) service registration property can be used to define
  the
   order in which the filters are called and the filter.scope property
 is
   required to indicate at what stage in the request processing a filter
  has
   to be called. See [1] for the full story.
  
   Turns out, that it would be good to have some simple and global
 flags to
   indicate when a filter should actually be called or not. This would
 be
   similar to the filter mappings of traditional web applications, where
   filters are bound to URL paths and/or servlets.
  
   So I am proposing to introduce three new service registration
  properties,
   which may be set on Servlet Filter services handled by the Sling
 Engine:
  
   * filter.path: The Filter is only called if the path of the
current Resource (SlingHttpServletRequest.getResource)
matches any of the given paths. If the property is
not set, the filter will always be called.
   * filter.resourceType: The Filter is only called if the resourceType
of the current Resource (SlingHttpServletRequest.getResource)
matches any of the given resource types. If the property is
not set, the filter will always be called.
   * filter.ignore: The Filter is never called if this property
is set to any true.
  
  
   The implementation would be as follows:
  
   * The FilterListEntry class is augmented with a method to verify
 whether
   to call the filter at all
   * The AbstractSlingFilterChain.doFilter method is augmented to call
 this
   new method and to not call a filter for which the match fails. A
   RequestProgressTracker entry is generated for filters not called
   indicating why it has not been called.
  
   Further extensions could be:
  
   * filter.expression: some scripting expression evaluating to
 a boolean. If true the filter is called.
   * Filter service implements a new interface providing an filter
 expression method returning a boolean. If true the filter
 is called (comparable to the option servlet).
  
   Regards
   Felix
  
   [1]
 http://sling.apache.org/documentation/the-sling-engine/filters.html
  
 
 

adaptTo() 2014 getting closer

[Dominik Süß]

Hey everybody,

just with the same pace Sling is currently evolving with all contributions
and new features comming in time runs by and we're close to the 1 month
left mark for adaptTo() 2014 in Berlin.

We would be really glad to see a lot of you join us in Berlin, share
experiences, exchange knowledge and build an even stronger community.

Beside the off-the-track opportunities that you'll have a hard time to
find somewhere else we have an absolutely great schedule with great talks
from great speaker. All of them will also be available in the playground
sessions where you will get a chance to play with the code, ask questions
and/or help to improve our beloved Apache Sling.

Check the schedule at http://adapt.to/2014/en/schedule.html and get your
ticket.

If you have any questions feel free to reach out for us via i...@adaptto.org
For updates you also can follow us on twitter: @adaptTo

Best regards in the name of the whole adaptTo() orgateam
Dominik

Re: [RT] Multi Tenancy

[Dominik Süß]

Hey Stefan,

just to add my 2 cents on constraints for a tenant:
* In both cases the tenant could be identfied by one or more branches in
the repo that can be linked to exactly one tenant.
* In cases of Tenant Inheritance (as described in the Massive Multi Site
Scenario) the returned Tenant would be the most concrete Tenant but could
be identified as subtenant (e.g. /content/maintenant/subtenant  maps to
subtenant which can be identified to be anchestor of maintenant)
* Contentsharing could happen on two levels
** Inheritance (Subtenant can always access resources from anchestors or in
last resort the platform - but is most probably not allowed to write there)
** Synching/Sharing (Master-Slave or bidirectional syncing of Resources, so
content virtually lives within the tenants content)

I don't think it is a good idea to bind Resource Resolution and therefore
scripts to a tenant since I can see the issue comming that a second tenant
needs to be set up with exact the same scripts. I would define a mapping
where Applicationpaths can be mapped to a tenant and the Searchpath lookup
adds those paths dynamically to a tenant. This has the advantage that it is
possible to define tenant by tenant which applicationextension will be made
available to them.

Best regards
Dominik





On Tue, Aug 12, 2014 at 12:43 PM, Stefan Seifert sseif...@pro-vision.de
wrote:

 i created a first draft of a wiki page where i tried to collect the
 different views of and requirements for multitenancy of the recent
 discussions:
 https://cwiki.apache.org/confluence/x/So2uAg

 i coined new names for the two scenarios Virtual Hosting and Massive
 Multi Site

 we should decide first which of the requirements we can target in a first
 phase, and which are more complex or even not solvable within the current
 architecture. and - of course - what is already fulfilled by the current
 sling tenant implementation.

 my interest is currently primary in the massive multi site scenario, and
 especially the configuration part in it.

 stefan

[adaptTo] Registration Talklist

[Dominik Süß]

Hey everyone,

a little while ago we opened registration for adaptTo() 2014 (see [0]).
Because we know a lot of you love to hear a bit more about content we
published a list of the confirmed talks[1] before we finalize the schedule.
We have a broad variaty of talks so everyone should find something
interesting. But being focused on open source the sling community and
theirfore networking and collaboration. We try to make sure that you get as
much code as possible in your hands (open source) and provide you with
opportunities to sit to gether to discuss, hack and in the evening ours
have a beer together (community). We try not just to be a conference but a
meetup - so make sure you don't miss it!

I'm looking forward to seeing you in Berlin this september.

Best regards in the name of the adaptTo() organisation team,
Dominik Süß

P.S. do not hesitate to contact us in case you have any question at
i...@adaptto.org


[0] http://adapt.to/2014/register.shtml
[1] http://adapt.to/2014/schedule.shtml

Re: Triggering logic on commit of ResourceResolver

[Dominik Süß]

Hi Alex,

yet the system is based on JCR 2.x but it might migrated to Oak in time.

But anyways I wonder if this is really a good idea for this specific use
case. If I get the idea right you'd add properties in a specific namespace
to the resources to be added and process them on commit and drop them from
the persisted conten - right?

a) I'd bind to a very generic mechanism that would be added to each and
every commit and needs to check for  the properties on every commit
although I know when to fire an event upfront (only condition - commit was
successful)

b) AFAIR a later commithook can still fail and stop the commit from
happening

c) I'd abuse a persistence mechanism (although not really commited in the
end) as transport for metainformation I create on a higher level and need
to process after the commit on higher level

d) Te mechanism implies that I have direct connection between event and a
specific node that I can utilize to transportmetadata, but an event is
often connected to a bunch of changes (ok I just could abuse one of those
but this feels hacky)

e) I'm currently not sure if this would work for deletes as well, so if I
add the metadata to a deleted node I'd have this changed node in the commit
hook at all.

All in all using commit hooks seem to require a lot of deep knowledge about
Oak while the requirements are solely definable on the sling layer. Looking
at those from an API view I just need a way to conditionally fire
events/create jobs while the condition is a successful commit.

Best regards

Dominik
Am 24.06.2014 23:37 schrieb Alexander Klimetschek aklim...@adobe.com:

 Is this for a resource provider implementation that is not backed by JCR?
 Because if we are talking about JCR resources I would advocate solutions on
 the JCR repo layer, Oak has some options with commit hooks.

 Just my 2 cents,
 Alex

 On 24.06.2014, at 04:22, Dominik Süß dominik.su...@gmail.com wrote:

  Hi everyone,
 
  I'm currently doing some research to implement a feature where I need to
  integrate 3rd party systems that act as client and need to perform some
  local changes that I can trigger from the sling instance.
 
  The issue I do have is that there seems to be no proper way to transport
  the information that I do have when preparing the changes in the local
 repo
  via resourceresolver to some code that is executed after the transient
  changes have been commited.
 
  The only mechansim available is listening for the Resource events but I
  lose a lot of information. One example is removal of a node where I
 cannot
  access the values of the removed resource anymore. The remove event for a
  resource testa with attribute testb with value testc provides me the
  following information:
 
 
 event.topicsorg/apache/sling/api/resource/Resource/REMOVEDpath/content/testa
  useridadminresourceRemovedAttributes[testb, jcr:primaryType]
  Beside losing information it just feels wrong that I have to bind to the
  persisted information but cannot bind specific logic to a commit.
 
  When thinking about this a bit more I wonder why Event and JobHandling
  shouldn't have an option to only be triggered on commit. If I'd have a
 way
  to prepare events/jobs that only get fired if the commit could
 successfully
  be performed I'd have a way to transport all the metadata I need to
 trigger
  the 3rd system via EventListener/JobConsumer.
 
  My concrete usecase is about triggering securitymechanisms of multiple
  third party system based on changes persisted in a sling instance
 (synching
  accesscontrol for a highly integrated system that is not only composed of
  sling instances).
 
  I had a related requirement some years ago where a search integration did
  require some metadata about deleted resources to be able to perform a
  proper cleanup and we had to turn on jcr versioning to be able to get
 this
  data from the corresponding frozen nodes since the original nodes are
  already gone when the event is fired.
 
  Any alternative idea or opinions regarding such an extension?
 
  Best regards
  Dominik

Re: Triggering logic on commit of ResourceResolver

[Dominik Süß]

Hi Alex,

this isn't true anymore, the session.save() in the POST Servlet is
triggered through the resourceResolver.commit() [0] - and direct
session.save() should not be performed anymore - even if switching to jcr
api because you act on low level API (e.g. for versioning) you should
control commit behavior via the resourceResolver - that way you can ensure
that any changes performed in other resourceProviders will be commited as
well. I know that the majority of cases will be local JCR repositories but
just think of remote sources included via REST Interfaces or the (yet not
possible) case that two repos are mounted in one instance (e.g. to separate
/content from /apps and /libs).

The mechanism I propose is bound to resourceResolver but does not prevent
JCR API access beside the fact that session.save() would not be a complete
resourceresolver.commit (which would still have pending changes aka the
events).

Best regards

Dominik


[0]
https://github.com/apache/sling/blob/trunk/bundles/servlets/post/src/main/java/org/apache/sling/servlets/post/AbstractPostOperation.java#L129
Am 25.06.2014 21:50 schrieb Alexander Klimetschek aklim...@adobe.com:

 On 25.06.2014, at 00:27, Dominik Süß dominik.su...@gmail.com wrote:

  All in all using commit hooks seem to require a lot of deep knowledge
 about
  Oak while the requirements are solely definable on the sling layer.

 But you exclude any change through the JCR API, for example the sling post
 servlet.

 Cheers,
 Alex

Triggering logic on commit of ResourceResolver

[Dominik Süß]

Hi everyone,

I'm currently doing some research to implement a feature where I need to
integrate 3rd party systems that act as client and need to perform some
local changes that I can trigger from the sling instance.

The issue I do have is that there seems to be no proper way to transport
the information that I do have when preparing the changes in the local repo
via resourceresolver to some code that is executed after the transient
changes have been commited.

The only mechansim available is listening for the Resource events but I
lose a lot of information. One example is removal of a node where I cannot
access the values of the removed resource anymore. The remove event for a
resource testa with attribute testb with value testc provides me the
following information:

event.topicsorg/apache/sling/api/resource/Resource/REMOVEDpath/content/testa
useridadminresourceRemovedAttributes[testb, jcr:primaryType]
Beside losing information it just feels wrong that I have to bind to the
persisted information but cannot bind specific logic to a commit.

When thinking about this a bit more I wonder why Event and JobHandling
shouldn't have an option to only be triggered on commit. If I'd have a way
to prepare events/jobs that only get fired if the commit could successfully
be performed I'd have a way to transport all the metadata I need to trigger
the 3rd system via EventListener/JobConsumer.

My concrete usecase is about triggering securitymechanisms of multiple
third party system based on changes persisted in a sling instance (synching
accesscontrol for a highly integrated system that is not only composed of
sling instances).

I had a related requirement some years ago where a search integration did
require some metadata about deleted resources to be able to perform a
proper cleanup and we had to turn on jcr versioning to be able to get this
data from the corresponding frozen nodes since the original nodes are
already gone when the event is fired.

Any alternative idea or opinions regarding such an extension?

Best regards
Dominik

Category for www.apache.org listing

[Dominik Süß]

Hi everyone,

last week I wanted to check about the state of the various webframeworks of
Apache. To get an idea which frameworks are available I visited
www.apache.org and opened the Index by Category and couldn't find Sling
with all the other webframworks - even worse, I couldn't find it at all
since it has no category assigned at all, it just can be found in the
alphabetical listing or by language.

Then I checked the various frameworks and their most recent releases to get
an idea about the activity. Again Sling has no release at all listed which
makes it hard to get an idea if the project is active at all.

It would be great if
a) at least the web-framework category could be assigned to Apache Sling
b) the most relevant releases would be maintained like engine and sling api
or the parent project

Thanks  best regards
Dominik

Re: [featureflags] Readding sling:features to resourceResolver

[Dominik Süß]

Hi,

I would second the idea of Mike to implement featureflags on the
technological base of a ResourceAccessGate but hiding it away. From a pure
execution perspective it does exactly what is required.

Regarding Performance I think this handling can be implemented in a cheap
way while achiving the same via ACLs (as it was done for a long time) is
much more expensive. It would probably be an option to define pathpatterns
that won't be checked at all, since content created at runtime would most
certainly not contain feature flags but there might be cases where you
would like to define certain areas that need to be checked anyways. As for
filters there need to be patterns to skip a check as early and cheap as
possible.

Comming back to the CRUD operations I do not really get the problem here,
the problems are exactly the same as existing for ACL protected resources.
We do even have an advantage here since we can utilize service users for
dedicated visibility for processing and check existance of a resource via
services without the need of a separate admin session to gracefully handle
conflicts.

Could someone please describe the scenario where a featureflag would be
problematic in therms of create update or delete? I assume that the
existing patterns to deal with the corresponding issues in ACL protected
scenarios could be adapted and used as well. We could even decide to
provide more information about why that fails when we decide that feature
flag control is not to be handled as strict as ACLs (since no security
feature).

Best regards
Dominik


On Fri, Jun 13, 2014 at 12:10 AM, Carsten Ziegeler cziege...@apache.org
wrote:

 In general I see two problems, one is performance and the other one is how
 to deal with CRUD operations wrt to feature flags on a resource. The latter
 point was the main trigger to pull this off.
 I think we should go back to talk about use cases.

 The number one use case I know in this area is displaying/hiding a button
 in a navigation - this can really easily be done in the navigation
 component itself when rendering: the resource has a specific property which
 is checked. If it contains a feature name this is compared with the active
 feature and then either this item is included or not. We could suggest a
 common name for the property and we could also come up with a filter
 utility class, so for code doing this it will be a short one liner.
 I don't want to add a heavy unclear concept into the resource resolver just
 for such a use case.

 Regards
 Carsten


 2014-06-12 2:55 GMT-04:00 Mike Müller mike...@mysign.ch:

  Hi
 
  Just my 2 cents to it:
  Why not defining a featureflag-interface which is internally
 implemented
  with ResourceAccessGates. Personally I think ResourceAccessGates could do
  the job but I can follow the fear, that such a mechanism mixing up with a
  security mechanism could lead to bad design. So the solution could really
  be to wrap the ResourceAccessGates for the functionality of featureflags.
 
  Best regards
  mike
 
   -Original Message-
   From: Dominik Süß [mailto:dominik.su...@gmail.com]
   Sent: Tuesday, June 10, 2014 2:53 PM
   To: dev
   Subject: [featureflags] Readding sling:features to resourceResolver
  
   Hi everyone,
  
   although I know this touches an area with a lot of emotions involved I
   wanted to reopen the discussion around Featureflags support for the
   resourceresolver.
   The last thing that happend was removing it for a release due to
   potential
   confusion and subtle issues. See
  http://markmail.org/thread/jgpso52iqiivpa5t
  
   Here are my arguments why I think it would be good to readd it to the
   resourceResolver (or any other mechanism being able to filter the
  resource
   tree:
   - Currently writing frontend that needs to adapt to featureflags
 requires
   adding custom code to check and filter the ui to be rendered. This
 leads
  to
   a lot of boilerplate code written over and over again with minor
  differences
   - Mechanisms relying on the Default Get Servlet JSON output would need
 to
   implement the filterlogic in clientside code.
   - ACL based solutions complicate the security setup for administrators
   because each feature would require a group (if toggling should be
 achived
   by membership instead of complex permissionrewriting) and could
  potentially
   impact performance of acl checks (not my domain so some specialists
 might
   be able to tell if those additional groups and memberships have impact
 on
   performance)
  
   The argument that developers might mistake feature flags with security
 is
   indicating that they don't read documentation (where potential security
   warnings should be written down in a prominent location) or do not
 care.
   But who does not care will not take care of proper ACLs anyways and
   assuming developers are using features without reading or respecting
   warnings in the documentation sounds a bit paranoid.
  
   I still think Resource Access Gate

Re: [featureflags] Readding sling:features to resourceResolver

[Dominik Süß]

Hi Betrand,

I fear it is not as easy since this mandates rendering engines to be able
to perform that filtering (in other words - to be able to skip rendering
based on the feature flag) or we would require developers to utilize
filters which are way more intrusive then a Resource Access Gate and could
potentially do much more harm. Additionally this code needs to be applied
to each consumer. This might not be that much work if applying features in
the first place, but just think of a solution like AEM where a huge
codebase should be featurized (e.g. a part should be deactivable due to
licencing or some other criteria): each and every part of the application
depending on a contentstructure would need to learn this new concept
instead of filtering the resourcetree in first place.

If I got the idea of featureflags right they should be at least invasive in
code as possible, keeping the risk low that a deactivated feature by
accident influences the rest of the system at all.

From a consumers perspective I would like to be able to declare resources
to be part of a feature (whitelisting) and probably to be removed for a
feature (blacklisting - although this requires a logic resolving potential
theoretical conflicts with a whitelist) by adding attributes. This
attribute check must be implemented in a cheap way (not much more then
already done during resource resolution process).

Best regards
Dominik


On Mon, Jun 16, 2014 at 9:58 AM, Bertrand Delacretaz bdelacre...@apache.org
 wrote:

 Hi,

 On Tue, Jun 10, 2014 at 2:53 PM, Dominik Süß dominik.su...@gmail.com
 wrote:
  -... Currently writing frontend that needs to adapt to featureflags
 requires
  adding custom code to check and filter the ui to be rendered. This leads
 to
  a lot of boilerplate code written over and over again with minor
 differences...

 Can't that be solved by a utility library? Maybe with minimal changes
 to the Sling core, but without baking feature flags into the core.

 -Bertrand

Re: [featureflags] Readding sling:features to resourceResolver

[Dominik Süß]

Hi Bertrand,

I'm not really about altering resource rendering but enable disable
resources for rendering, so I probably wouldn't decorate the scripts and
servlets but the resources that define those resourceTypes. This is what we
all have done a lot when hiding away frontend for endusers (at least I know
nobody who didn't have to do that once in a while) via ACLs wherever the UI
was composed from resources.

I get the case where you would like to alter the Script/Servlet that
handles a resourceType but as you mentioned this comes with quite some
constraints and locations that would require some changes to work. To get
this working we would definitively need some script metadata which could
also be added as annotation to be able to distinct on servletresolution.

I do not like the term magic feature flags since it implies there would
happen something out of control for a developert. Declarative feature
flags is matching what I'm thinking of - declaring something being part of
a feature and having a unified behavior of the system to handle these for
the specific cases just as we have a declarative way of defining
selectorbased filtering for scripts and/or servlets (declaration syntax is
different but declaration and behavior of the system is always the same.

IMHO we should go for the simplest mechanism first - which is the
endresource being declared being part of a specific feature and carefully
checking the lower level mechanisms for alter resource rendering. It still
is better to have an easy and cheap solution that covers the easy cases but
requires some engineering where more complex scenarios come into the game
then forcing people to write custom code everywhere even for such common
cases like disabling a Tab in a ui.

Best regards
Dominik



On Mon, Jun 16, 2014 at 3:13 PM, Bertrand Delacretaz bdelacre...@apache.org
 wrote:

 Hi Dominik,

 On Mon, Jun 16, 2014 at 1:55 PM, Dominik Süß dominik.su...@gmail.com
 wrote:
  ...I fear it is not as easy since this mandates rendering engines to be
 able
  to perform that filtering (in other words - to be able to skip rendering
  based on the feature flag)...

 so IIUC you're looking at the alter resource rendering use case of [1] ?

 Note that even if the resource resolver hides rendering resources like
 scripts, I suspect you'll get in trouble as rendering scripts are
 cached. That's a good example of why I pushed for the SLING-3483
 removal.

  ...This might not be that much work if applying features in
  the first place, but just think of a solution like AEM where a huge
  codebase should be featurized (e.g. a part should be deactivable due to
  licencing or some other criteria)...

 I sense a slightly more complex use case than [1] here...not sure if
 in-content feature flags are the right way to implement this.

 ... If I got the idea of featureflags right they should be at least
 invasive in
  code as possible, keeping the risk low that a deactivated feature by
  accident influences the rest of the system at all

 aka magic feature flags ;-)

 I agree that this looks nice, but as mentioned before I'm wary of
 multiple weird side effects like the caching thing mentioned above.
 We've seen those coming before SLING-3483, and so far no one has been
 able to reassure me that we're not opening a can of worms.

  ...From a consumers perspective I would like to be able to declare
 resources
  to be part of a feature (whitelisting) and probably to be removed for a
  feature (blacklisting - although this requires a logic resolving
 potential
  theoretical conflicts with a whitelist) by adding attributes...

 Assuming you want to work like this for scripts, how to you handle
 rendering servlets?

 -Bertrand

 [1]
 https://cwiki.apache.org/confluence/display/SLING/Sling+Feature+Flags+support

 P.S. no emotions about this on my side...I'm just not convinced so
 far, and wary of possible side effects. Best way to convince me is
 probably a prototype with sufficiently good tests that prove me wrong.

[featureflags] Readding sling:features to resourceResolver

[Dominik Süß]

Hi everyone,

although I know this touches an area with a lot of emotions involved I
wanted to reopen the discussion around Featureflags support for the
resourceresolver.
The last thing that happend was removing it for a release due to  potential
confusion and subtle issues. See http://markmail.org/thread/jgpso52iqiivpa5t

Here are my arguments why I think it would be good to readd it to the
resourceResolver (or any other mechanism being able to filter the resource
tree:
- Currently writing frontend that needs to adapt to featureflags requires
adding custom code to check and filter the ui to be rendered. This leads to
a lot of boilerplate code written over and over again with minor differences
- Mechanisms relying on the Default Get Servlet JSON output would need to
implement the filterlogic in clientside code.
- ACL based solutions complicate the security setup for administrators
because each feature would require a group (if toggling should be achived
by membership instead of complex permissionrewriting) and could potentially
impact performance of acl checks (not my domain so some specialists might
be able to tell if those additional groups and memberships have impact on
performance)

The argument that developers might mistake feature flags with security is
indicating that they don't read documentation (where potential security
warnings should be written down in a prominent location) or do not care.
But who does not care will not take care of proper ACLs anyways and
assuming developers are using features without reading or respecting
warnings in the documentation sounds a bit paranoid.

I still think Resource Access Gate might be viable but some people
convinced me that solving such a mechanism with a security mechanism would
probably make distinction between security and business based access
constraints (such as featureflags that constraint the access to a feature).

Let's discuss this a bit so that everyone gets a clearer picture what
issues where faced and why it was a better idea to remove this featureflag
support and what would be the conditions under which no one would have an
issue with readding a revamped featueflag support for the resource tree.

Best regards
Dominik

Re: adaptTo() 2014 - Call for Papers

[Dominik Süß]

Hi everyone,

although we really got a bunch of great submissions yet we're still
accepting further submissions for adaptTo() 2014. It doesn't matter if you
got a field report, a generic conceptual talk or want to present a sling
based solution, any idea realated directly or indirectly to Apache Sling is
welcome for submission and we'll try to help you forming a session that the
others will enjoy and learn from it. The most promissing submissions will
then be accepted for adaptTo() 2014 so you will have some time to prepare
your session.

For the sake of completeness:
- Speakers get free entrance and a fancy speaker shirt ;)

Best regards
Dominik


On Thu, Apr 3, 2014 at 10:52 AM, Dominik Süß dominik.su...@gmail.comwrote:

 Hey everyone,

 altough we already got some really great submissions in the last days we
 want to encourage you to send in your submissions as soon as possible. That
 way we can finalize the schedule early, give proper feedback about the
 proposals and grant the verified speakers their slot early so you'd have
 enough time to prepare your talk.

 Don't hesitate to contact us if you just have a rough idea and need some
 feedback how you could wrap this topic into a 45 min session.

 For proposals use pap...@adaptto.org. For general questions you can send
 us a mail via i...@adaptto.org

 Don't forget to revisit http://adaptto.org once in a while for updates
 and/or follow @adaptto in Twitter to make sure you hear about all important
 news about adaptTo() 2014.

 I'm looking forward to getting all your great submissions ;)

 Best regards
 Dominik


 On Tue, Mar 25, 2014 at 11:36 AM, Peter Mannel-Wiedemann 
 pman...@pro-vision.de wrote:

 Hi everyone,

 time flies! After three great years, there'll also be a 2014 edition of
 adaptTo() in Berlin.
 We just opened our Call for Papers, so feel free to send your ideas to
 pap...@adaptto.org.
 For those who do not know about adaptTo() yet: it is a non-profit
 conference around Apache Sling and the connected Frameworks such as Apache
 Felix and Apache Jackrabbit.
 The conference is hosted by pro!vision GmbH and sponsored by Adobe
 Systems, with great support of many ASF members participating as speakers
 and driving the community around this great open source project further.
 So have a look at all the details about the Call for Papers at
 http://www.adaptto.org and send yours!
 I'm looking forward to seeing you in Berlin.

 Best regards, Dominik  Peter

 pro!vision GmbH
 Wilmersdorfer Str. 50/51
 10627 Berlin
 Telefon +49 (30) 818 828-710
 mailto:pman...@pro-vision.de
 http://www.pro-vision.de

 Geschäftsführer: Karim Khan, Stefan Seifert
 Sitz der Gesellschaft: Berlin
 AG Charlottenburg, HRB78141, USt-IdNr. DE209954974

Re: SLING-3203 - rejecting POST/delete if any selector, extension or suffix?

[Dominik Süß]

I just checked the RFC for statuscodes and 403 seems appropriate while 409
seems to be wrong.
Although you could argue the user can resolve the conflict by changing the
URI the new URI has a new target (since the URI does not know about
concepts like selectors or suffixes) and therefore is a different request
(the versioning example indicates that the intention is a conflict created
by the payload). IMHO 403 would be good and could return an info what
exactly was wrong with the request (like Found suffix [extension |
selectors] for POST request).

Regards,
Dominik


On Wed, Jan 22, 2014 at 10:34 AM, Bertrand Delacretaz 
bdelacre...@apache.org wrote:

 On Wed, Jan 22, 2014 at 9:58 AM, Felix Meschberger fmesc...@adobe.com
 wrote:
  ...I am not sure about the 404 response. How about 409/CONFLICT or
 403/FORBIDDEN ?

 403/FORBIDDEN sounds good, will do that.

 
  Finally: Lets consider not allowing selector, extension, and suffix on
 all requests handled by the SlingPostServlet ?

 That's a different topic.
 -Bertrand

Re: Reconsidering when to apply resource access security

[Dominik Süß]

+1


On Mon, Jan 13, 2014 at 2:24 PM, Carsten Ziegeler cziege...@apache.orgwrote:

 Hi,

 after long discussions we have to the compromise to tag a resource provider
 if a (optionally) available resource access security is used for this
 provider.

 I think this was a wrong compromise with no real value - and we should
 remove this additional flag and simply always apply the checks.
 One main driver is the new feature flags implementation which requires the
 additional checks for all providers to properly work - and it would be a
 maintenance nightmare to enable the flag on all providers (default is off).

 So, if no one complains with a good reason I'll do the change

 Thanks
 Carsten
 --
 Carsten Ziegeler
 cziege...@apache.org

Re: Setting the sling.core.current.servletName request attribute

[Dominik Süß]

I'm not sure what I think of that change due to the following points:
- Filters might override getAttribute and therefore could (at least
theoretically) break currently working functionality (code which would not
be harmful atm)
- All usecases I can imagine here are about introspection of what script
was used here (since changing wouldn't make sense at all as it does not
influence ContentData at all).

IMHO it would make more sense to add an introspectionservice which exposes
some information from ContentData/RequestData for pure consumtion (e.g.
logging/measuring). This Service could take a request and (since being part
of the core bundle) can read dedicated data from those internal objects and
return the values in a human readable String representation.

WDYT?
Dominik

P.S. I know the goal should always be not to have the API leak
Implementation details but for introspection cases it might make sense to
at least provide a hook to get meaningfull textual dumps of this kind of
information.


On Wed, Jan 8, 2014 at 1:06 AM, Alexander Klimetschek aklim...@adobe.comwrote:

 On 07.01.2014, at 11:19, Felix Meschberger fmesc...@adobe.com wrote:

  The Sling Engine sets the sling.core.current.servletName request
 attribute to the name of the Servlet (absolut path in case of Scripts)
 before calling the servlet or script. In essence this means tha the name of
 the servlet/script to be called is not available to the filters executed
 before calling the script.
 
  What about if me move setting the property to immediately before calling
 any filters (and resetting it after returning from all filter and script
 processing) ? Would that break existing functionality ?

 I don't know any code using that attribute but thinking about it:

 It could only be an issue, if a filter relies on the fact that the servlet
 name is NOT set (which would then always be the case atm, so it's not
 really something where any meaningful logic could be behind).

 Or if the filter relies that it is from the previously executed servlet
 (i.e. one that did an include or forward). Not sure if that is feasible...

 Finally, in our product code (Adobe CQ) I did not find a usage.

 So I would tend to say it's not a problem. It seems useful to make this
 available to servlet filters that can do some aspect oriented handling
 here, to e.g. process rendering resolution insights.

 OTOH, we already have the request progress tracker, might also make sense
 to make individual entries more programmatically accessible.

 Cheers,
 Alex

Re: [Happy new year] A new year with Sling (2013 Recap and a whishlist for 2014)

[Dominik Süß]

Hi Bertrand,


On Wed, Jan 8, 2014 at 10:53 AM, Bertrand Delacretaz bdelacre...@apache.org
 wrote:


 On Wed, Jan 1, 2014 at 11:27 PM, Dominik Süß dominik.su...@gmail.com
 wrote:



  ...DevOps optimization: this includes setup, patching, monitoring and
  scalling of installations...

 I also think this is the next big topic to tackle for Sling. I have a
 number of (somewhat wild) ideas about this, hoping to get some interns
 to work on experiments in that area in 2014. I'm in favor of not going
 too far inside Sling with this, and taking a systems approach to
 configuration and upgrades management to separate concerns and keep
 Sling lean and mean.

I agree that Sling should not force into a specific direction, but it might
be that there are repeating patterns where some global/Sling provided
(optional) tooling might be a good choice.


  ...Subtopic Deployments: It is still not clear how to package deployments
  the right way, although various mechanisms are available it seems like
  there still is room for optimization...

 Not sure what you mean by this but the devops work can also help here
 - I'm thinking in particular of letting Git or other repositories
 drive the configuration of Sling instances, as recently discussed.

I was thinking of application deployments. Sling currently is based on
bundles with the initial-content or installing it from the repo from
install folders. In Adobe CQ Packages (vlt - contributed to Apache some
months ago) are the mechanism to package deployments. So there are multiple
ways to organize deployments. Bug e.g. all are tight to a JCR Repository as
soon as it comes to content (since there is no generic equivalent to the
JCR Installer). what doesn't feel right is that the prefered way of
deployment in a Sling based app as Adobe CQ is different from how Sling is
doing deployments with the own parts or demo apps (creating a uncessessary
learning barrier).


  ...POST Servlet: this is an area that I have on my list since last year
 and
  where I started to work on a proposal for a new version that hopefully
 can
  be a base for something  that replaces the old POST Servlet and reduces
 the
  need for implementing custom Servlets as much as possible...

 I like this, the challenge here IMO is keeping things backwards
 compatible, so the starting point is to make sure the current code has
 full test coverage.

I'm still playing around with this. keeping everything backwards compatible
does create some constraints. I thought about implementing a completely new
one (cherrypicking the good parts of the old servlet) and keeping the old
one to delegate there where the new one isn't configured. Since one goal is
to be able  configure where this servlet should act this delegation might
be the way to keep backwards compatibility.



  ...Feature Flags: although the Feature of Features seams close to be
 ready
  as first draft there is a lot of work left...

 Agreed, at this point we need small reversible steps in this
 direction, to help converge on the use cases and how we implement them
 as this is very new territory for most of us. The devops systems
 approach can also play a role here, as turning a feature on or off can
 in some cases be implemented by routing incoming requests to different
 Sling instances.

+1 - this is something where reality will bring in a lot of necessary
changes I think.


  ...Documentation...

 I already replied to that one in this thread, I'm still a big fan of
 readable tests as the ultimate reference documentation, and keeping
 written documentation at the overview level to make it sustainable and
 accurate. Yet, we have a long way to go here. As a simple thing were
 any community member can help, we still have too many old pages under
 http://svn.apache.org/repos/asf/sling/site/trunk/content/site/ that
 need to be cleaned up as per my comment  04/Apr/13 12:28 in
 SLING-2002.

Good inline documentation is really good to understand why things behave as
they behave, But you need some guidance when starting with a new
technology. I think there is also some room to flatten this initial
learning curve by having some documentation/tutorials and/or guided
demoprojects.


 Apart from all that my wish for 2014 is that we can get more people
 involved in Sling who are not using CQ, to keep the diversity. Not
 only in terms of company influences (I think we're doing ok despite a
 majority of Adobe/CQ related community members) but above all in terms
 of a diverse set of use cases that help make Sling better by bringing
 in different views.


Big +1 on this one.

Best regards
Dominik

[Happy new year] A new year with Sling (2013 Recap and a whishlist for 2014)

[Dominik Süß]

First of all - Happy new year to all of you from my side :)

The last days I had the chance to think a bit abou what happend in the last
year and what I expect and/or wish for the next year. Since I feel
pretty connected to Apache Sling this also did involve thinking about the
project from my personal point of view. I'm sharing those thoughts since
I do hope to hear your point of view as well and we can push Sling even
further as community.

The year 2013
-
At adaptTo() 2013 Mike and Carsten already did summarize the major
technical changes that where adressed until then. By revisiting the
releases of last year it looks to me Sling made a big step forward
improving in various areas like administration/maintenance (e.g.
healthcheck and JMX improvements, Backlog integration),  interoperability
(e.g. full CRUD support, Oak Support, Cassandra ResourceResolver, Access
Gates) as well as a lot of little but important updates of the existing
functionality.
Especially in the last two months there is a lot of movement in the
community and a lot of discussions are still open. This kind of
constructive discussion with partially opposing opinions as well as even
concurrent implementationproposals are in my eyes a sign of a vivid
community.

2014 - a whishlist
--
This is not a real whishlist but a list of topics that where recently
discussed and some arguments why I personally think it might be worth to
invest some time:
- DevOps optimization: this includes setup, patching, monitoring and
scalling of installations. Ian did start a corresponding thread in November
and I hope this discussion will be pickedup to really fulfill the promise
of a horizontally scallable solution not just on paper but in an
administrable way (addressing secondary items like timing issues for
deployments)
- Subtopic Deployments: It is still not clear how to package deployments
the right way, although various mechanisms are available it seems like
there still is room for optimization
- POST Servlet: this is an area that I have on my list since last year and
where I started to work on a proposal for a new version that hopefully can
be a base for something  that replaces the old POST Servlet and reduces the
need for implementing custom Servlets as much as possible
- Feature Flags: although the Feature of Features seams close to be ready
as first draft there is a lot of work left. One thing not discussed yet is
the usage of featureflags for functionality of Sling itself (tailoring
sling instances to the real needs by deactivating all unused features).
- Multi-Tenant Applications: Although the tenant API does help to implement
multi tenant applications there is still some unleashed potential. E.g. I
am thinking of tenantspecific applicationextentions (might be possible that
featureflags could help here).
- Documentation: This is nothing new and although it recently wasn't topic
on the mailinglist this topic gets more and more important. Everytime I try
to onboard a new dev on Slingbased projects I realize there is more and
more of functionality and it gets harder and harder to teach  all relevant
information without having the dev lost in the middle. The golden goal
would be a book covering all the stable parts of sling. IMHO it is
essential for the success of Sling in the next years to flatten the
learningcurve.

This list ist far from complete but those are the topics that I did think
about when thinking about last year. All in all I think the Sling Community
is in a great condition and I can't wait to see more solutions on top of
Apache Sling.

So in the end there is the questions:
What are the topics you think need more/most attention of the community?

Best regards
Dominik

Re: [ResourceAccessSecurity] Returns NonExistingResource if acess is denied

[Dominik Süß]

+0.5

I'm aware of this contract but just did check when the NonExistingResource
would be valid to be used.
Looking at [0] you could read this to be a correct behavior as well. There
is currently a gap between the behavior of .resolve() and .getResource()
where getResource would return null and .resolve() should return a
NonExistingResource. I'm pretty sure there is a reason for that, but I
couldn't find it. So could anyone enlighten me befor I can give full +1
from my side? :)

Best regards
Dominik

[0]
http://sling.apache.org/apidocs/sling5/org/apache/sling/api/resource/Resource.html#RESOURCE_TYPE_NON_EXISTING


On Mon, Dec 16, 2013 at 11:54 AM, Felix Meschberger fmesc...@adobe.comwrote:

 Hi

 Are you talking about ResourceAccessSecurityImpl.getReadableResource ?
 Yes, I agree, that returning NonExistingResource is indeed violating the
 API spec which states null is to be returned if the resource is not
 readable.

 Regards
 Felix

 Am 16.12.2013 um 08:00 schrieb Carsten Ziegeler cziege...@apache.org:

  Hi,
 
  while looking at the ResourceAccessSecurity implementation I noticed that
  it returns a NonExistingResource if read access is denied. I think it
  simply should return null.
 
  Thoughts?
 
  Regards
  Carsten
  --
  Carsten Ziegeler
  cziege...@apache.org

Re: [ResourceAccessSecurity] Returns NonExistingResource if acess is denied

[Dominik Süß]

Ah ok thanks, wasn't really sure about that due to the alternative resolve
signature with request but I should have read the classdescription which is
pretty clear.

So +1 from my side as well.

Best regards
Dominik
Am 16.12.2013 21:38 schrieb Alexander Klimetschek aklim...@adobe.com:

 On 16.12.2013, at 04:38, Dominik Süß dominik.su...@gmail.com wrote:

  There is currently a gap between the behavior of .resolve() and
 .getResource()
  where getResource would return null and .resolve() should return a
  NonExistingResource. I'm pretty sure there is a reason for that, but I
  couldn't find it.

 Oh, yes, there is a good reason for that:

 - resolve() is used for request processing, where it is necessary to
 handle the non-existing case with the special sling:nonexisting resource
 type and the original path info
 - getResource() is the more raw access, similar to JCR Session.getNode()
 (*)

 Applications would always use getResource() and handle the null check.
 resolve() is mostly only for the sling engine, or if you have some more
 complex internal forwarding etc. that requires to replicate Sling's
 resolution behavior.

 (*) yes, getNode() throws an exception, but that's similar to returning
 null compared to returning a special NonExistingResource object

 Cheers,
 Alex

Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)

[Dominik Süß]

Hi Henry,

the way understand Feature Flags as well as the comment from Roy is quite
different:
- Features can be content, java code, configuration or anything else that
you would touch to introduce a new feature
- Therefore the when a feature is turned off ist must be granted that (as
far as technically possible) the feature has no impact on the behavior of
the system (this might not be achivable since the only way of total removal
of impact is not to release it, but the goal is to get as close as possible
to this state)
- Pure highlevel application checks cannot accomplish this since the
plattform API would anyway call different logic and has to rely on the high
level API to produce the same result (e.g. the resolutionprocess would be
different between (a) the feature not being present at all (since there is
no resource found) (b) the feature is disabled and a third logic (like a
filter) needs to take care of this.

I read Roy's comment that this is something required, but there is even
more than that, like configuration which needs to be taken into account.
But when looking at the area of resource resolving filtering the
resourcetree in first place is as close as we can get to a similar behavior
like non-existance.

Best regards
Dominik

P.S. Isolation of JS logic isn't that hard, you just make sure that all
plugins of a feature are included as one JS file. The hard part is request
optimization where you might want to aggregate the plugins.  This might be
achivable by aggregations that have generated featurehashes in their  URL
(this way all users consuming the same featureset get the same aggregation
so you still can cache).


On Mon, Nov 18, 2013 at 11:43 PM, Henry Saginor hsagi...@gmail.com wrote:

 This is what I derive from your Roy's comments.

 It is not possible to predict all of the changes that might be conditioned
 via a flag. The context is really up to the application developers and
 their requirements.
 Applying feature flags at the resource level would only cover a particular
 set of changes.
 So, fundamentally all that the framework can do is provide a way to define
 flags, provide a switch panel and a way to extend it, and API to check
 flags in condition statements.
 How and where each flag is used is up to the developer of a specific
 application feature.

 Also, API for flag checking needs to be made available on both client and
 server without them calling each other. This can get tricky when we
 consider caching.

 On Nov 15, 2013, at 6:00 PM, Roy T. Fielding field...@gbiv.com wrote:

  On Nov 15, 2013, at 2:54 PM, Alexander Klimetschek wrote:
  On 15.11.2013, at 07:13, Amit.. Gupta. amitg...@adobe.com wrote:
 
  You are right, we can temporarily enable feature. But, as we advocate
 more and more use of ResourceResolver api instead of underlying content
 storage. There could be cases where even editors/tools used in
 development/installers are using the resourceResolver api and never see the
 resource.
  Like exporting some content package to be deployed to another sling
 instance, but package exporter use resouceResolver api and never see the
 resource.
 
  Ack. IMO feature flags are clearly a high-level application, not
 infrastructure, aspect.
 
  Feature flags are a mechanism for isolating changes within a deployed
  system.  Any part of that system.
 
  That means a feature flag needs to be able to condition any change
  that might be made to a system, including any change to the configuration
  files/data, any change to code monitoring the system, any change to the
  selection of data sources, any change to content (including everything
  as content), any change to a layout within any page or component, any
  change to the order in which things are done, any change to a report
  about what was done, and any change I haven't mentioned yet short of
  physically walking up to the server rack and unplugging the power
  by hand.
 
  In short, if it is content, it can be made conditional on the basis
  of a feature flag.  That is the granularity of feature flag use.
 
  Separate from that is the feature flag flip switch (i.e., the set
  of ways that a given feature can be turned on) and the extent to
  which a feature becomes sticky per user once enabled for that user.
 
  You should expect a typical deployed site to have on the order of
  1024 active feature flags.  Hence, think carefully before choosing
  a verbose (or linear) mechanism for checking or remembering flags.
  Likewise, you should expect to have both a global setting for each
  flag and a per-user mask, and the person running the flip switch
  control panel needs to be able to choose from
 
   a) off for all users
   b) off for unassigned users
   c) proportional assignment to on (X out of N users, max M)
   d) logical (custom code) assignment to on
   e) on for unassigned users
   f) on for all users
 
  and be able to remember assignments per user, without requiring
  the user to login, and without assigning more 

Re: FYI: feature flags prototype

[Dominik Süß]

Hi Bertrand,

sure you could deliver a synthetic resource, but anyways you would have
this resource in Resource.listChildren() - this is why I said that you then
would need to make sure all your application code is aware of this
possibility. The idea to keep the core free from additional code was the
reason why I did think of access gates as an already existing hook that
provides matching functionallity (filtering the resourcetree based on
codable accessrules).

I still think it is important to have such support since most features
coded in sling are content(/resource)-driven so a switch that just acts
in the javacode will in my eyes not be sufficient to be usable. (I just had
such a scenario in a project where we had a really hard time to setup the
corresponding ACLs to activate and deactivate the feature by
groupmemberships)

Best regards
Dominik




On Fri, Nov 15, 2013 at 9:27 AM, Bertrand Delacretaz bdelacre...@apache.org
 wrote:

 On Fri, Nov 15, 2013 at 7:51 AM, Dominik Süß dominik.su...@gmail.com
 wrote:
  Am 14.11.2013 23:11 schrieb Alexander Klimetschek aklim...@adobe.com
 :
  ...And the ResourceDecorator can't filter out things?
 
  No, returning null skips tehe decoration and returns the original
 resource.
  You could hide properties but you'd additionally have to handle such
  resources in applicationcode...

 Yes, the ResourceDecorator can supply a synthetic resource with a
 resource type that points to a do-nothing renderer.

 The more we discuss this, the more I feel we don't need more than
 something along the lines of my prototype, in the Sling core.

 Additional modules like a specialized access gate or resource
 decorators in contrib are fine, but I'd like to keep the changes
 minimal in core, as people will need time to figure exactly where and
 how this is useful.

 -Bertrand

Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)

[Dominik Süß]

Hi Amit,
maybe I haven't understood the idea of FeatureFlags right, but isn't this
exactly what this is about. The system should behave if it wouldn't be
there at all. The basic idea is that you don't have to branch it away
during development so you can ship it in a non-productionready or non QEed
state and turn it on without deployment (maybe just to a smaler audience or
in the beta env). Therefore I would expect this to be completely hidden as
it would like when being protected through ACLs.

Cheers
Dominik


On Fri, Nov 15, 2013 at 2:11 PM, Amit.. Gupta. amitg...@adobe.com wrote:

 So, finally, I agree that baking the feature flag support directly into
 the ResourceResolver implementation is suboptimal, it is probably still the
 most comprehensive and complete solution to the requirements. And I cannot
 conceive plugin hooks (at this point) to define such that we can do feature
 flag plugins.

 I think that we should not put it directly into ResourceResolver, because
 if resourceResolver does not give me a resource if feature is disabled,
 Resource will stop existing for me. There will be no way to access that
 resource using ResourceResolver api i.e. let's say I want to remove
 sling:feature attribute from that resource, I can't do that.
 ResourceResolverDecorator should be the way to go (implementation could be
 restricted i.e. queryResources not supported), additionally providing a
 servlet filter as Alex suggested.

 Thanks,
 Amit

 -Original Message-
 From: Felix Meschberger [mailto:fmesc...@adobe.com]
 Sent: 15 November 2013 13:11
 To: dev@sling.apache.org
 Subject: [OT] Feature flag influence on Resource access (Was: FYI: feature
 flags prototype)

 Hi

 TL;DR: Long discussion on why I think Feature flag support should
 currently be baked into the ResourceResolver implementation.

 I am forking of this discussion now to step back a bit and really look
 into what we expect from Feature flag support in the ResourceResolver. I go
 by the main resource access or methods there, so:

 * resolve() - Resource
 Calculates a virtual list of resource candidates and returns the first
 one. Applying feature flags, it might not return the first one.
 Another level of features could be applied to supporting feature flags in
 the /etc/map mappings leading to the list of candidate resources.

 * map - String
 The input path is first converted into a resource, which may have a
 feature flag applied.
 In addition to applying a feature flag to the resource which is finally
 mapped the /etc/map mappings can also be filtered with feature flags.

 * getResource() - Resource
 For absolute path its a single yes/no question: Is the resource visible or
 not according to the feature flag.
 For relative paths its not as simple since the ResourceResolver iterates
 the search path looking for a resource. So each canidate is looked at and
 has to have its feature flag inspected. (feature flags of ancestors are
 ignored; only feature flags in the candidate resource itself are
 considered; so no feature flag inheritance down the tree)

 * getParentResource() - Resource
 This is not an interesting case because it accesses the parent resource
 using the absolute path and we would not expect to get null here (except if
 the argument resource is the root resource).

 * listChildren - IteratorResource
 * getChildren - IterableResource
 * queryResources - IteratorMapString,Object
 * findResources - IteratorResource
 Simple case here: We just exclude child resources whose feature flag
 refers to a disabled feature.

 What options do we have ?

 * ResourceResolverDecorator (to be specced/implemented): Will have to do
 extra work getResource to iterate the search path for relative resources to
 consider the feature flag - might optimize by only iterating if the actual
 getResource method returns a resource with a disabled feature flag.
 IteratorResource can simply be decorated, too. queryResources is harder
 again because this might contain results from queries which should not be
 included according to the feature flag (so each entry would have to be
 inspected, if at all possible). Also: A ResourceDecorator cannot properly
 handle feature flags in /etc/map mappings at all and also support feature
 flags on resolveResource is probably hard to implement because the list of
 canidate resources is influence by /etc/map mappings so a decorator would
 have to replicate that work.

 * ResourceAccessGate: This is not leveraged by all ResourceProviders and
 we expressely leave it to these services to indicate the use of a gate.
 Defining Feature flag support to have all ResourceProviders require to
 leverage ResourceAccessGate sounds contradictionary. Also, while a case can
 be made for the Feature flag to be some kind of an access gate, the actual
 idea of the ResourceAccessGate is actual access control as in secure
 access. Also we just want to apply the feature flag gate to all
 Resourceproviders not a generic ACL gate which may also 

Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)

[Dominik Süß]

Hi Amit,

regarding your answer: this is at least not the spirit of feature flags,
but this would work as well since the toggle could be based on specific
groupmemberships or so.

This would also solve the second part you mentioned - a user might even
have permissions to toggle the switch for himself (the toggle it self
obviously should not be protected by the feature ;) ).
Such a mechanism would even match the scenario I just had where the feature
is experimental and therefore could be activated by users/tenants that want
to enable experimental features for their interface. (like google sometimes
gives you the option to turn on/off a newer version of their interface for
betatesting).

Best regards
Dominik


On Fri, Nov 15, 2013 at 4:13 PM, Amit.. Gupta. amitg...@adobe.com wrote:

 Hi,

 @Dominik,
 Some other use cases could be - free features vs premium/paid features,
 where some features are disabled based on type of user account.

 @Felix,
 You are right, we can temporarily enable feature. But, as we advocate more
 and more use of ResourceResolver api instead of underlying content storage.
 There could be cases where even editors/tools used in
 development/installers are using the resourceResolver api and never see the
 resource.
 Like exporting some content package to be deployed to another sling
 instance, but package exporter use resouceResolver api and never see the
 resource.

 Thanks,
 Amit

 -Original Message-
 From: Dominik Süß [mailto:dominik.su...@gmail.com]
 Sent: 15 November 2013 18:49
 To: dev
 Subject: Re: [OT] Feature flag influence on Resource access (Was: FYI:
 feature flags prototype)

 Hi Amit,
 maybe I haven't understood the idea of FeatureFlags right, but isn't this
 exactly what this is about. The system should behave if it wouldn't be
 there at all. The basic idea is that you don't have to branch it away
 during development so you can ship it in a non-productionready or non QEed
 state and turn it on without deployment (maybe just to a smaler audience or
 in the beta env). Therefore I would expect this to be completely hidden as
 it would like when being protected through ACLs.

 Cheers
 Dominik


 On Fri, Nov 15, 2013 at 2:11 PM, Amit.. Gupta. amitg...@adobe.com wrote:

  So, finally, I agree that baking the feature flag support directly
  into
  the ResourceResolver implementation is suboptimal, it is probably
  still the most comprehensive and complete solution to the
  requirements. And I cannot conceive plugin hooks (at this point) to
  define such that we can do feature flag plugins.
 
  I think that we should not put it directly into ResourceResolver,
  because if resourceResolver does not give me a resource if feature is
  disabled, Resource will stop existing for me. There will be no way to
  access that resource using ResourceResolver api i.e. let's say I want
  to remove sling:feature attribute from that resource, I can't do that.
  ResourceResolverDecorator should be the way to go (implementation
  could be restricted i.e. queryResources not supported), additionally
  providing a servlet filter as Alex suggested.
 
  Thanks,
  Amit
 
  -Original Message-
  From: Felix Meschberger [mailto:fmesc...@adobe.com]
  Sent: 15 November 2013 13:11
  To: dev@sling.apache.org
  Subject: [OT] Feature flag influence on Resource access (Was: FYI:
  feature flags prototype)
 
  Hi
 
  TL;DR: Long discussion on why I think Feature flag support should
  currently be baked into the ResourceResolver implementation.
 
  I am forking of this discussion now to step back a bit and really look
  into what we expect from Feature flag support in the ResourceResolver.
  I go by the main resource access or methods there, so:
 
  * resolve() - Resource
  Calculates a virtual list of resource candidates and returns the first
  one. Applying feature flags, it might not return the first one.
  Another level of features could be applied to supporting feature flags
  in the /etc/map mappings leading to the list of candidate resources.
 
  * map - String
  The input path is first converted into a resource, which may have a
  feature flag applied.
  In addition to applying a feature flag to the resource which is
  finally mapped the /etc/map mappings can also be filtered with feature
 flags.
 
  * getResource() - Resource
  For absolute path its a single yes/no question: Is the resource
  visible or not according to the feature flag.
  For relative paths its not as simple since the ResourceResolver
  iterates the search path looking for a resource. So each canidate is
  looked at and has to have its feature flag inspected. (feature flags
  of ancestors are ignored; only feature flags in the candidate resource
  itself are considered; so no feature flag inheritance down the tree)
 
  * getParentResource() - Resource
  This is not an interesting case because it accesses the parent
  resource using the absolute path and we would not expect to get null
  here (except if the argument resource

Re: FYI: feature flags prototype

[Dominik Süß]

+1 on extension hook in RR and adding this
I had no closer look at Accessgate yet and thought it to behave that way
from initial talks about this before implementation started. I just thought
that Access Control is not just about permissions, it is about granting or
denying access based on what ever logic you implement.

Best regards
Dominik


On Thu, Nov 14, 2013 at 12:12 PM, Julian Sedding jsedd...@gmail.com wrote:

  Rather I could imagine backing this into the ResourceResolver itself ...

 I think we should avoid going down this route. The ResourceResolver is
 a core feature of Sling, while feature-flags is (should be) an
 optional feature.

 Baking feature-flags into the RR would violate modularity IMO.

 One way to achieve the same integration without baking that
 functionality into the RR would be to create an extension hook that
 allows decorating the RR. Then the FF bundle could provide such a
 decorator and filter resources according to its needs.

 Regards
 Julian


 On Thu, Nov 14, 2013 at 1:30 AM, Felix Meschberger fmesc...@adobe.com
 wrote:
  Hi
 
  I agree that it would be cool to also select resources based on
 features. But I think the access gate is the wrong mechanism: Access
 Control and Feature Selection are different beasts and should not be mixed.
 
  Rather I could imagine backing this into the ResourceResolver itself:
 before returning a Resource it is checked for a feature flag property
  (e.g. sling:feature ?) and this being checked against the Feature service.
 If not enabled, that resource is „hidden“ and not returned.
 
  WDYT ?
 
  Regards
  Felix
 
  —
  Felix Meschberger  |  Principal Scientist  |  Adobe
 
 
 
  Am 14.11.2013 um 02:21 schrieb Dominik Süß dominik.su...@gmail.com:
 
  Hi Ruben,
 
  the intention is to disable features that are not should not be globally
  available but might be activated under certain conditions. This reduces
 the
  need to branch non-production ready features away and merge them in
 later
  and opens the option to have something like a Friendly user Test or
  softlaunch of a feature. Therefore this can be something big or
 something
  small. I think a solution should be capable of dealing with both. The
 java
  API would allow to hook in at any granularity level of the application
 so
  this already fullfills the requirements I'd have. Adding a corresponding
  declarative logic to filter the resourcetree would give the same coarse
  and/or finegrained filtermechanism to the resolutionprocess.
 
  What still would be missing is controlling updates and not just
 additions.
  e.g. when a resource should be rendered by a new version of a
 resourceType
  - in such case it might be an option to extend the searchpath from
  /libs/../myresourcetype, /apps/../myresourcetype by featurespecific
  overlaypaths that would either be searched when a feature is activated
 or
  hidden if the feature is deactivated. This would require refactoring
 later
  on but would allow parallel existance of multiple versions of a
  resourceType.
 
  Best regards,
  Dominik
 
 
 
 
  On Wed, Nov 13, 2013 at 4:02 PM, Ruben Reusser r...@headwire.com wrote:
 
  Bertrand, Dominik,
 
  the feature flag may also have an impact on the nodes/properties that
 you
  need to render the feature. Being able to handle this in the resource
 tree
  directly without having to handle it in component code would be great.
  However, I am not sure if the intention of the feature flag was more to
  enable/change little features (code fragment) and not really change big
  things (leave that to testtarget or other products?)
 
  Ruben
 
 
  On 11/13/2013 6:32 AM, Dominik Süß wrote:
 
  Hi Bertrand,
 
  the UI of an application based on Sling are often composed of existing
  resourceTypes so you cannot just decide in the code to display or not
 to
  display so you have to annotate/flag the resources and then have
 some
  code deciding if this resource should be rendered or not. For sure you
  could add code to each resource to check if it is to be rendered but
 this
  is a lot of repetive code. Another option would be a Servlet filter to
  skip
  inclusion at that Point. But this all fails in some situations like
  whenyou
  consume an aggregated json dump and use this on client side.
 Therefore the
  only shared location that all code should act on when looking at the
  persistance is the resourcetree, and as already existing API the
 Access
  Gate API seems to be capable of doing exactly what is required -
 masking
  the resourcetree based on custom logic.
 
  Best regards
  Dominik
 
 
  On Wed, Nov 13, 2013 at 12:01 PM, Bertrand Delacretaz 
  bdelacre...@apache.org wrote:
 
  Hi Dominik,
 
  On Tue, Nov 12, 2013 at 5:07 PM, Dominik Süß 
 dominik.su...@gmail.com
  wrote:
 
  ...as far as I can see the API is just covering the java aspect of
 
  this...
 
  Nothing prevents you from using the FeatureFlags service in scripted
  code.
 
  you could have a gate looking for a marker

Re: FYI: feature flags prototype

[Dominik Süß]

Hi Bertrand,

I disagree on that one - maybe we should put it in contrib or so, but is is
essential to disable most features to disable some parts of the
resourcetree. This is just applying your api in a conventient api to
resource resolving. There is no additional magic since developers would
have to set the flag in the content anyways.
As mentioned earlier the majority of features I have implemented yet do
have a frontendpart that would get rendered and it would add additional
complexity if I have to use custom resourceTypes (inherited ones through
superType) just to disable them based on such rules.

Best regards
Dominik


On Thu, Nov 14, 2013 at 2:03 PM, Bertrand Delacretaz bdelacre...@apache.org
 wrote:

 On Thu, Nov 14, 2013 at 1:56 PM, Mike Müller mike...@mysign.ch wrote:
  ...Just implement a
  FeatureFlagResourceGate (or whatever name would make sense)..

 My earlier question was, can one do this without any changes to Sling
 besides providing a way to find if a given feature is enabled, like in
 my prototype?

 I think the answer is yes, and if is is I wouldn't worry about it -
 let users implement that themselves to start with, but don't put
 anything in Sling for now besides the raw FeatureFlags (or Feature)
 service.

 Then, if common use cases emerge that need something in Sling,
 implement that - but cross that bridge once we get there.

 -Bertrand

Re: FYI: feature flags prototype

[Dominik Süß]

Hi Felix,

see my comments inline.

Best regards
Dominik

On Thu, Nov 14, 2013 at 2:35 PM, Felix Meschberger fmesc...@adobe.comwrote:

 Hi

 Sure you can do it, but it (a) doesn’t match the idea of an access gate
 (at least not in my little brain cells) and (b) it is not comprehensive
 since the JCR Resource Provider does not leverage that. (b) is IMHO the one
 reason breaking the idea.


Although I disagree on a (what else is this but restriction of access
(don't mix it with permission by default) if b is the case (so it could not
be granted to act on the global resource Tree I agree this would be a no go


 I like the idea of a decoration hook. Yet: it might have to be implemented
 somewhat differently because we don’t just want to have or have not a
 resource. In some cases we want to fall back to a resource with a lower
 „priority“ such as a resource furhter in the search path sequence. Just
 having a decorating hook would not solve this issue.

Why is that? The searchpath isn't influenced at all, it is just that in one
of the locations a specific verison is not there. What on the other hand
could break is a superType chain, but This is something the developer
should be aware when implementing. (given that decoration could be removal
as well)


 Regards
 Felix

 —
 Felix Meschberger  |  Principal Scientist  |  Adobe



 Am 14.11.2013 um 23:56 schrieb Mike Müller mike...@mysign.ch:

  To confirm what Dominik mentioned:
  The existing ResourceAccessGate would allow to grant or deny access
  to resources. IMHO there's no need to implement another interface or
  hook to achieve what is requested in the perspective of granting or
 denying
  access to resources based on feature flag. Just implement a
  FeatureFlagResourceGate (or whatever name would make sense)..
 
  best regards
  Mike
 
  -Original Message-
  From: Dominik Süß [mailto:dominik.su...@gmail.com]
  Sent: Thursday, November 14, 2013 1:07 PM
  To: dev
  Subject: Re: FYI: feature flags prototype
 
  +1 on extension hook in RR and adding this
  I had no closer look at Accessgate yet and thought it to behave that way
  from initial talks about this before implementation started. I just
 thought
  that Access Control is not just about permissions, it is about granting
 or
  denying access based on what ever logic you implement.
 
  Best regards
  Dominik
 
 
  On Thu, Nov 14, 2013 at 12:12 PM, Julian Sedding jsedd...@gmail.com
 wrote:
 
  Rather I could imagine backing this into the ResourceResolver itself
 ...
 
  I think we should avoid going down this route. The ResourceResolver is
  a core feature of Sling, while feature-flags is (should be) an
  optional feature.
 
  Baking feature-flags into the RR would violate modularity IMO.
 
  One way to achieve the same integration without baking that
  functionality into the RR would be to create an extension hook that
  allows decorating the RR. Then the FF bundle could provide such a
  decorator and filter resources according to its needs.
 
  Regards
  Julian
 
 
  On Thu, Nov 14, 2013 at 1:30 AM, Felix Meschberger fmesc...@adobe.com
 
  wrote:
  Hi
 
  I agree that it would be cool to also select resources based on
  features. But I think the access gate is the wrong mechanism: Access
  Control and Feature Selection are different beasts and should not be
 mixed.
 
  Rather I could imagine backing this into the ResourceResolver itself:
  before returning a Resource it is checked for a feature flag property
  (e.g. sling:feature ?) and this being checked against the Feature
 service.
  If not enabled, that resource is „hidden“ and not returned.
 
  WDYT ?
 
  Regards
  Felix
 
  —
  Felix Meschberger  |  Principal Scientist  |  Adobe
 
 
 
  Am 14.11.2013 um 02:21 schrieb Dominik Süß dominik.su...@gmail.com:
 
  Hi Ruben,
 
  the intention is to disable features that are not should not be
 globally
  available but might be activated under certain conditions. This
 reduces
  the
  need to branch non-production ready features away and merge them in
  later
  and opens the option to have something like a Friendly user Test or
  softlaunch of a feature. Therefore this can be something big or
  something
  small. I think a solution should be capable of dealing with both. The
  java
  API would allow to hook in at any granularity level of the
 application
  so
  this already fullfills the requirements I'd have. Adding a
 corresponding
  declarative logic to filter the resourcetree would give the same
 coarse
  and/or finegrained filtermechanism to the resolutionprocess.
 
  What still would be missing is controlling updates and not just
  additions.
  e.g. when a resource should be rendered by a new version of a
  resourceType
  - in such case it might be an option to extend the searchpath from
  /libs/../myresourcetype, /apps/../myresourcetype by featurespecific
  overlaypaths that would either be searched when a feature is
 activated
  or
  hidden if the feature is deactivated. This would require

Re: FYI: feature flags prototype

[Dominik Süß]

Hi Alex,
this is one way but just solves this partially since you completely rely on
inclusions to happen, but sometimes you just walk the tree and collect the
information of resources e.g. to draw the navigation - and for such
situations it would then be required to add such logic to the rendering
Code where you could just filter the ResourceTree beforehand.

Best regards,
Dominik


On Thu, Nov 14, 2013 at 10:48 PM, Alexander Klimetschek
aklim...@adobe.comwrote:

 On 14.11.2013, at 05:11, Dominik Süß dominik.su...@gmail.com wrote:

  As mentioned earlier the majority of features I have implemented yet do
  have a frontendpart that would get rendered and it would add additional
  complexity if I have to use custom resourceTypes (inherited ones through
  superType) just to disable them based on such rules.

 Wouldn't you just filter those requests out on a high level, e.g. using a
 servlet filter? Which can already be provided in a modular fashion by an
 optional featureflags module.


 Cheers,
 Alex

Re: FYI: feature flags prototype

[Dominik Süß]

Am 14.11.2013 23:11 schrieb Alexander Klimetschek aklim...@adobe.com:

 On 14.11.2013, at 13:55, Dominik Süß dominik.su...@gmail.com wrote:

  this is one way but just solves this partially since you completely
rely on
  inclusions to happen, but sometimes you just walk the tree and collect
the
  information of resources e.g. to draw the navigation - and for such
  situations it would then be required to add such logic to the rendering
  Code where you could just filter the ResourceTree beforehand.

 I see. And the ResourceDecorator can't filter out things?

No, returning null skips tehe decoration and returns the original resource.
You could hide properties but you'd additionally have to handle such
resources in applicationcode but having it really jidden.

Best regards
Dominik

Re: FYI: feature flags prototype

[Dominik Süß]

Hi Bertrand,

the UI of an application based on Sling are often composed of existing
resourceTypes so you cannot just decide in the code to display or not to
display so you have to annotate/flag the resources and then have some
code deciding if this resource should be rendered or not. For sure you
could add code to each resource to check if it is to be rendered but this
is a lot of repetive code. Another option would be a Servlet filter to skip
inclusion at that Point. But this all fails in some situations like whenyou
consume an aggregated json dump and use this on client side. Therefore the
only shared location that all code should act on when looking at the
persistance is the resourcetree, and as already existing API the Access
Gate API seems to be capable of doing exactly what is required - masking
the resourcetree based on custom logic.

Best regards
Dominik


On Wed, Nov 13, 2013 at 12:01 PM, Bertrand Delacretaz 
bdelacre...@apache.org wrote:

 Hi Dominik,

 On Tue, Nov 12, 2013 at 5:07 PM, Dominik Süß dominik.su...@gmail.com
 wrote:
  ...as far as I can see the API is just covering the java aspect of
 this...

 Nothing prevents you from using the FeatureFlags service in scripted code.

  you could have a gate looking for a marker at a resource
  which indicates it to be part of a specific feature and therefore
 disables
  access to it

 Do we need any changes to Sling or to this new API to enable that?

 The problem IMO is that this makes the whole thing less transparent
 than using feature flags in the rendering code. OTOH if people can
 implement it themselves (and add the corresponding info to
 RequestProgressTracker) for transparency, I don't mind.

 -Bertrand

Re: FYI: feature flags prototype

[Dominik Süß]

Hi Ruben,

the intention is to disable features that are not should not be globally
available but might be activated under certain conditions. This reduces the
need to branch non-production ready features away and merge them in later
and opens the option to have something like a Friendly user Test or
softlaunch of a feature. Therefore this can be something big or something
small. I think a solution should be capable of dealing with both. The java
API would allow to hook in at any granularity level of the application so
this already fullfills the requirements I'd have. Adding a corresponding
declarative logic to filter the resourcetree would give the same coarse
and/or finegrained filtermechanism to the resolutionprocess.

What still would be missing is controlling updates and not just additions.
e.g. when a resource should be rendered by a new version of a resourceType
- in such case it might be an option to extend the searchpath from
/libs/../myresourcetype, /apps/../myresourcetype by featurespecific
overlaypaths that would either be searched when a feature is activated or
hidden if the feature is deactivated. This would require refactoring later
on but would allow parallel existance of multiple versions of a
resourceType.

Best regards,
Dominik




On Wed, Nov 13, 2013 at 4:02 PM, Ruben Reusser r...@headwire.com wrote:

 Bertrand, Dominik,

 the feature flag may also have an impact on the nodes/properties that you
 need to render the feature. Being able to handle this in the resource tree
 directly without having to handle it in component code would be great.
 However, I am not sure if the intention of the feature flag was more to
 enable/change little features (code fragment) and not really change big
 things (leave that to testtarget or other products?)

 Ruben


 On 11/13/2013 6:32 AM, Dominik Süß wrote:

 Hi Bertrand,

 the UI of an application based on Sling are often composed of existing
 resourceTypes so you cannot just decide in the code to display or not to
 display so you have to annotate/flag the resources and then have some
 code deciding if this resource should be rendered or not. For sure you
 could add code to each resource to check if it is to be rendered but this
 is a lot of repetive code. Another option would be a Servlet filter to
 skip
 inclusion at that Point. But this all fails in some situations like
 whenyou
 consume an aggregated json dump and use this on client side. Therefore the
 only shared location that all code should act on when looking at the
 persistance is the resourcetree, and as already existing API the Access
 Gate API seems to be capable of doing exactly what is required - masking
 the resourcetree based on custom logic.

 Best regards
 Dominik


 On Wed, Nov 13, 2013 at 12:01 PM, Bertrand Delacretaz 
 bdelacre...@apache.org wrote:

  Hi Dominik,

 On Tue, Nov 12, 2013 at 5:07 PM, Dominik Süß dominik.su...@gmail.com
 wrote:

 ...as far as I can see the API is just covering the java aspect of

 this...

 Nothing prevents you from using the FeatureFlags service in scripted
 code.

  you could have a gate looking for a marker at a resource
 which indicates it to be part of a specific feature and therefore

 disables

 access to it

 Do we need any changes to Sling or to this new API to enable that?

 The problem IMO is that this makes the whole thing less transparent
 than using feature flags in the rendering code. OTOH if people can
 implement it themselves (and add the corresponding info to
 RequestProgressTracker) for transparency, I don't mind.

 -Bertrand

Re: [VOTE] - Accept donation of replication module to Apache Sling

[Dominik Süß]

+1 non-binding.
I just did a rough codecheck to understand how this should work - looks
good and extensible which I think is important when people with other
resourceResolvers want to utilize it. There are some typos here and there
(pacakge instead of package, even in the api) but it would be easier to
have this on github or svn to create corresponding patches.

Cheers
Dominik


On Mon, Nov 11, 2013 at 3:02 PM, Tommaso Teofili
tommaso.teof...@gmail.comwrote:

 Hi all,

 as per discussions on SLING-3223 [1] I'm opening the vote for accepting the
 Sling replication module for inclusion in Apache Sling project:

 [ ] +1 : accept its donation to Apache Sling
 [ ] +0 : don't care
 [ ] -1 : don't accept it because ...

 Vote is open for the next 72 hours.

 Looking forward to your votes.
 Regards,
 Tommaso

 [1] : https://issues.apache.org/jira/browse/SLING-3223

Re: FYI: feature flags prototype

[Dominik Süß]

Hi Bertrand,

as far as I can see the API is just covering the java aspect of this. When
looking at typical Apache Sling-based Applications you might want to toggle
specific resources from being renderes (this could be on page or on a lower
resource level). Since this is a lot about permission to access these
features I had the thought this is a case where the accessgates might be
suitable where you could have a gate looking for a marker at a resource
which indicates it to be part of a specific feature and therefore disables
access to it.

WDYT?

---
Dominik


On Tue, Nov 12, 2013 at 4:52 PM, Bertrand Delacretaz bdelacre...@apache.org
 wrote:

 Hi,

 FYI I have created a minimal prototype [2] of how I'd see feature
 flags in Sling, as suggested a while ago by Henry Saginor in
 SLING-3148.

 The slides at [1], that Tommaso tweeted today, are full of good ideas
 about this.

 -Bertrand

 [1] http://www.paulhammond.org/2010/06/trunk/alwaysshiptrunk.pdf

 [2]
 https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/feature-flags

Re: Scalabilty of EventListener

[Dominik Süß]

I just realized that there might be the need to dynamicaly add paths to the
Listener. I have at least 2 cases in mind where the paths cannot be
determined at deployment time which is the workflow launcher in CQ (where a
user does define a ruleset at runtime) which might be changed to individual
listeners being registerd, and the other case is when you have the
temporary need to watch for changes of specific nodes (e.g. when a cache
needs to be invalidated based on contentchanges - so the listener just
needs to react on changes of resources relevant to the invalidation logic).

During writing that I just came up with the question, what about such
global listeners as the replication agent of CQ which potentially nees to
act on all paths. The restrictions I have in mind is the path /content and
that it would be sufficient to have one aggregated event for a page
(substructure containing all resource to be used for rendering one
request)  which needs to be touched on subcontentchanges anyway
(lastmodified).

--
Dominik


On Tue, Oct 22, 2013 at 5:48 PM, Carsten Ziegeler cziege...@apache.orgwrote:

 From the use cases I know, the listeners register for a specific path and
 are rarely interested in anything else. Some do check the resource type as
 well.
 For example the script engines check for changes under /libs and /apps (the
 resource paths actually) for changes to scripts, the job engine checks for
 new jobs somewhere under /var/jobs and checks the resource type as well
 etc.
 Many use cases check for changes (resource added, resource removed,
 resource changed) and then re-read the sub tree based on the changes.

 The mapping handler in the resource resolver is probably the most
 interesting one as it changes for nodes with some well defined properties,
 basically scanning the whole repository. And I think the i18n stuff does
 something similar (but this one might still be using jcr observation).

 This list is by no means exhaustive for Sling, but we see that we already
 have two listeners scanning the whole repository and require access to
 properties.

 Carsten


 2013/10/22 Dominik Süß dominik.su...@gmail.com

  In a discussion [0] within the Oak mailinglist it became clear that the
 way
  Sling listens zu JCR Repository Changes and transforms all of them to
  events will not scale well in some big scale scenarios that oak is aiming
  to enable. Therefore the question was posted if it would be feasible
 and/or
  even necessary to refactor the API and deprecate (or at least discurrage)
  registration in a global scope as currently done.
 
  Since I do not want to copy  paste parts of the discussion I do hope
 that
  the participants of the oak discussion add the remaining options with
 some
  more detail about consequences than can be found in the linked
 discussion.
 
  It would be great to also get some feedbacks of consumers of the existing
  API about the usage to identify how finegrained a potential
  registrationlogic with paths/properties might need to be.
 
  Best regards
  Dominik
 
  [0] http://markmail.org/message/n5vllhjoawypteck
 



 --
 Carsten Ziegeler
 cziege...@apache.org

Re: Scalabilty of EventListener

[Dominik Süß]

The analysis looks pretty good to me but does not provide answers of how to
solve this. The first two topics Cached Content and Content Export,
Replication to Remote Systems are the ones where I don't see an option to
get rid of the content change triggers. This might not apply to the whole
tree, but does this really matter when the tree that needs to be watched
contains over 90% of the data?

If I got the problem right the overhead is created by the fact that an
event object is created and sent regardles if a consumer cares about it or
not. So it might be worth to add something that asks the listeners if
there is one that would consume this event and (something like an
accepts() Method handing over raw metadata without generating the event
object itself - more like a filter) and send the event then to be consumed
by this and potential other consumers.

Or did i get something completely wrong?

Cheers
Dominik


On Wed, Oct 23, 2013 at 2:30 PM, Bertrand Delacretaz bdelacre...@apache.org
 wrote:

 On Wed, Oct 23, 2013 at 2:10 PM, Carsten Ziegeler cziege...@apache.org
 wrote:
  So far, I heard that the global listener which translates jcr events
 into
  OSGi events is a problem - however as far as I followed the discussion,
  this isn't a problem right now but might lead to problems in some time if
  huge Oak based clustered repositories are used...

 Agreed.

  ...In the same category fall the global listeners we have in the resource
  resolver for the mapping and the i18n one..
  Is there more?...

 I looked at an analysis the we did earlier this year on our
 Sling-based app and I don't have more than that.

 -Bertrand

Re: Scalabilty of EventListener

[Dominik Süß]

Hi Bertrand,

I'm not so sure about the seldom changes - it is not about the amound of
changes but about the amount of changes in a specific timeframe. The
initial discussion started with the asumtion to have to deal with tons of
changes within a second, e.g. for huge imports.  In some cases those
imports are real imports (so new creation) so postponing the processing and
delegating to some postprocessing might work - but in case of updates this
is not so easy (and I know such cases from the automotive area where masses
of technical data is synched to all markets).

Regarding the options you were stating:
- service properties: my initial thought, but static and can therefore not
adress all scenarios
- registring for certain types: same problem, a bit more possibilities but
restricted to the capabilities of the registry

Therefore I thought of a filterlike behavior where the listeners can
implement their own logic. Including measuring the time such a call takes
and having a healthcheck announcing such a logic not to be performing well
would be a good way to give developers the tooling to identify where they
lose performance in this area.

---
Dominik


On Wed, Oct 23, 2013 at 4:19 PM, Bertrand Delacretaz bdelacre...@apache.org
 wrote:

 Hi,

 On Wed, Oct 23, 2013 at 4:01 PM, Dominik Süß dominik.su...@gmail.com
 wrote:
  ...This might not apply to the whole
  tree, but does this really matter when the tree that needs to be watched
  contains over 90% of the data?...

 What's important is the frequency of observation events - if that 90%
 seldom changes, scaling won't be a problem.

  ...If I got the problem right the overhead is created by the fact that an
  event object is created and sent regardles if a consumer cares about it
 or
  not. So it might be worth to add something that asks the listeners if
  there is one that would consume this event...

 That's what I meant above:

  ...A simple way of making our wide observation more specific is to
  require users of our rebroadcast OSGi events to indicate more
  specifically what they're interested in...

 There's various ways of doing that: service properties, calling a
 service to register your interest in certain types of events etc.

 -Bertrand

Scalabilty of EventListener

[Dominik Süß]

In a discussion [0] within the Oak mailinglist it became clear that the way
Sling listens zu JCR Repository Changes and transforms all of them to
events will not scale well in some big scale scenarios that oak is aiming
to enable. Therefore the question was posted if it would be feasible and/or
even necessary to refactor the API and deprecate (or at least discurrage)
registration in a global scope as currently done.

Since I do not want to copy  paste parts of the discussion I do hope that
the participants of the oak discussion add the remaining options with some
more detail about consequences than can be found in the linked discussion.

It would be great to also get some feedbacks of consumers of the existing
API about the usage to identify how finegrained a potential
registrationlogic with paths/properties might need to be.

Best regards
Dominik

[0] http://markmail.org/message/n5vllhjoawypteck

AdaptTo 2013 Berlin

[Dominik Süß]

Hi everyone,

time runs fast and like the last two years we'll have adaptTo() in Berlin.
For those who do not know it yet: this is a non-profit conference arround
Apache Sling and the connected Frameworks like Apache Felix and Apache
Jackrabbit.

The conference is hosted by pro!vision GmbH and sponsored by Adobe Systems
with great support of various ASF members participating as speakers and
driving the community around this great open source project further.

Since there is so little time left I would like to encourage you to
register as soon as possible so we can make sure you get a shirt in the
right size and catering can be planned.

In contrast to last year we try to give you more room for interaction and
socializing. So have a look at all the details including a schedule draft
at http://www.adaptto.org

I'm looking forward to seeing you in Berlin next month.

Best regards
Dominik

Re: Service Authentication

[Dominik Süß]

Hi Felix,

I just did wonder if this really can replace loginAdministrative().
Although I'd really like to get rid of the adminSession due to various
(mostly securitybased) reasons, I don't see all usecases covered by this
solution. The one I have explicitly in mind is the impersonation to users.
Just think of asynchronous processing of content by a service _in the name
and under the restrictions of a user_ Nowadays you'd get an adminsession
and then impersonate it since the adminsession is the only session
implicitly allowed to impersonate any user.
Beside the fact that impersonation is a problematic feature in sense of
tracibility (not being identified as impersonated session in the logs) this
seems to be the only way to fullfill such a task.

Cheers
Dominik


On Fri, Jul 5, 2013 at 8:20 PM, Felix Meschberger fmesc...@adobe.comwrote:

 Hi Angela,

 Thanks alot for the extensive feedback. Very much appreciated !

 Am 05.07.2013 um 11:01 schrieb Angela Schreiber:

  hi felix
 
  i had a closer look at the patch in SLING-2944. here some
  additional comments:
 
  SlingRepository.java:
  
  - lacks whitespace in the javadoc of #loginService:
 + * Returns a sessionto the given workspace with privileges
 + * Returns a session to the given workspace with privileges
 
 ACK

  - IMO the param description of @param serviceInfo is not self
 explaining. i would suggest that you either quickly describe what
 the serviceInfo is or link to another location for further
 information.
 

 ACK

 
  JcrResourceProviderFactory:
  
  - typo in the name of the repository constant
 +private static final String REPOSITORY_REFERNENCE_NAME =
  repository;
 +private static final String REPOSITORY_REFERENCE_NAME =
  repository;
 = and fixing accordingly in the @Reference annotation for
the repositoryReference field and in the active method.
 

 ACK

 
  Regarding deprecation of loginAdministrative et al
  
  on the wiki page you state that there will be a configuration flag
  to disable those methods. is that still outstanding or did i miss it?
  IMO that would be really cool to have as we definitely want to
  get rid of the admin-logins.

 Oops, missed that. Yes, that makes perfect sense. I will add it with
 values enabled (will write a warn log message) and disabled (will throw
 a LoginException and log an error message explaining the case)

 For backwards compatibility I would think that initially this will default
 to enabled with. Later we can change that default.

 WDYT ?

 
  related to this: i got the impression that the deprecated methods are
  still used in AbstractSlingRepository and JcrResourceProviderFactory.
  wouldn't it be better to replace them with an internal call such
  that the API method can really be disabled?

 Yes, absolutely.

 
 
  Regarding implementation of #loginService
  
  this is currently achieved by loginAdministrative followed by an
  impersonation. as of oak where we plan to have pluggable and
  osgi aware principal mgt exposed on the OAK layer. this could
  potentially be used to simplify the call and replace it by a
  single pre-authenticated login where the subject for the service
  user is created upfront by retrieve the principal set for the
  specified service userId.

 We could split the loginService(Bundle, ...) method to allow plugging a
 different implementation for the actual session creation once the user has
 been defined.

 The default implementation would be the impersonation based one and an
 improved one based on Oak could implenent that.

 
 
  ServiceUserMapper
  
  if we agree that userId was better than user name, the javadoc of
  the ServiceUserMapper should be adjusted to consistently use userId.

 Absolutely

 
  what i am missing in the documentation is a short note about what
  a service user is and if/how that service users should/could be
  different from regular users. since that service user mapper goes
  along with a modification in jackrabbit that allows to create user
  accounts without password it might we worth mentioning somewhere
  in the documentation that service users are not necessarily intended
  to perform a regular SlingRepository#login (which in combination with
  jackrabbit and oak can be achieved by creating those special users
  without password).

 Good point.

 
 
  Mapping
  
  here again 'userName' should be replaced by userId.

 ACK

 
 
  ServiceUserMapperImpl
  
  same here: references to the user's name should be 

Re: SLING-2803 validation module, hierarchical structures and extensible types

[Dominik Süß]

+1 - validation can also be necessary on dataimport through services, to
have a default integration of this service in the default Post Handler is
IMHO a mandatory but not stricktly bound extension to this service.

Dominik


On Mon, Jul 8, 2013 at 12:19 PM, Carsten Ziegeler cziege...@apache.orgwrote:

 Even if there is processing overhead - and I think this is really minimal
 compared to persisting the data - storing unvalidated and therefore maybe
 wrong data might haver a much higher impact on the application.

 And I totally agree, this needs to be configurable (controllable) - but
 limiting this to the post servlet is way too restrictive.

 Carsten


 2013/7/8 Alexander Klimetschek aklim...@adobe.com

  On 04.07.2013, at 14:56, Carsten Ziegeler cziege...@apache.org wrote:
 
   Adding this - maybe as an optional service - into the resource resolver
   makes it also impossible to bypass validation - the validation is
 always
   done regardless whether the changes are done through the post servlet,
  any
   other servlet, or some server side code running in the background.
 
  We should be careful with the imposed new processing overhead of this.
  There needs to be control over it, and IMO an active whitelisting for
 which
  validators (i.e. resource types) this would happen and when. And the
  simplest way to do that is to have custom application code call the
  validation service (one-liner) themselves and do it automatically only in
  the post servlet (but also with an option to enable/disable individual
  validators).
 
  Cheers,
  Alex




 --
 Carsten Ziegeler
 cziege...@apache.org

Re: SLING-2803 validation module, hierarchical structures and extensible types

[Dominik Süß]

Hi Radu,

regarding the first part of your mail:
 I see validation as generic check which allows to read (and explicitly not
modify, I wouldn't mess with autofixing) data from anywhere in the system
(inkluding resourcetree as well as OSGi Services) and return either true or
false and optionally some metadata like what caused it to fail (and
probably some resoltionhints).

Best regards
Dominik


On Mon, Jul 8, 2013 at 2:42 PM, Radu Cotescu r...@apache.org wrote:

 Hi,

 Apart from Carsten nobody else provided me with an answer to my question,
 which in the end boils down to what kind of validation is needed in Sling:

 Depending on what we need in Sling I see two solutions:
  1. extend the current API and implementation to be able to validate
  tree-like structures - better suited for validating requests rather than
  resources, given that most ValueMap implementations don't provide us with
  the children's properties
  2. erase and start over with a new validation framework at the
  ResourceResolver level that would handle validation right before the
 commit
  phase - this implies that we actually validate changed resources (credits
  to Carsten for this idea)
 
  Devs, which solution sounds better to you and why?
 

 What would be the minimum requirements for adding some validation bundles
 (api + impl) in contrib?

 Thanks,
 Radu


 On Mon, Jul 8, 2013 at 3:24 PM, Dominik Süß dominik.su...@gmail.com
 wrote:

  +1 - validation can also be necessary on dataimport through services, to
  have a default integration of this service in the default Post Handler is
  IMHO a mandatory but not stricktly bound extension to this service.
 
  Dominik
 
 
  On Mon, Jul 8, 2013 at 12:19 PM, Carsten Ziegeler cziege...@apache.org
  wrote:
 
   Even if there is processing overhead - and I think this is really
 minimal
   compared to persisting the data - storing unvalidated and therefore
 maybe
   wrong data might haver a much higher impact on the application.
  
   And I totally agree, this needs to be configurable (controllable) - but
   limiting this to the post servlet is way too restrictive.
  
   Carsten
  
  
   2013/7/8 Alexander Klimetschek aklim...@adobe.com
  
On 04.07.2013, at 14:56, Carsten Ziegeler cziege...@apache.org
  wrote:
   
 Adding this - maybe as an optional service - into the resource
  resolver
 makes it also impossible to bypass validation - the validation is
   always
 done regardless whether the changes are done through the post
  servlet,
any
 other servlet, or some server side code running in the background.
   
We should be careful with the imposed new processing overhead of
 this.
There needs to be control over it, and IMO an active whitelisting for
   which
validators (i.e. resource types) this would happen and when. And the
simplest way to do that is to have custom application code call the
validation service (one-liner) themselves and do it automatically
 only
  in
the post servlet (but also with an option to enable/disable
 individual
validators).
   
Cheers,
Alex
  
  
  
  
   --
   Carsten Ziegeler
   cziege...@apache.org
  
 

Re: Sling Posthandling - thougts about the current behavior

[Dominik Süß]

Hi Alex,

why do you think registering logic by path is bad. Especially if I look at
potential for multitenantsupport it would be great to be able to register
postbehavior that is tenantspecific. And the tenantsupport of Sling is
completely based on paths.

Regarding usage of Servlet Filters as pipelline I personally think this
could probably get a bit intransparent for develpers. As previously
mentioned the various phases should/would give the option to have a
contract about what can be done during that phase. A filterbased handling
just would give the option to control order of execution, but any filter
could break this transactional contract.
The injection of such a pipeline without the need to touch the existing
servlet could be done via a filter, but I think it would make sense to
optimize the current implementation when introducing such a mechanism.

Just my 2 cents
Dominik


On Tue, Jul 2, 2013 at 8:38 PM, Alexander Klimetschek aklim...@adobe.comwrote:

 Ack on the overall goal.

 The way I see it, it boils down to having the sling post servlet (or more
 specifically that new POST-pipeline) not just one special servlet out of
 many, but an integral part of Sling.


 Registering operations, post processors or whatever we need by resource
 type sounds good. By path not so much, don't know.

 IMHO, the rt would be taken from the addressed resource (what the URL
 addresses, to be 1:1 with how GET servlet resolution works; not any
 resources that additional request parameters might address) and if not
 present (creating a new resource) from the sling:resourceType param.

 It would actually be nice if those operations or postprocessor could
 become servlets or servlet filters again. They could get the necessary
 state passed via a request attribute for example + a utility to fetch them.
 And thinking about it, filters are actually the right thing, they are
 designed for pipelines.

 I am not sure if adding a :selector parameter as proposed by Justin
 (SLING-2936) is a good idea - maybe the integration with this new pipeline
 is the better long-term approach. You'd register by resource type + http
 method + :operation. Having both :operation and :selector (in the combined
 overall picture) seems like duplication. But it's difficult.

 It was mentioned that using selectors in the URL for POST requests, such
 as POST /content/page.createChild.html, is not RESTful. Is that really the
 case? As long as the server provides the URL instead of the client building
 it himself, such as path + .createChild.html as it happens way too
 much, and you use the right HTTP methods for changing/deleting content,
 nothing here would be unRESTful afaics.

 It would only look nicer if you put all the POST related information into
 the request parameters instead of into the URL. But then it's the old
 action=create topic again, which should be covered very well with the
 default features of the Sling post servlet already, which only requires you
 to add custom code (actions) for very specific things.

 This is even less once we have a validation framework in place (also
 resource type based), where Radu did a lot of work already!

 Cheers,
 Alex


 On 02.07.2013, at 15:26, Dominik Süß dominik.su...@gmail.com wrote:

  Well, if locking is just about permission I do agree with ACLs being the
  right solution (the permission set on the node itself might be sufficient
  for that case) - if it is about businessconstraints that need to be
  fullfilled an ACL cannot solve this requirement[0]. This is why
 validation
  and so on should be performed first, I would think of a pipeline having a
  contract on each phase what can be done and what cannot be done, while a
  first phase might not write any data (even as transient changes) the next
  phase might be perform (transient) change, then the postoperations would
 be
  performed in a transient followed by another phase that might perform
  transient changes and/or stop the processing, followed by a last phase
 that
  is called after the resourceResolve has performed a commit().
 
  This is purely about giving developers a contract on what they can and
  cannot do (and therefore what they can expect 3rd party code to do) at a
  specific point in this pipeline.
 
  [0] a businessconstraint to control sepecific operations by permissions
  could be solved by a shadowstructure like proposed by Bertrand.
 
  --
  Dominik
 
 
  On Tue, Jul 2, 2013 at 2:47 PM, Bertrand Delacretaz
  bdelacre...@apache.orgwrote:
 
  On Tue, Jul 2, 2013 at 2:38 PM, Dominik Süß dominik.su...@gmail.com
  wrote:
  Facing some questions about how to prevent the SlingPostServlet to be
  able
  to perform a change I had a closer look at the current implementation
 and
  it looks like there is currently no secure way of doing that beside
  locking the target on persistancelevel (alias setting ACLs)...
 
  ...which looks to me like the right way of locking things.
 
  But maybe for the post servlet we need a parallel

Re: Sling Posthandling - thougts about the current behavior

[Dominik Süß]

Hi Bertrand,

while I agree that paths should not drive the app they might build a scope
for the logic, since the content is organized in a tree structure and not
in by it's resourceType hierarchy, Therefore you often do have pathspecific
operations (just think of workflows and workflowlaunchers in CQ). Or to
come up with another scenario.
Changing resourceTypes depending on the location of the same data on the
other hand would be redundant information.

So - the main Driver should be the resourceType is what is defining the
behavior of a component while the contentpath in my eyes could act as
restricting criteria.

WDYT?


On Wed, Jul 3, 2013 at 1:22 PM, Bertrand Delacretaz
bdelacre...@apache.orgwrote:

 Hi,

 On Wed, Jul 3, 2013 at 12:55 PM, Dominik Süß dominik.su...@gmail.com
 wrote:
  ...why do you think registering logic by path is bad. Especially if I
 look at
  potential for multitenantsupport it would be great to be able to register
  postbehavior that is tenantspecific. And the tenantsupport of Sling is
  completely based on paths

 In general we want people to get away from the notion that paths drive
 your app, it should be resource types that do.

 Also, the problem with paths is that they are usually hidden in code,
 whereas resource types are transparently exposed in the content.

 For the POST handling, we could very well take the resource type of
 the parent/ancestors into account, instead of relying on paths.

 -Bertrand