[jira] [Commented] (SLING-6219) Allow to create users with repoinit

[Bertrand Delacretaz (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15646833#comment-15646833
 ] 

Bertrand Delacretaz commented on SLING-6219:


The encoding is meant to be used to provide passwords like 
{SHA-256}dc460da4as mentioned by Robert above, where SHA-256 would be the 
encoding.

I think it's fine to keep it in the grammar for now and aim for supporting it 
as soon as we can - but it's also easy to disable in the grammar - 
http://svn.apache.org/rsvn.apache.org/r1768509 should give a good idea of how 
that works.

> Allow to create users with repoinit
> ---
>
> Key: SLING-6219
> URL: https://issues.apache.org/jira/browse/SLING-6219
> Project: Sling
>  Issue Type: New Feature
>  Components: JCR, Repoinit
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Repoinit Parser 1.0.4, Repoinit JCR 1.0.4
>
>
> it seems it's not possible to create a user through the repoinit. 
> This would be very useful for sample apps and testing. For example, the
> slingshot sample app currently needs an admin user to create the sample
> user accounts. And therefore slingshot needs to be in the whitelist for
> admin usage - which is not a good thing
> I suggest we add:
> create user {name}
> create user {name} {password}
> delete user {name}
> If no pw is provided for create user, we create a random pw



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (SLING-6219) Allow to create users with repoinit

[Bertrand Delacretaz (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15646833#comment-15646833
 ] 

Bertrand Delacretaz edited comment on SLING-6219 at 11/8/16 7:57 AM:
-

The encoding is meant to be used to provide passwords like 

{code}
{SHA-256}dc460da4
{code}

as mentioned by Robert above, where SHA-256 would be the encoding.

I think it's fine to keep it in the grammar for now and aim for supporting it 
as soon as we can - but it's also easy to disable in the grammar - 
http://svn.apache.org/rsvn.apache.org/r1768509 should give a good idea of how 
that works.


was (Author: bdelacretaz):
The encoding is meant to be used to provide passwords like 
{SHA-256}dc460da4as mentioned by Robert above, where SHA-256 would be the 
encoding.

I think it's fine to keep it in the grammar for now and aim for supporting it 
as soon as we can - but it's also easy to disable in the grammar - 
http://svn.apache.org/rsvn.apache.org/r1768509 should give a good idea of how 
that works.

> Allow to create users with repoinit
> ---
>
> Key: SLING-6219
> URL: https://issues.apache.org/jira/browse/SLING-6219
> Project: Sling
>  Issue Type: New Feature
>  Components: JCR, Repoinit
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Repoinit Parser 1.0.4, Repoinit JCR 1.0.4
>
>
> it seems it's not possible to create a user through the repoinit. 
> This would be very useful for sample apps and testing. For example, the
> slingshot sample app currently needs an admin user to create the sample
> user accounts. And therefore slingshot needs to be in the whitelist for
> admin usage - which is not a good thing
> I suggest we add:
> create user {name}
> create user {name} {password}
> delete user {name}
> If no pw is provided for create user, we create a random pw



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6068) slingstart-maven-plugin: Allow to start a quickstart JAR based on a provisioning model even for non "slingstart" packagings

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15646749#comment-15646749
 ] 

Carsten Ziegeler commented on SLING-6068:
-

I understand that a clash in generated artifacts is is one of the problems this 
issue tries to solve. How about we do a check whether the project is a 
slingstart project and in that case use the old names, otherwise the new ones.

> slingstart-maven-plugin: Allow to start a quickstart JAR based on a 
> provisioning model even for non "slingstart" packagings
> ---
>
> Key: SLING-6068
> URL: https://issues.apache.org/jira/browse/SLING-6068
> Project: Sling
>  Issue Type: Improvement
>  Components: Maven Plugins and Archetypes
>Affects Versions: Slingstart Maven Plugin 1.4.4
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Slingstart Maven Plugin 1.5.0
>
> Attachments: SLING-6068-v01.patch
>
>
> Currently the {{slingstart-maven-plugin}} can only start a server based on 
> textual model definitions in case the maven module is of packaging 
> "slingstart" 
> (https://sling.apache.org/documentation/development/slingstart.html#starting-a-server).
>  
> For ITs it is often beneficial to have them in the same module as the tested 
> classes itself (which in most cases have packaging {{bundle}}). Therefore it 
> would be nice, if even for other packaging values all model definitions below 
> {{src/main/provisioning}} would be considered during the goal {{start}} 
> (which must first build the quickstart.jar out of the models and then start 
> it).
> Compare also with the readme in 
> https://github.com/apache/sling/blob/trunk/testing/samples/bundle-with-it/pom.xml#L196.
>  This would be especially helpful for ITs leveraging the {{TeleporterRule}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-6213) Provide a way to add artifacts from the current project to the provisioning model

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler resolved SLING-6213.
-
Resolution: Fixed

Tested with the slingshot sample, works

> Provide a way to add artifacts from the current project to the provisioning 
> model
> -
>
> Key: SLING-6213
> URL: https://issues.apache.org/jira/browse/SLING-6213
> Project: Sling
>  Issue Type: Improvement
>  Components: Maven Plugins and Archetypes
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Slingstart Maven Plugin 1.5.0
>
>
> For single bundle projects and for example for sample apps it would be nice 
> if everything could be defined in a single project: the bundle with the code, 
> and the provisioning model for the feature defined through this project.
> An example is the slingshot sample app: it has a bundle for the app code, but 
> also needs a prov model for repoinit stuff, like setting up a service user 
> etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6219) Allow to create users with repoinit

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15646664#comment-15646664
 ] 

Carsten Ziegeler commented on SLING-6219:
-

[~bdelacretaz] I'Ve tested with plain text passwords and this works, but I have 
no idea about the encoding stuff (I mean the two argument variant with encoding 
+ password). If this is not supported, shouldnt we maybe remove it for now?

> Allow to create users with repoinit
> ---
>
> Key: SLING-6219
> URL: https://issues.apache.org/jira/browse/SLING-6219
> Project: Sling
>  Issue Type: New Feature
>  Components: JCR, Repoinit
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Repoinit Parser 1.0.4, Repoinit JCR 1.0.4
>
>
> it seems it's not possible to create a user through the repoinit. 
> This would be very useful for sample apps and testing. For example, the
> slingshot sample app currently needs an admin user to create the sample
> user accounts. And therefore slingshot needs to be in the whitelist for
> admin usage - which is not a good thing
> I suggest we add:
> create user {name}
> create user {name} {password}
> delete user {name}
> If no pw is provided for create user, we create a random pw



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (SLING-6068) slingstart-maven-plugin: Allow to start a quickstart JAR based on a provisioning model even for non "slingstart" packagings

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler reopened SLING-6068:
-

There is another regression, the created artifacts now have different names, 
breaking any script. This is the output from version 1.4.4:

[INFO] --- slingstart-maven-plugin:1.4.4:package (default-package) @ 
org.apache.sling.launchpad ---
[INFO] Packaging standalone jar...
[INFO] Building zip: 
/Users/cziegeler/Developer/workspaces/granite/sling/launchpad/builder/target/org.apache.sling.launchpad-9-SNAPSHOT.jar
[INFO] Packaging webapp...
[INFO] Building zip: 
/Users/cziegeler/Developer/workspaces/granite/sling/launchpad/builder/target/org.apache.sling.launchpad-9-SNAPSHOT.war

and this from 1.4.5-SNAPSHOT:
[INFO] --- slingstart-maven-plugin:1.4.5-SNAPSHOT:package (default-package) @ 
org.apache.sling.launchpad ---
[INFO] Packaging standalone jar...
[INFO] Building zip: 
/Users/cziegeler/Developer/workspaces/granite/sling/launchpad/builder/target/org.apache.sling.launchpad-9-SNAPSHOT.standalonelaunchpad.jar
[INFO] Packaging webapp...
[INFO] Building zip: 
/Users/cziegeler/Developer/workspaces/granite/sling/launchpad/builder/target/org.apache.sling.launchpad-9-SNAPSHOT.webapplaunchpad.war


> slingstart-maven-plugin: Allow to start a quickstart JAR based on a 
> provisioning model even for non "slingstart" packagings
> ---
>
> Key: SLING-6068
> URL: https://issues.apache.org/jira/browse/SLING-6068
> Project: Sling
>  Issue Type: Improvement
>  Components: Maven Plugins and Archetypes
>Affects Versions: Slingstart Maven Plugin 1.4.4
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Slingstart Maven Plugin 1.5.0
>
> Attachments: SLING-6068-v01.patch
>
>
> Currently the {{slingstart-maven-plugin}} can only start a server based on 
> textual model definitions in case the maven module is of packaging 
> "slingstart" 
> (https://sling.apache.org/documentation/development/slingstart.html#starting-a-server).
>  
> For ITs it is often beneficial to have them in the same module as the tested 
> classes itself (which in most cases have packaging {{bundle}}). Therefore it 
> would be nice, if even for other packaging values all model definitions below 
> {{src/main/provisioning}} would be considered during the goal {{start}} 
> (which must first build the quickstart.jar out of the models and then start 
> it).
> Compare also with the readme in 
> https://github.com/apache/sling/blob/trunk/testing/samples/bundle-with-it/pom.xml#L196.
>  This would be especially helpful for ITs leveraging the {{TeleporterRule}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-6068) slingstart-maven-plugin: Allow to start a quickstart JAR based on a provisioning model even for non "slingstart" packagings

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler resolved SLING-6068.
-
Resolution: Fixed

Thanks [~kwin]. I'Ve applied your patch in rev 1768630 and it seems to fix the 
problem

> slingstart-maven-plugin: Allow to start a quickstart JAR based on a 
> provisioning model even for non "slingstart" packagings
> ---
>
> Key: SLING-6068
> URL: https://issues.apache.org/jira/browse/SLING-6068
> Project: Sling
>  Issue Type: Improvement
>  Components: Maven Plugins and Archetypes
>Affects Versions: Slingstart Maven Plugin 1.4.4
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Slingstart Maven Plugin 1.5.0
>
> Attachments: SLING-6068-v01.patch
>
>
> Currently the {{slingstart-maven-plugin}} can only start a server based on 
> textual model definitions in case the maven module is of packaging 
> "slingstart" 
> (https://sling.apache.org/documentation/development/slingstart.html#starting-a-server).
>  
> For ITs it is often beneficial to have them in the same module as the tested 
> classes itself (which in most cases have packaging {{bundle}}). Therefore it 
> would be nice, if even for other packaging values all model definitions below 
> {{src/main/provisioning}} would be considered during the goal {{start}} 
> (which must first build the quickstart.jar out of the models and then start 
> it).
> Compare also with the readme in 
> https://github.com/apache/sling/blob/trunk/testing/samples/bundle-with-it/pom.xml#L196.
>  This would be especially helpful for ITs leveraging the {{TeleporterRule}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (SLING-6252) Resource Editor :: Fix frontend build

[Sandro Boehme (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sandro Boehme reassigned SLING-6252:


Assignee: Sandro Boehme

> Resource Editor :: Fix frontend build
> -
>
> Key: SLING-6252
> URL: https://issues.apache.org/jira/browse/SLING-6252
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Sandro Boehme
>Assignee: Sandro Boehme
>
> The frontend build currently does not work because the package.json has to be 
> updated and the e2e tests for PhantomJS (and Chrome and Firefox) have to be 
> fixed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-6252) Resource Editor :: Fix frontend build

[Sandro Boehme (JIRA)]

Sandro Boehme created SLING-6252:


 Summary: Resource Editor :: Fix frontend build
 Key: SLING-6252
 URL: https://issues.apache.org/jira/browse/SLING-6252
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Reporter: Sandro Boehme


The frontend build currently does not work because the package.json has to be 
updated and the e2e tests for PhantomJS (and Chrome and Firefox) have to be 
fixed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6219) Allow to create users with repoinit

[Oliver Lietz (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15645190#comment-15645190
 ] 

Oliver Lietz commented on SLING-6219:
-

Plain text passwords only with current {{UserManager}}, see JCR-4050.

> Allow to create users with repoinit
> ---
>
> Key: SLING-6219
> URL: https://issues.apache.org/jira/browse/SLING-6219
> Project: Sling
>  Issue Type: New Feature
>  Components: JCR, Repoinit
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Repoinit Parser 1.0.4, Repoinit JCR 1.0.4
>
>
> it seems it's not possible to create a user through the repoinit. 
> This would be very useful for sample apps and testing. For example, the
> slingshot sample app currently needs an admin user to create the sample
> user accounts. And therefore slingshot needs to be in the whitelist for
> admin usage - which is not a good thing
> I suggest we add:
> create user {name}
> create user {name} {password}
> delete user {name}
> If no pw is provided for create user, we create a random pw



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-6068) slingstart-maven-plugin: Allow to start a quickstart JAR based on a provisioning model even for non "slingstart" packagings

[Konrad Windszus (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus updated SLING-6068:
---
Attachment: SLING-6068-v01.patch

Attached is an untested patch.
[~cziegeler] Feel free to try out, otherwise I will do some testing tomorrow.

> slingstart-maven-plugin: Allow to start a quickstart JAR based on a 
> provisioning model even for non "slingstart" packagings
> ---
>
> Key: SLING-6068
> URL: https://issues.apache.org/jira/browse/SLING-6068
> Project: Sling
>  Issue Type: Improvement
>  Components: Maven Plugins and Archetypes
>Affects Versions: Slingstart Maven Plugin 1.4.4
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Slingstart Maven Plugin 1.5.0
>
> Attachments: SLING-6068-v01.patch
>
>
> Currently the {{slingstart-maven-plugin}} can only start a server based on 
> textual model definitions in case the maven module is of packaging 
> "slingstart" 
> (https://sling.apache.org/documentation/development/slingstart.html#starting-a-server).
>  
> For ITs it is often beneficial to have them in the same module as the tested 
> classes itself (which in most cases have packaging {{bundle}}). Therefore it 
> would be nice, if even for other packaging values all model definitions below 
> {{src/main/provisioning}} would be considered during the goal {{start}} 
> (which must first build the quickstart.jar out of the models and then start 
> it).
> Compare also with the readme in 
> https://github.com/apache/sling/blob/trunk/testing/samples/bundle-with-it/pom.xml#L196.
>  This would be especially helpful for ITs leveraging the {{TeleporterRule}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6068) slingstart-maven-plugin: Allow to start a quickstart JAR based on a provisioning model even for non "slingstart" packagings

[Konrad Windszus (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15644769#comment-15644769
 ] 

Konrad Windszus commented on SLING-6068:


Ooops, this seems to be a conflict between the change in 
https://github.com/apache/sling/blame/74a64290b14597187a370ccb70a9b9e01e7fe530/tooling/maven/slingstart-maven-plugin/src/main/java/org/apache/sling/maven/slingstart/PackageMojo.java#L79
 and 
https://github.com/apache/sling/blob/trunk/tooling/maven/slingstart-maven-plugin/src/main/java/org/apache/sling/maven/slingstart/run/StartMojo.java#L405.
 Probably it would good to rely on the same code to figure out the right 
filename.

> slingstart-maven-plugin: Allow to start a quickstart JAR based on a 
> provisioning model even for non "slingstart" packagings
> ---
>
> Key: SLING-6068
> URL: https://issues.apache.org/jira/browse/SLING-6068
> Project: Sling
>  Issue Type: Improvement
>  Components: Maven Plugins and Archetypes
>Affects Versions: Slingstart Maven Plugin 1.4.4
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Slingstart Maven Plugin 1.5.0
>
>
> Currently the {{slingstart-maven-plugin}} can only start a server based on 
> textual model definitions in case the maven module is of packaging 
> "slingstart" 
> (https://sling.apache.org/documentation/development/slingstart.html#starting-a-server).
>  
> For ITs it is often beneficial to have them in the same module as the tested 
> classes itself (which in most cases have packaging {{bundle}}). Therefore it 
> would be nice, if even for other packaging values all model definitions below 
> {{src/main/provisioning}} would be considered during the goal {{start}} 
> (which must first build the quickstart.jar out of the models and then start 
> it).
> Compare also with the readme in 
> https://github.com/apache/sling/blob/trunk/testing/samples/bundle-with-it/pom.xml#L196.
>  This would be especially helpful for ITs leveraging the {{TeleporterRule}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (SLING-6068) slingstart-maven-plugin: Allow to start a quickstart JAR based on a provisioning model even for non "slingstart" packagings

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler reopened SLING-6068:
-

It seems that something is broken now, if I update the launchpad project to use 
1.4.5-SNAPSHOT I get:
[ERROR] Failed to execute goal 
org.apache.sling:slingstart-maven-plugin:1.4.5-SNAPSHOT:start (start-container) 
on project org.apache.sling.launchpad: Could not find the launchpad jar. Either 
specify the 'launchpadJar' configuration or use this inside a slingstart 
project. -> [Help 1]
[

> slingstart-maven-plugin: Allow to start a quickstart JAR based on a 
> provisioning model even for non "slingstart" packagings
> ---
>
> Key: SLING-6068
> URL: https://issues.apache.org/jira/browse/SLING-6068
> Project: Sling
>  Issue Type: Improvement
>  Components: Maven Plugins and Archetypes
>Affects Versions: Slingstart Maven Plugin 1.4.4
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Slingstart Maven Plugin 1.5.0
>
>
> Currently the {{slingstart-maven-plugin}} can only start a server based on 
> textual model definitions in case the maven module is of packaging 
> "slingstart" 
> (https://sling.apache.org/documentation/development/slingstart.html#starting-a-server).
>  
> For ITs it is often beneficial to have them in the same module as the tested 
> classes itself (which in most cases have packaging {{bundle}}). Therefore it 
> would be nice, if even for other packaging values all model definitions below 
> {{src/main/provisioning}} would be considered during the goal {{start}} 
> (which must first build the quickstart.jar out of the models and then start 
> it).
> Compare also with the readme in 
> https://github.com/apache/sling/blob/trunk/testing/samples/bundle-with-it/pom.xml#L196.
>  This would be especially helpful for ITs leveraging the {{TeleporterRule}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6249) Move ServletResolverConstants to an exported package

[Konrad Windszus (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15644724#comment-15644724
 ] 

Konrad Windszus commented on SLING-6249:


For me all those constants are public API and therefore potentially interesting 
to consumers. They are documented at 
https://sling.apache.org/documentation/the-sling-engine/errorhandling.html and 
https://sling.apache.org/documentation/the-sling-engine/servlets.html#default-servlets.
If I e.g. want to bind my servlet to any resource type with a specific 
extension I need to use {{DEFAULT_SERVLET_NAME}}. The same for 
{{ERROR_HANDLER_PATH}}. I am just not sure about {{SLING_SERLVET_NAME}}. Except 
for the typo in the constant name it is also unclear what it is good for. I 
personally never used it or felt the need to overwrite the name. Where in the 
system are the servlet names exposed? I only understand how that could be 
relevant for classical servlet programming leveraging web.xmls 
(http://stackoverflow.com/questions/20073905/why-do-we-need-a-servlet-name).

> Move ServletResolverConstants to an exported package
> 
>
> Key: SLING-6249
> URL: https://issues.apache.org/jira/browse/SLING-6249
> Project: Sling
>  Issue Type: Improvement
>Affects Versions: Servlets Resolver 2.4.6
>Reporter: Konrad Windszus
>
> The constants being defined in 
> {{o.a.s.servlets.resolver.internal.ServletResolverConstants}} are not only 
> useful for the servlet resolver bundle itself but basically for every Sling 
> Servlet being defined without the custom Felix SCR annotations. Therefore it 
> would be good to move that to a package which is exported (and therefore part 
> of the public API). Although in reality all constant Strings are inline in 
> Java (which means that there should never be a runtime dependency towards 
> that class) it does not even appear in 
> http://sling.apache.org/apidocs/sling7/ nor in 
> https://sling.apache.org/apidocs/sling7/constant-values.html. Also the 
> constants are not part of the uber-jar being generated for the Sling API as 
> well for AEM 
> (https://docs.adobe.com/docs/en/aem/6-1/develop/dev-tools/ht-projects-maven.html#What%20is%20the%20UberJar?).
> This was first requested in 
> http://www.mail-archive.com/dev@sling.apache.org/msg45467.html and became 
> more important with the advent of OSGi 6 component annotations (see also 
> FELIX-5396).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6249) Move ServletResolverConstants to an exported package

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15644585#comment-15644585
 ] 

Carsten Ziegeler commented on SLING-6249:
-

[~kwin] I agree 1) is the cleanest option, however we should not move all 
constants to the API (DEFAULT_SERVLET_NAME, ERROR_HANDLER_PATH and 
DEFAULT_ERROR_HANDLER_NAME should probably stay private)

> Move ServletResolverConstants to an exported package
> 
>
> Key: SLING-6249
> URL: https://issues.apache.org/jira/browse/SLING-6249
> Project: Sling
>  Issue Type: Improvement
>Affects Versions: Servlets Resolver 2.4.6
>Reporter: Konrad Windszus
>
> The constants being defined in 
> {{o.a.s.servlets.resolver.internal.ServletResolverConstants}} are not only 
> useful for the servlet resolver bundle itself but basically for every Sling 
> Servlet being defined without the custom Felix SCR annotations. Therefore it 
> would be good to move that to a package which is exported (and therefore part 
> of the public API). Although in reality all constant Strings are inline in 
> Java (which means that there should never be a runtime dependency towards 
> that class) it does not even appear in 
> http://sling.apache.org/apidocs/sling7/ nor in 
> https://sling.apache.org/apidocs/sling7/constant-values.html. Also the 
> constants are not part of the uber-jar being generated for the Sling API as 
> well for AEM 
> (https://docs.adobe.com/docs/en/aem/6-1/develop/dev-tools/ht-projects-maven.html#What%20is%20the%20UberJar?).
> This was first requested in 
> http://www.mail-archive.com/dev@sling.apache.org/msg45467.html and became 
> more important with the advent of OSGi 6 component annotations (see also 
> FELIX-5396).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-6251) SCD integration tests fail due to blocked loginAdministrative

[Julian Sedding (JIRA)]

Julian Sedding created SLING-6251:
-

 Summary: SCD integration tests fail due to blocked 
loginAdministrative
 Key: SLING-6251
 URL: https://issues.apache.org/jira/browse/SLING-6251
 Project: Sling
  Issue Type: Task
  Components: Distribution
Reporter: Julian Sedding
Assignee: Julian Sedding


The Sling Content Distribution integration tests currently fail due to 
{{loginAdministrative}} being blocked.

The log files of the tested instances show messages like these:
{noformat}
02.11.2016 11:15:35.056 *ERROR* [qtp875477671-46] 
org.apache.sling.event.impl.jobs Unable to create new resource resolver: Bundle 
is not whitelisted for loginAdministrative:org.apache.sling.event
org.apache.sling.api.resource.LoginException: Bundle is not whitelisted for 
loginAdministrative:org.apache.sling.event
at 
org.apache.sling.jcr.resource.internal.helper.jcr.JcrProviderStateFactory.checkLoginAdminWhitelist(JcrProviderStateFactory.java:93)
at 
org.apache.sling.jcr.resource.internal.helper.jcr.JcrProviderStateFactory.createProviderState(JcrProviderStateFactory.java:111)
{noformat}

At least the Event bundle needs to be updated and the "Sling Distribution 
Sample" needs to be adjusted to refrain from using {{loginAdministrative}}.

cc [~teofili], [~simone.tripodi]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6249) Move ServletResolverConstants to an exported package

[Konrad Windszus (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15644550#comment-15644550
 ] 

Konrad Windszus commented on SLING-6249:


We have several options here
1) Move the class to the Sling API bundle to {{o.a.s.api.servlets}} and at the 
same time deprecate 
{{o.a.s.servlets.resolver.internal.ServletResolverConstants}}.
2) Leave it in the current bundle but move it to a package which is not an impl 
package and make sure this is exported in the resulting bundle and javadoc is 
being generated.  At the same time deprecate the same class in 
{{o.a.s.servlets.resolver.internal.ServletResolverConstants}}.
3) Leave it in the current bundle and in the current package and make sure that 
javadoc is being generated for the package 
{{o.a.s.servlets.resolver.internal}}. Still the class would not be exported (as 
the package is used by some other internal classes) and the javadoc would also 
contain some really internal classes.

Although option 3) is the quickest solution I personally would prefer the clean 
option 1). 
Once we have a release of Sling API with that class for some time we should 
switch to using those in bundle {{o.a.s.servlets.resolver}}.

[~cziegeler] WDYT, since you made did of the commits in that bundle?

> Move ServletResolverConstants to an exported package
> 
>
> Key: SLING-6249
> URL: https://issues.apache.org/jira/browse/SLING-6249
> Project: Sling
>  Issue Type: Improvement
>Affects Versions: Servlets Resolver 2.4.6
>Reporter: Konrad Windszus
>
> The constants being defined in 
> {{o.a.s.servlets.resolver.internal.ServletResolverConstants}} are not only 
> useful for the servlet resolver bundle itself but basically for every Sling 
> Servlet being defined without the custom Felix SCR annotations. Therefore it 
> would be good to move that to a package which is exported (and therefore part 
> of the public API). Although in reality all constant Strings are inline in 
> Java (which means that there should never be a runtime dependency towards 
> that class) it does not even appear in 
> http://sling.apache.org/apidocs/sling7/ nor in 
> https://sling.apache.org/apidocs/sling7/constant-values.html. Also the 
> constants are not part of the uber-jar being generated for the Sling API as 
> well for AEM 
> (https://docs.adobe.com/docs/en/aem/6-1/develop/dev-tools/ht-projects-maven.html#What%20is%20the%20UberJar?).
> This was first requested in 
> http://www.mail-archive.com/dev@sling.apache.org/msg45467.html and became 
> more important with the advent of OSGi 6 component annotations (see also 
> FELIX-5396).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-6249) Move ServletResolverConstants to an exported package

[Konrad Windszus (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus updated SLING-6249:
---
Description: 
The constants being defined in 
{{o.a.s.servlets.resolver.internal.ServletResolverConstants}} are not only 
useful for the servlet resolver bundle itself but basically for every Sling 
Servlet being defined without the custom Felix SCR annotations. Therefore it 
would be good to move that to a package which is exported (and therefore part 
of the public API). Although in reality all constant Strings are inline in Java 
(which means that there should never be a runtime dependency towards that 
class) it does not even appear in http://sling.apache.org/apidocs/sling7/ nor 
in https://sling.apache.org/apidocs/sling7/constant-values.html. Also the 
constants are not part of the uber-jar being generated for the Sling API as 
well for AEM 
(https://docs.adobe.com/docs/en/aem/6-1/develop/dev-tools/ht-projects-maven.html#What%20is%20the%20UberJar?).
This was first requested in 
http://www.mail-archive.com/dev@sling.apache.org/msg45467.html and became more 
important with the advent of OSGi 6 component annotations (see also FELIX-5396).

  was:
The constants being defined in 
{{o.a.s.servlets.resolver.internal.ServletResolverConstants}} are not only 
useful for the servlet resolver bundle itself but basically for every Sling 
Servlet being defined without the custom Felix SCR annotations. Therefore it 
would be good to move that to a package which is exported (and therefore part 
of the public API). Although in reality all constant Strings are inline in Java 
(which means that should never be a runtime dependency towards that class) 
currently the class does not even appear in 
http://sling.apache.org/apidocs/sling7/ nor in 
https://sling.apache.org/apidocs/sling7/constant-values.html. Also the 
constants are not part of the uber-jar being generated for the Sling API as 
well for AEM 
(https://docs.adobe.com/docs/en/aem/6-1/develop/dev-tools/ht-projects-maven.html#What%20is%20the%20UberJar?).
This was first requested in 
http://www.mail-archive.com/dev@sling.apache.org/msg45467.html and became more 
important with the advent of OSGi 6 component annotations (see also FELIX-5396).


> Move ServletResolverConstants to an exported package
> 
>
> Key: SLING-6249
> URL: https://issues.apache.org/jira/browse/SLING-6249
> Project: Sling
>  Issue Type: Improvement
>Affects Versions: Servlets Resolver 2.4.6
>Reporter: Konrad Windszus
>
> The constants being defined in 
> {{o.a.s.servlets.resolver.internal.ServletResolverConstants}} are not only 
> useful for the servlet resolver bundle itself but basically for every Sling 
> Servlet being defined without the custom Felix SCR annotations. Therefore it 
> would be good to move that to a package which is exported (and therefore part 
> of the public API). Although in reality all constant Strings are inline in 
> Java (which means that there should never be a runtime dependency towards 
> that class) it does not even appear in 
> http://sling.apache.org/apidocs/sling7/ nor in 
> https://sling.apache.org/apidocs/sling7/constant-values.html. Also the 
> constants are not part of the uber-jar being generated for the Sling API as 
> well for AEM 
> (https://docs.adobe.com/docs/en/aem/6-1/develop/dev-tools/ht-projects-maven.html#What%20is%20the%20UberJar?).
> This was first requested in 
> http://www.mail-archive.com/dev@sling.apache.org/msg45467.html and became 
> more important with the advent of OSGi 6 component annotations (see also 
> FELIX-5396).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6219) Allow to create users with repoinit

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15644487#comment-15644487
 ] 

Carsten Ziegeler commented on SLING-6219:
-

Added a first implementation for plain user creation / deletion

> Allow to create users with repoinit
> ---
>
> Key: SLING-6219
> URL: https://issues.apache.org/jira/browse/SLING-6219
> Project: Sling
>  Issue Type: New Feature
>  Components: JCR, Repoinit
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Repoinit Parser 1.0.4, Repoinit JCR 1.0.4
>
>
> it seems it's not possible to create a user through the repoinit. 
> This would be very useful for sample apps and testing. For example, the
> slingshot sample app currently needs an admin user to create the sample
> user accounts. And therefore slingshot needs to be in the whitelist for
> admin usage - which is not a good thing
> I suggest we add:
> create user {name}
> create user {name} {password}
> delete user {name}
> If no pw is provided for create user, we create a random pw



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6219) Allow to create users with repoinit

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15644475#comment-15644475
 ] 

Carsten Ziegeler commented on SLING-6219:
-

Thanks [~bdelacretaz] - how is the encoding / password combination intended to 
be passed on to Oak/Jackrabbit?

> Allow to create users with repoinit
> ---
>
> Key: SLING-6219
> URL: https://issues.apache.org/jira/browse/SLING-6219
> Project: Sling
>  Issue Type: New Feature
>  Components: JCR, Repoinit
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Repoinit Parser 1.0.4, Repoinit JCR 1.0.4
>
>
> it seems it's not possible to create a user through the repoinit. 
> This would be very useful for sample apps and testing. For example, the
> slingshot sample app currently needs an admin user to create the sample
> user accounts. And therefore slingshot needs to be in the whitelist for
> admin usage - which is not a good thing
> I suggest we add:
> create user {name}
> create user {name} {password}
> delete user {name}
> If no pw is provided for create user, we create a random pw



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (SLING-6219) Allow to create users with repoinit

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler reassigned SLING-6219:
---

Assignee: Carsten Ziegeler

> Allow to create users with repoinit
> ---
>
> Key: SLING-6219
> URL: https://issues.apache.org/jira/browse/SLING-6219
> Project: Sling
>  Issue Type: New Feature
>  Components: JCR, Repoinit
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Repoinit Parser 1.0.4, Repoinit JCR 1.0.4
>
>
> it seems it's not possible to create a user through the repoinit. 
> This would be very useful for sample apps and testing. For example, the
> slingshot sample app currently needs an admin user to create the sample
> user accounts. And therefore slingshot needs to be in the whitelist for
> admin usage - which is not a good thing
> I suggest we add:
> create user {name}
> create user {name} {password}
> delete user {name}
> If no pw is provided for create user, we create a random pw



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [repoinit] Creating users?

[Carsten Ziegeler]

Bertrand Delacretaz wrote
> On Mon, Nov 7, 2016 at 12:07 PM, Carsten Ziegeler  
> wrote:
>>> ... If someone can add the update to the grammar, I can definitely do the
>>> remaining part...
> 
> I'll have a look at the grammar part.
> 
Thanks Bertrand!


I'll try to get the remaining parts done

 Regards

Carsten

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

Re: Sling Content Distribiution - running integration tests vs loginAdministrative

[Julian Sedding]

Hi Bertrand

Thanks for the pointers. For the moment I have resorted to creating a
plain unit test for my issue. I hope I'll have time to investigate the
integration test again soon.

Regards
Julian


On Mon, Nov 7, 2016 at 1:33 PM, Bertrand Delacretaz
 wrote:
> Hi,
>
> On Mon, Nov 7, 2016 at 12:32 PM, Julian Sedding  wrote:
>> ...What I am missing so far is a way to inject my own provisioning model
>> (and ideally repoinit) into the launchpad I am starting in an
>> integration test
>
> It depends how you are starting the Sling instance that you use for
> testing, and unfortunately there are several flavors of that in our
> codebase.
>
> If you have existing test code and want to add a repoinit setup, the
> simplest might be to pass the output of a RepoInitParser to a
> JcrRepoInitOpsProcessor. in your test setup code after adding the
> corresponding bundles to your test instance.
>
> -Bertrand

[jira] [Updated] (SLING-6250) Importing packages with large headers fails

[Julian Sedding (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding updated SLING-6250:
--
Attachment: SLING-6250-testcase.patch

The attached patch adds a test case that allows to reproduce the issue.

> Importing packages with large headers fails
> ---
>
> Key: SLING-6250
> URL: https://issues.apache.org/jira/browse/SLING-6250
> Project: Sling
>  Issue Type: Bug
>  Components: Distribution
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Julian Sedding
>Assignee: Julian Sedding
> Attachments: SLING-6250-testcase.patch
>
>
> When importing packages with large headers, e.g. packages containing many 
> paths, the following exception is thrown:
> {noformat}
> java.lang.RuntimeException: java.io.IOException: Resetting to invalid mark
>   at java.io.BufferedInputStream.reset(BufferedInputStream.java:448)
>   at 
> org.apache.sling.distribution.packaging.impl.importer.LocalDistributionPackageImporter.importStream(LocalDistributionPackageImporter.java:122)
>   at 
> org.apache.sling.distribution.packaging.impl.importer.LocalDistributionPackageImporterTest.importPackageWithLargeHeader(LocalDistributionPackageImporterTest.java:100)
> {noformat}
> This happens when the header is larger than the default buffer size of the 
> {{BufferedInputStream}} and thus its {{#mark()}} is lost and {{#reset()}} 
> cannot happen anymore.
> I will investigate, whether we can stop relying on marked input streams. This 
> would be desirable, because we cannot know in advance how long the header is.
> cc [~teofili]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-6250) Importing packages with large headers fails

[Julian Sedding (JIRA)]

Julian Sedding created SLING-6250:
-

 Summary: Importing packages with large headers fails
 Key: SLING-6250
 URL: https://issues.apache.org/jira/browse/SLING-6250
 Project: Sling
  Issue Type: Bug
  Components: Distribution
Affects Versions: Content Distribution Core 0.1.18
Reporter: Julian Sedding
Assignee: Julian Sedding


When importing packages with large headers, e.g. packages containing many 
paths, the following exception is thrown:

{noformat}
java.lang.RuntimeException: java.io.IOException: Resetting to invalid mark
at java.io.BufferedInputStream.reset(BufferedInputStream.java:448)
at 
org.apache.sling.distribution.packaging.impl.importer.LocalDistributionPackageImporter.importStream(LocalDistributionPackageImporter.java:122)
at 
org.apache.sling.distribution.packaging.impl.importer.LocalDistributionPackageImporterTest.importPackageWithLargeHeader(LocalDistributionPackageImporterTest.java:100)
{noformat}

This happens when the header is larger than the default buffer size of the 
{{BufferedInputStream}} and thus its {{#mark()}} is lost and {{#reset()}} 
cannot happen anymore.

I will investigate, whether we can stop relying on marked input streams. This 
would be desirable, because we cannot know in advance how long the header is.

cc [~teofili]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Apache Sling Installer Core 3.8.0

[Daniel Klco]

+1

On Mon, Nov 7, 2016 at 5:12 AM, Antonio Sanso  wrote:

> +1
>
> On Nov 7, 2016, at 10:18 AM, Carsten Ziegeler 
> wrote:
>
> > Hi,
> >
> > We solved 2 issues in this release:
> > https://issues.apache.org/jira/browse/SLING/fixforversion/12338567
> >
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachesling-1563/
> >
> > 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 1563 /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.
> >
> > Regards
> > Carsten
> > --
> > Carsten Ziegeler
> > Adobe Research Switzerland
> > cziege...@apache.org
>
>

[jira] [Assigned] (SLING-6219) Allow to create users with repoinit

[Bertrand Delacretaz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bertrand Delacretaz reassigned SLING-6219:
--

Assignee: (was: Bertrand Delacretaz)

I have implemented the create/delete user grammar in revisions 1768509 and 
1768513.

See 
https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/repoinit/parser/src/test/resources/testcases/test-60.txt
 for the supported syntax.

To implement the actual JCR operations, a visitor similar to 
ServiceAndAclVisitor needs to be added in the bundles/jcr/repoinit module, with 
test cases similar to those which currently test service users.

Adding tests to bundles/extensions/repoinit/it might not be needed if coverage 
is sufficient in that jcr/repoinit module.

> Allow to create users with repoinit
> ---
>
> Key: SLING-6219
> URL: https://issues.apache.org/jira/browse/SLING-6219
> Project: Sling
>  Issue Type: New Feature
>  Components: JCR, Repoinit
>Reporter: Carsten Ziegeler
> Fix For: Repoinit Parser 1.0.4, Repoinit JCR 1.0.4
>
>
> it seems it's not possible to create a user through the repoinit. 
> This would be very useful for sample apps and testing. For example, the
> slingshot sample app currently needs an admin user to create the sample
> user accounts. And therefore slingshot needs to be in the whitelist for
> admin usage - which is not a good thing
> I suggest we add:
> create user {name}
> create user {name} {password}
> delete user {name}
> If no pw is provided for create user, we create a random pw



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Exporting ServletResolverConstants in org.apache.sling.servlets.resolver

[Konrad Windszus]

Since the constant also does not appear in the Javadoc and with the advent of 
OSGi 6 annotations it is more common to not use Felix SCR annotations I opened 
a ticket for moving this class somewhere else in 
https://issues.apache.org/jira/browse/SLING-6249 
.
Konrad

[jira] [Updated] (SLING-6249) Move ServletResolverConstants to an exported package

[Konrad Windszus (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus updated SLING-6249:
---
Summary: Move ServletResolverConstants to an exported package  (was: Move 
ServletResolverConstant to an exported package)

> Move ServletResolverConstants to an exported package
> 
>
> Key: SLING-6249
> URL: https://issues.apache.org/jira/browse/SLING-6249
> Project: Sling
>  Issue Type: Improvement
>Affects Versions: Servlets Resolver 2.4.6
>Reporter: Konrad Windszus
>
> The constants being defined in 
> {{o.a.s.servlets.resolver.internal.ServletResolverConstants}} are not only 
> useful for the servlet resolver bundle itself but basically for every Sling 
> Servlet being defined without the custom Felix SCR annotations. Therefore it 
> would be good to move that to a package which is exported (and therefore part 
> of the public API). Although in reality all constant Strings are inline in 
> Java (which means that should never be a runtime dependency towards that 
> class) currently the class does not even appear in 
> http://sling.apache.org/apidocs/sling7/ nor in 
> https://sling.apache.org/apidocs/sling7/constant-values.html. Also the 
> constants are not part of the uber-jar being generated for the Sling API as 
> well for AEM 
> (https://docs.adobe.com/docs/en/aem/6-1/develop/dev-tools/ht-projects-maven.html#What%20is%20the%20UberJar?).
> This was first requested in 
> http://www.mail-archive.com/dev@sling.apache.org/msg45467.html and became 
> more important with the advent of OSGi 6 component annotations (see also 
> FELIX-5396).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-6249) Move ServletResolverConstant to an exported package

[Konrad Windszus (JIRA)]

Konrad Windszus created SLING-6249:
--

 Summary: Move ServletResolverConstant to an exported package
 Key: SLING-6249
 URL: https://issues.apache.org/jira/browse/SLING-6249
 Project: Sling
  Issue Type: Improvement
Affects Versions: Servlets Resolver 2.4.6
Reporter: Konrad Windszus


The constants being defined in 
{{o.a.s.servlets.resolver.internal.ServletResolverConstants}} are not only 
useful for the servlet resolver bundle itself but basically for every Sling 
Servlet being defined without the custom Felix SCR annotations. Therefore it 
would be good to move that to a package which is exported (and therefore part 
of the public API). Although in reality all constant Strings are inline in Java 
(which means that should never be a runtime dependency towards that class) 
currently the class does not even appear in 
http://sling.apache.org/apidocs/sling7/ nor in 
https://sling.apache.org/apidocs/sling7/constant-values.html. Also the 
constants are not part of the uber-jar being generated for the Sling API as 
well for AEM 
(https://docs.adobe.com/docs/en/aem/6-1/develop/dev-tools/ht-projects-maven.html#What%20is%20the%20UberJar?).
This was first requested in 
http://www.mail-archive.com/dev@sling.apache.org/msg45467.html and became more 
important with the advent of OSGi 6 component annotations (see also FELIX-5396).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Sling Content Distribiution - running integration tests vs loginAdministrative

[Bertrand Delacretaz]

Hi,

On Mon, Nov 7, 2016 at 12:32 PM, Julian Sedding  wrote:
> ...What I am missing so far is a way to inject my own provisioning model
> (and ideally repoinit) into the launchpad I am starting in an
> integration test

It depends how you are starting the Sling instance that you use for
testing, and unfortunately there are several flavors of that in our
codebase.

If you have existing test code and want to add a repoinit setup, the
simplest might be to pass the output of a RepoInitParser to a
JcrRepoInitOpsProcessor. in your test setup code after adding the
corresponding bundles to your test instance.

-Bertrand

RE: [VOTE] Release Apache Sling Context-Aware Configuration SPI 1.1.0 and impl 1.1.0

[Stefan Seifert]

+1 

Re: Sling Content Distribiution - running integration tests vs loginAdministrative

[Julian Sedding]

Thanks Bertrand.

I know (a little) about both the provisioning model and the repoinit
feature. Your link [1] points to the launchpad, which as I understand
uses the provisioning model to bootstrap the instance.

What I am missing so far is a way to inject my own provisioning model
(and ideally repoinit) into the launchpad I am starting in an
integration test. Do you have any pointers to that?

Please also let me know if my understanding is flawed ;) Thanks.

Regards
Julian


On Mon, Nov 7, 2016 at 12:03 PM, Bertrand Delacretaz
 wrote:
> Hi Julian,
>
> On Mon, Nov 7, 2016 at 11:59 AM, Julian Sedding  wrote:
>> ...I am currently struggling to get the Sling Content Distribution ITs
>> (based on launchpad 9-SNAPSHOT) to run due to the blocked
>> loginAdministrative
>
> For tests you can configure a regexp for whitelisted bundles in the
> org.apache.sling.jcr.base.internal.LoginAdminWhitelistImpl config  as
> done in [1].
>
> If you need service users and ACLs in tests you can use the repoinit
> mechanism, [2]
>
> -Bertrand
>
> [1] 
> https://svn.apache.org/repos/asf/sling/trunk/launchpad/testing/src/main/provisioning/model.txt
> [2] 
> https://sling.apache.org/documentation/bundles/repository-initialization.html

[jira] [Assigned] (SLING-6219) Allow to create users with repoinit

[Bertrand Delacretaz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bertrand Delacretaz reassigned SLING-6219:
--

Assignee: Bertrand Delacretaz

I'll implement the grammar part.

> Allow to create users with repoinit
> ---
>
> Key: SLING-6219
> URL: https://issues.apache.org/jira/browse/SLING-6219
> Project: Sling
>  Issue Type: New Feature
>  Components: JCR, Repoinit
>Reporter: Carsten Ziegeler
>Assignee: Bertrand Delacretaz
> Fix For: Repoinit Parser 1.0.4, Repoinit JCR 1.0.4
>
>
> it seems it's not possible to create a user through the repoinit. 
> This would be very useful for sample apps and testing. For example, the
> slingshot sample app currently needs an admin user to create the sample
> user accounts. And therefore slingshot needs to be in the whitelist for
> admin usage - which is not a good thing
> I suggest we add:
> create user {name}
> create user {name} {password}
> delete user {name}
> If no pw is provided for create user, we create a random pw



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [repoinit] Creating users?

[Bertrand Delacretaz]

On Mon, Nov 7, 2016 at 12:07 PM, Carsten Ziegeler  wrote:
>>... If someone can add the update to the grammar, I can definitely do the
>> remaining part...

I'll have a look at the grammar part.

-Bertrand

Re: [repoinit] Creating users?

[Carsten Ziegeler]

Carsten Ziegeler wrote
> Carsten Ziegeler wrote
>> Hi,
>>
>> it seems it's not possible to create a user through the repoinit. Is
>> this intended to be added?
>>
>> This would be very useful for sample apps and testing. For example, the
>> slingshot sample app currently needs an admin user to create the sample
>> user accounts. And therefore slingshot needs to be in the whitelist for
>> admin usage - which is not a good thing
>>
> I'Ve created
> https://issues.apache.org/jira/browse/SLING-6219
> 
> for this
> 
> If someone can add the update to the grammar, I can definitely do the
> remaining part.
> 

Anyone able to help out? This is currently blocking using the Slingshot
sample application which in turn blocks Sling 9 Release

Thanks
Carsten

 

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

Re: Sling Content Distribiution - running integration tests vs loginAdministrative

[Bertrand Delacretaz]

Hi Julian,

On Mon, Nov 7, 2016 at 11:59 AM, Julian Sedding  wrote:
> ...I am currently struggling to get the Sling Content Distribution ITs
> (based on launchpad 9-SNAPSHOT) to run due to the blocked
> loginAdministrative

For tests you can configure a regexp for whitelisted bundles in the
org.apache.sling.jcr.base.internal.LoginAdminWhitelistImpl config  as
done in [1].

If you need service users and ACLs in tests you can use the repoinit
mechanism, [2]

-Bertrand

[1] 
https://svn.apache.org/repos/asf/sling/trunk/launchpad/testing/src/main/provisioning/model.txt
[2] 
https://sling.apache.org/documentation/bundles/repository-initialization.html

Sling Content Distribiution - running integration tests vs loginAdministrative

[Julian Sedding]

Hi all

I am currently struggling to get the Sling Content Distribution ITs
(based on launchpad 9-SNAPSHOT) to run due to the blocked
loginAdministrative. SCD provides a sample bundle that initializes
users and acls for the ITs in an SCR component using
loginAdministrative.

Now the obvious solution would be to change the sample project to
loginService. However, how do I then set up the service user and its
ACLs? Note that any manual intervention is impossible, because these
are fully automated integration tests.

Any pointer or help very much appreciated!

Regards
Julian

[jira] [Closed] (SLING-3926) Update to latest mime type definitions from httpd, remove inoffical custom ones

[Antonio Sanso (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-3926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Antonio Sanso closed SLING-3926.


> Update to latest mime type definitions from httpd, remove inoffical custom 
> ones
> ---
>
> Key: SLING-3926
> URL: https://issues.apache.org/jira/browse/SLING-3926
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Affects Versions: Commons Mime 2.1.8
>Reporter: Stefan Seifert
>Priority: Minor
>  Labels: mime
> Fix For: Commons Mime 2.1.10
>
>
> the mime type services contains a quite old mime type definition from httpd 
> server from 2009:
> http://svn.apache.org/repos/asf/httpd/httpd/tags/2.2.14/docs/conf/mime.types
> this should be updated to the latest version
> http://svn.apache.org/repos/asf/httpd/httpd/tags/2.4.10/docs/conf/mime.types
> this new version brings a lot of nowadays used new mime types, e.g. for woff, 
> otf etc.
> additionally there are some custom mime type extensions to this list that are 
> not valid (not the official ones, and are replaced with the official ones in 
> the httpd version):
> {noformat}
> application/msexcelxls xlsx
> application/mspowerpoint   ppt pptx
> application/octet-stream   class exe msi
> application/photoshop  psd
> text/rtf   rtf
> {noformat}
> they should be removed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Apache Sling Context-Aware Configuration SPI 1.1.0 and impl 1.1.0

[Carsten Ziegeler]

+1

 

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

[jira] [Closed] (SLING-6222) [Startup ERROR] org.apache.sling.commons.mime FrameworkEvent ERROR (The bundle is uninstalled.)

[Antonio Sanso (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Antonio Sanso closed SLING-6222.


> [Startup ERROR] org.apache.sling.commons.mime FrameworkEvent ERROR (The 
> bundle is uninstalled.)
> ---
>
> Key: SLING-6222
> URL: https://issues.apache.org/jira/browse/SLING-6222
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Reporter: Antonio Sanso
>Assignee: Antonio Sanso
>Priority: Minor
> Fix For: Commons Mime 2.1.10
>
>
> During startup, the following ERROR randomly appears in the logs:
> {code}
> 25.10.2016 07:57:53.712 *ERROR* [FelixDispatchQueue] 
> org.apache.sling.commons.mime FrameworkEvent ERROR 
> (java.lang.IllegalStateException: The bundle is uninstalled.)
> java.lang.IllegalStateException: The bundle is uninstalled.
>   at org.apache.felix.framework.Felix.getBundleEntry(Felix.java:1741)
>   at org.apache.felix.framework.BundleImpl.getEntry(BundleImpl.java:291)
>   at 
> org.apache.sling.commons.mime.internal.MimeTypeServiceImpl.bundleChanged(MimeTypeServiceImpl.java:249)
>   at 
> org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:916)
>   at 
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:835)
>   at 
> org.apache.felix.framework.util.EventDispatcher.run(EventDispatcher.java:1148)
>   at 
> org.apache.felix.framework.util.EventDispatcher.access$000(EventDispatcher.java:55)
>   at 
> org.apache.felix.framework.util.EventDispatcher$1.run(EventDispatcher.java:103)
>   at java.lang.Thread.run(Thread.java:745)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[VOTE] Release Apache Sling Context-Aware Configuration SPI 1.1.0 and impl 1.1.0

[Carsten Ziegeler]

Hi,

We solved 1 issue in the SPI
https://issues.apache.org/jira/browse/SLING/fixforversion/12338441

We solved 6 issues in the impl:
https://issues.apache.org/jira/browse/SLING/fixforversion/12338443

Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-1565/

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 1565 /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.

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

[jira] [Updated] (SLING-6137) Context-Aware Config: Configuration Manager - Support resource collection and property inheritance

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler updated SLING-6137:

Fix Version/s: (was: Context-Aware Configuration Impl 1.1.0)
   Context-Aware Configuration Impl 1.1.2

> Context-Aware Config: Configuration Manager - Support resource collection and 
> property inheritance
> --
>
> Key: SLING-6137
> URL: https://issues.apache.org/jira/browse/SLING-6137
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Stefan Seifert
>Priority: Minor
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration Impl 1.1.2
>
>
> the ConfigurationManager interface that is part of the "management API" 
> dedicated for tooling support like configuration editors should support 
> providing information about inherited configuration data (resource 
> collections, properties) as well to be able to visualize this information.
> this may be usable for a configuration editor and the web console 
> (SLING-6115) as well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-6155) Context-Aware Config: Integration Test unstable on Apache Jenkins

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler updated SLING-6155:

Fix Version/s: (was: Context-Aware Configuration Impl 1.1.0)
   Context-Aware Configuration Impl 1.1.2

> Context-Aware Config: Integration Test unstable on Apache Jenkins
> -
>
> Key: SLING-6155
> URL: https://issues.apache.org/jira/browse/SLING-6155
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Stefan Seifert
>Priority: Minor
>  Labels: contextaware-config, integration-test
> Fix For: Context-Aware Configuration Impl 1.1.2
>
>
> the integration tests for context-aware config are currently flaky for java 
> 1.7 (but run smooth with java 1.8). i cannot reproduce the problem when 
> running them locally with java 1.7.
> example: 
> https://builds.apache.org/job/sling-contrib-extensions-contextaware-config-integration-tests-1.7/11/console
> seems to be a startup racing condition with getting the resource 
> resolver/root resource.
> {noformat}
> Results :
> Tests in error: 
>   AdaptToConfigClassIT.setUp:54 » IllegalState Cannot read root resource
>   ConfigurationManagerIT.setUp:69 » IllegalState Cannot read root resource
>   ConfigurationManagerIT.setUp:69 » IllegalState Cannot read root resource
>   ConfigurationManagerIT.setUp:69 » IllegalState Cannot read root resource
>   ConfigurationManagerIT.setUp:69 » IllegalState Cannot read root resource
> org.apache.sling.contextaware.config.it.ConfigurationResolverConfigClassIT.testExistingConfig(org.apache.sling.contextaware.config.it.ConfigurationResolverConfigClassIT)
>   Run 1: ConfigurationResolverConfigClassIT.setUp:53 » IllegalState unable to 
> get a ser...
>   Run 2: ConfigurationResolverConfigClassIT.tearDown:59 » NullPointer
> org.apache.sling.contextaware.config.it.ConfigurationResolverConfigClassIT.testNonExistingConfig(org.apache.sling.contextaware.config.it.ConfigurationResolverConfigClassIT)
>   Run 1: ConfigurationResolverConfigClassIT.setUp:53 » IllegalState unable to 
> get a ser...
>   Run 2: ConfigurationResolverConfigClassIT.tearDown:59 » NullPointer
> org.apache.sling.contextaware.config.it.ConfigurationResolverValueMapIT.testExistingConfig(org.apache.sling.contextaware.config.it.ConfigurationResolverValueMapIT)
>   Run 1: ConfigurationResolverValueMapIT.setUp:53 » IllegalState unable to 
> get a servic...
>   Run 2: ConfigurationResolverValueMapIT.tearDown:59 » NullPointer
> org.apache.sling.contextaware.config.it.ConfigurationResolverValueMapIT.testNonExistingConfig(org.apache.sling.contextaware.config.it.ConfigurationResolverValueMapIT)
>   Run 1: ConfigurationResolverValueMapIT.setUp:53 » IllegalState unable to 
> get a servic...
>   Run 2: ConfigurationResolverValueMapIT.tearDown:59 » NullPointer
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-6115) Context-Aware Config: Web Console Plugin

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler updated SLING-6115:

Fix Version/s: (was: Context-Aware Configuration Impl 1.1.0)
   Context-Aware Configuration Impl 1.1.2

> Context-Aware Config: Web Console Plugin
> 
>
> Key: SLING-6115
> URL: https://issues.apache.org/jira/browse/SLING-6115
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Priority: Minor
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration Impl 1.1.2
>
>
> with the first implementation prototype a web console plugin was included 
> which can be used to test/debug configuration resource resolution.
> it was not maintained properly during all the refactoring and new features 
> that were added since then, thus is quite broken currently.
> the web console plugin has to be refactored and fixed, and perhaps enhanced 
> to support the new features as well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-6060) Context-Aware Config: Configuration property override providers

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler updated SLING-6060:

Fix Version/s: (was: Context-Aware Configuration Impl 1.1.0)
   (was: Context-Aware Configuration SPI 1.1.0)
   Context-Aware Configuration Impl 1.1.2
   Context-Aware Configuration SPI 1.1.2

> Context-Aware Config: Configuration property override providers
> ---
>
> Key: SLING-6060
> URL: https://issues.apache.org/jira/browse/SLING-6060
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Stefan Seifert
>Priority: Minor
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration SPI 1.1.2, Context-Aware 
> Configuration Impl 1.1.2
>
>
> add support similar to http://wcm.io/config/core/override-providers.html
> this is esp. useful for test/QA systems where a bunch of content and 
> configuration packages are imported from the production system, and only a 
> few of them need to be overwritten e.g. ip addresses, host names.
> these override providers should not be active by default. perhaps they should 
> go into a separate package - but we need the SPI for them in the core 
> implementation.
> this is somewhat related to SLING-6058
> information about overriding that is in place should be provided in the 
> Configuration Management API (ConfigurationManager) as well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Apache Sling Installer Core 3.8.0

[Antonio Sanso]

+1

On Nov 7, 2016, at 10:18 AM, Carsten Ziegeler  wrote:

> Hi,
> 
> We solved 2 issues in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12338567
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1563/
> 
> 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 1563 /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.
> 
> Regards
> Carsten
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

[jira] [Resolved] (SLING-6244) Provide an SPI for influencing the collection inheritance

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler resolved SLING-6244.
-
Resolution: Fixed

Thanks [~sseif...@pro-vision.de]

> Provide an SPI for influencing the collection inheritance
> -
>
> Key: SLING-6244
> URL: https://issues.apache.org/jira/browse/SLING-6244
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Context-Aware Configuration SPI 1.0.2, Context-Aware 
> Configuration Impl 1.0.2
>
>
> Currently there is no way to influence the inheritance for collections as for 
> example being implemented in DefaultConfigurationResourceResolvingStrategy
> We should provide an SPI which can be used by all strategy implementations:
> interface CollectionInheritanceDecider {
>enum DECISION {
>   INCLUDE,
>   EXCLUDE,
>   BLOCK
>}
>DECISION decide(String bucketName, Resource resource);
> }
> So for every item found in getResourceCollection this optional service
> is asked. If it returns INCLUDE the resource is included, if it returns
> EXCLUDE it is excluded, but a parent can provide this resource. If it
> returns BLOCK, it's excluded and no parent can provide this resource.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6244) Provide an SPI for influencing the collection inheritance

[Stefan Seifert (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15643692#comment-15643692
 ] 

Stefan Seifert commented on SLING-6244:
---

Completed: At revision: 1768474  

use @CheckForNull for return value

> Provide an SPI for influencing the collection inheritance
> -
>
> Key: SLING-6244
> URL: https://issues.apache.org/jira/browse/SLING-6244
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Context-Aware Configuration SPI 1.0.2, Context-Aware 
> Configuration Impl 1.0.2
>
>
> Currently there is no way to influence the inheritance for collections as for 
> example being implemented in DefaultConfigurationResourceResolvingStrategy
> We should provide an SPI which can be used by all strategy implementations:
> interface CollectionInheritanceDecider {
>enum DECISION {
>   INCLUDE,
>   EXCLUDE,
>   BLOCK
>}
>DECISION decide(String bucketName, Resource resource);
> }
> So for every item found in getResourceCollection this optional service
> is asked. If it returns INCLUDE the resource is included, if it returns
> EXCLUDE it is excluded, but a parent can provide this resource. If it
> returns BLOCK, it's excluded and no parent can provide this resource.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[RESULT] [VOTE] Release Apache Sling MIME type mapping support 2.1.10

[Antonio Sanso]

The vote passed with 4 binding +1s

regards

antonio

[jira] [Commented] (SLING-6244) Provide an SPI for influencing the collection inheritance

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15643685#comment-15643685
 ] 

Carsten Ziegeler commented on SLING-6244:
-

Updated impl in rev 1768473

> Provide an SPI for influencing the collection inheritance
> -
>
> Key: SLING-6244
> URL: https://issues.apache.org/jira/browse/SLING-6244
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Context-Aware Configuration SPI 1.0.2, Context-Aware 
> Configuration Impl 1.0.2
>
>
> Currently there is no way to influence the inheritance for collections as for 
> example being implemented in DefaultConfigurationResourceResolvingStrategy
> We should provide an SPI which can be used by all strategy implementations:
> interface CollectionInheritanceDecider {
>enum DECISION {
>   INCLUDE,
>   EXCLUDE,
>   BLOCK
>}
>DECISION decide(String bucketName, Resource resource);
> }
> So for every item found in getResourceCollection this optional service
> is asked. If it returns INCLUDE the resource is included, if it returns
> EXCLUDE it is excluded, but a parent can provide this resource. If it
> returns BLOCK, it's excluded and no parent can provide this resource.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6244) Provide an SPI for influencing the collection inheritance

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15643681#comment-15643681
 ] 

Carsten Ziegeler commented on SLING-6244:
-

Updated the SPI to handle multiple deciders in rev 1768471

> Provide an SPI for influencing the collection inheritance
> -
>
> Key: SLING-6244
> URL: https://issues.apache.org/jira/browse/SLING-6244
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Context-Aware Configuration SPI 1.0.2, Context-Aware 
> Configuration Impl 1.0.2
>
>
> Currently there is no way to influence the inheritance for collections as for 
> example being implemented in DefaultConfigurationResourceResolvingStrategy
> We should provide an SPI which can be used by all strategy implementations:
> interface CollectionInheritanceDecider {
>enum DECISION {
>   INCLUDE,
>   EXCLUDE,
>   BLOCK
>}
>DECISION decide(String bucketName, Resource resource);
> }
> So for every item found in getResourceCollection this optional service
> is asked. If it returns INCLUDE the resource is included, if it returns
> EXCLUDE it is excluded, but a parent can provide this resource. If it
> returns BLOCK, it's excluded and no parent can provide this resource.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6244) Provide an SPI for influencing the collection inheritance

[Stefan Seifert (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15643660#comment-15643660
 ] 

Stefan Seifert commented on SLING-6244:
---

bq. So we would call the services in service ranking order (highest first), the 
first one returning a non null value is used for the decision
yes

> Provide an SPI for influencing the collection inheritance
> -
>
> Key: SLING-6244
> URL: https://issues.apache.org/jira/browse/SLING-6244
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Context-Aware Configuration SPI 1.0.2, Context-Aware 
> Configuration Impl 1.0.2
>
>
> Currently there is no way to influence the inheritance for collections as for 
> example being implemented in DefaultConfigurationResourceResolvingStrategy
> We should provide an SPI which can be used by all strategy implementations:
> interface CollectionInheritanceDecider {
>enum DECISION {
>   INCLUDE,
>   EXCLUDE,
>   BLOCK
>}
>DECISION decide(String bucketName, Resource resource);
> }
> So for every item found in getResourceCollection this optional service
> is asked. If it returns INCLUDE the resource is included, if it returns
> EXCLUDE it is excluded, but a parent can provide this resource. If it
> returns BLOCK, it's excluded and no parent can provide this resource.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

RE: [VOTE] Release Apache Sling Installer Core 3.8.0

[Stefan Seifert]

+1 

RE: [VOTE] Release Apache Sling Provisioning Model 1.6.0

[Stefan Seifert]

+1 

RE: [VOTE] Release Apache Sling Resource Resolver 1.5.2

[Stefan Seifert]

+1 

[jira] [Commented] (SLING-6244) Provide an SPI for influencing the collection inheritance

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15643644#comment-15643644
 ] 

Carsten Ziegeler commented on SLING-6244:
-

[~sseif...@pro-vision.de] Yes, I think having multiple implementations makes 
sense as there could be different implementations for different buckets.
So we would call the services in service ranking order (highest first), the 
first one returning a non null value is used for the decision

> Provide an SPI for influencing the collection inheritance
> -
>
> Key: SLING-6244
> URL: https://issues.apache.org/jira/browse/SLING-6244
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Context-Aware Configuration SPI 1.0.2, Context-Aware 
> Configuration Impl 1.0.2
>
>
> Currently there is no way to influence the inheritance for collections as for 
> example being implemented in DefaultConfigurationResourceResolvingStrategy
> We should provide an SPI which can be used by all strategy implementations:
> interface CollectionInheritanceDecider {
>enum DECISION {
>   INCLUDE,
>   EXCLUDE,
>   BLOCK
>}
>DECISION decide(String bucketName, Resource resource);
> }
> So for every item found in getResourceCollection this optional service
> is asked. If it returns INCLUDE the resource is included, if it returns
> EXCLUDE it is excluded, but a parent can provide this resource. If it
> returns BLOCK, it's excluded and no parent can provide this resource.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6244) Provide an SPI for influencing the collection inheritance

[Stefan Seifert (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15643631#comment-15643631
 ] 

Stefan Seifert commented on SLING-6244:
---

Completed: At revision: 1768465  

i've slightly changed the SPI method signature (swap parameter order) to make 
it consistent with ConfigurationResourceResolvingStrategy, and added @NotNull 
annotations.

question: should we support multiple SPI implementations via multiplexer here 
as well? then we have to allow null as return value, and support multiple 
services. maybe there are different deciders for different bucket names.

> Provide an SPI for influencing the collection inheritance
> -
>
> Key: SLING-6244
> URL: https://issues.apache.org/jira/browse/SLING-6244
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Context-Aware Configuration SPI 1.0.2, Context-Aware 
> Configuration Impl 1.0.2
>
>
> Currently there is no way to influence the inheritance for collections as for 
> example being implemented in DefaultConfigurationResourceResolvingStrategy
> We should provide an SPI which can be used by all strategy implementations:
> interface CollectionInheritanceDecider {
>enum DECISION {
>   INCLUDE,
>   EXCLUDE,
>   BLOCK
>}
>DECISION decide(String bucketName, Resource resource);
> }
> So for every item found in getResourceCollection this optional service
> is asked. If it returns INCLUDE the resource is included, if it returns
> EXCLUDE it is excluded, but a parent can provide this resource. If it
> returns BLOCK, it's excluded and no parent can provide this resource.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Apache Sling Installer Core 3.8.0

[Carsten Ziegeler]

+1

 

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

[VOTE] Release Apache Sling Installer Core 3.8.0

[Carsten Ziegeler]

Hi,

We solved 2 issues in this release:
https://issues.apache.org/jira/browse/SLING/fixforversion/12338567

Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-1563/

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 1563 /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.

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