date:20200824



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

Oliver Lietz resolved SLING-9359.
-
Resolution: Done

> Provide Installer Factory Configuration Option
> --
>
> Key: SLING-9359
> URL: https://issues.apache.org/jira/browse/SLING-9359
> Project: Sling
>  Issue Type: New Feature
>  Components: Testing
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>Priority: Major
> Fix For: Testing PaxExam 3.1.2
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (SLING-9360) Provide Installer Factory Packages Option



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

Oliver Lietz resolved SLING-9360.
-
Resolution: Done

> Provide Installer Factory Packages Option
> -
>
> Key: SLING-9360
> URL: https://issues.apache.org/jira/browse/SLING-9360
> Project: Sling
>  Issue Type: New Feature
>  Components: Testing
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>Priority: Major
> Fix For: Testing PaxExam 3.1.2
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Reopened] (SLING-9686) Update project badges to point to ci-builds.apache.org



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

Oliver Lietz reopened SLING-9686:
-

Check and fix broken {{README}}s.

> Update project badges to point to ci-builds.apache.org
> --
>
> Key: SLING-9686
> URL: https://issues.apache.org/jira/browse/SLING-9686
> Project: Sling
>  Issue Type: Improvement
>  Components: Tooling
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
>
> The project badges from their {{README.md}} files should point to the new CI 
> server.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[Jenkins] Sling » Modules » sling-org-apache-sling-launchpad-testing » master #52 is BROKEN

Please see 
https://ci-builds.apache.org/job/Sling/job/modules/job/sling-org-apache-sling-launchpad-testing/job/master/52/
 for details.

No further emails will be sent until the status of the build is changed.
Build log follows below:

[...truncated 1545 lines...]
[INFO] Tests run: 15, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.856 s 
- in 
org.apache.sling.launchpad.webapp.integrationtest.servlets.post.PostServletMoveTest
[INFO] Running 
org.apache.sling.launchpad.webapp.integrationtest.userManager.CreateUserTest
[INFO] Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.439 s 
- in 
org.apache.sling.launchpad.webapp.integrationtest.userManager.CreateUserTest
[INFO] Running org.apache.sling.launchpad.webapp.integrationtest.crud.CrudTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.279 s 
- in org.apache.sling.launchpad.webapp.integrationtest.crud.CrudTest
[INFO] Running 
org.apache.sling.launchpad.webapp.integrationtest.WebdavDeleteTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.191 s 
- in org.apache.sling.launchpad.webapp.integrationtest.WebdavDeleteTest
[INFO] Running 
org.apache.sling.launchpad.webapp.integrationtest.DavExDisabledAnonAccessTest
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.396 s 
- in 
org.apache.sling.launchpad.webapp.integrationtest.DavExDisabledAnonAccessTest
[INFO] Running org.apache.sling.launchpad.webapp.integrationtest.JspForwardTest
[INFO] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.379 s 
- in org.apache.sling.launchpad.webapp.integrationtest.JspForwardTest
[INFO] Running 
org.apache.sling.launchpad.webapp.integrationtest.repository.RepositoryInitializersTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 s 
- in 
org.apache.sling.launchpad.webapp.integrationtest.repository.RepositoryInitializersTest
[INFO] Running 
org.apache.sling.launchpad.webapp.integrationtest.repository.RepoinitPathTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.197 s 
- in 
org.apache.sling.launchpad.webapp.integrationtest.repository.RepoinitPathTest
[INFO] Running 
org.apache.sling.launchpad.webapp.integrationtest.repository.SystemUsersTest
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.236 s 
- in 
org.apache.sling.launchpad.webapp.integrationtest.repository.SystemUsersTest
[INFO] Running 
org.apache.sling.launchpad.webapp.integrationtest.repository.RepositoryNameTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.027 s 
- in 
org.apache.sling.launchpad.webapp.integrationtest.repository.RepositoryNameTest
[INFO] Running 
org.apache.sling.launchpad.webapp.integrationtest.NodeTypeBasedRenderingTest
[INFO] Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.307 s 
- in 
org.apache.sling.launchpad.webapp.integrationtest.NodeTypeBasedRenderingTest
[INFO] Running 
org.apache.sling.launchpad.webapp.integrationtest.SlingResourceTypeRenderingTest
[INFO] Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.202 s 
- in 
org.apache.sling.launchpad.webapp.integrationtest.SlingResourceTypeRenderingTest
[INFO] Running org.apache.sling.launchpad.webapp.integrationtest.EspLoadTest
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.354 s 
- in org.apache.sling.launchpad.webapp.integrationtest.EspLoadTest
[INFO] Running 
org.apache.sling.launchpad.webapp.integrationtest.StaticContentTest
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 s 
- in org.apache.sling.launchpad.webapp.integrationtest.StaticContentTest
[INFO] Running 
org.apache.sling.launchpad.webapp.integrationtest.login.AuthRequestLoginTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.045 s 
- in 
org.apache.sling.launchpad.webapp.integrationtest.login.AuthRequestLoginTest
[INFO] Running 
org.apache.sling.launchpad.webapp.integrationtest.resourceprovider.PlanetsResourceProviderTest
[INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.046 s 
- in 
org.apache.sling.launchpad.webapp.integrationtest.resourceprovider.PlanetsResourceProviderTest
[INFO] Running 
org.apache.sling.launchpad.webapp.integrationtest.teleporter.TeleporterOptionsTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 s - in 
org.apache.sling.launchpad.webapp.integrationtest.teleporter.TeleporterOptionsTest
[INFO] Running 
org.apache.sling.launchpad.webapp.integrationtest.DavExIntegrationTest
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.224 s 
- in org.apache.sling.launchpad.webapp.integrationtest.DavExIntegrationTest
[INFO] Running 
org.apache.sling.launchpad.webapp.integrationtest.servlets.resolution.SelectorServletTest
[INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.566 s 
- in

[Jenkins] Sling » Modules » sling-org-apache-sling-launchpad-testing » master #51 is FIXED

Please see 
https://ci-builds.apache.org/job/Sling/job/modules/job/sling-org-apache-sling-launchpad-testing/job/master/51/
 for details.

No further emails will be sent until the status of the build is changed.

[GitHub] [sling-org-apache-sling-launchpad-integration-tests] sonarcloud[bot] commented on pull request #1: [SLING-9417] Added test for an nt:file child of a versioned node



sonarcloud[bot] commented on pull request #1:
URL: 
https://github.com/apache/sling-org-apache-sling-launchpad-integration-tests/pull/1#issuecomment-679404970


   SonarCloud Quality Gate failed.
   
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=BUG)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=BUG)
 [0 
Bugs](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=BUG)
  
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=VULNERABILITY)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=VULNERABILITY)
 [0 
Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=VULNERABILITY)
 (and [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launch
 pad-integration-tests=1=false=SECURITY_HOTSPOT) [0 
Security 
Hotspots](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=SECURITY_HOTSPOT)
 to review)  
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=CODE_SMELL)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=CODE_SMELL)
 [0 Code 
Smells](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=CODE_SMELL)
   
   [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=new_coverage=list)
 [0.0% 
Coverage](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=new_coverage=list)
  
   [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=new_duplicated_lines_density=list)
 [0.0% 
Duplication](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=new_duplicated_lines_density=list)
   
The version of Java (1.8.0_252) you 
have used to run this analysis is deprecated and we will stop accepting it from 
October 2020. Please update to at least Java 11.
   Read more [here](https://sonarcloud.io/documentation/upcoming/)
   
   
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [sling-org-apache-sling-launchpad-integration-tests] sonarcloud[bot] removed a comment on pull request #1: [SLING-9417] Added test for an nt:file child of a versioned node



sonarcloud[bot] removed a comment on pull request #1:
URL: 
https://github.com/apache/sling-org-apache-sling-launchpad-integration-tests/pull/1#issuecomment-679298315


   SonarCloud Quality Gate failed.
   
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=BUG)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=BUG)
 [0 
Bugs](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=BUG)
  
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=VULNERABILITY)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=VULNERABILITY)
 [0 
Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=VULNERABILITY)
 (and [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launch
 pad-integration-tests=1=false=SECURITY_HOTSPOT) [0 
Security 
Hotspots](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=SECURITY_HOTSPOT)
 to review)  
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=CODE_SMELL)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=CODE_SMELL)
 [0 Code 
Smells](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=CODE_SMELL)
   
   [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=new_coverage=list)
 [0.0% 
Coverage](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=new_coverage=list)
  
   [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=new_duplicated_lines_density=list)
 [0.0% 
Duplication](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=new_duplicated_lines_density=list)
   
The version of Java (1.8.0_252) you 
have used to run this analysis is deprecated and we will stop accepting it from 
October 2020. Please update to at least Java 11.
   Read more [here](https://sonarcloud.io/documentation/upcoming/)
   
   
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[Jenkins] Sling » Modules » sling-org-apache-sling-launchpad-testing » master #48 is FIXED

Please see 
https://ci-builds.apache.org/job/Sling/job/modules/job/sling-org-apache-sling-launchpad-testing/job/master/48/
 for details.

No further emails will be sent until the status of the build is changed.

[Jenkins] Sling » Modules » sling-org-apache-sling-launchpad-testing » master #49 is BROKEN

 : org.apache.sling.engine:2.7.2 
ref=[javax.servlet.Servlet] properties={objectClass=[javax.servlet.Servlet], 
osgi.http.whiteboard.context.select=(osgi.http.whiteboard.context.name=org.apache.sling),
 osgi.http.whiteboard.servlet.name=ApacheSling/2.7, 
osgi.http.whiteboard.servlet.pattern=/, service.bundleid=124, 
service.description=Apache Sling Engine Main Servlet, service.id=411, 
service.scope=singleton, service.vendor=The Apache Software Foundation}] 
Ignoring unmatching Servlet service
[DEBUG] [ServiceReference 427 from bundle 124 : org.apache.sling.engine:2.7.2 
ref=[javax.servlet.Filter] properties={component.id=218, 
component.name=org.apache.sling.engine.impl.log.RequestLoggerFilter, 
objectClass=[javax.servlet.Filter], 
osgi.http.whiteboard.context.select=(osgi.http.whiteboard.context.name=org.apache.sling),
 osgi.http.whiteboard.filter.pattern=[/], service.bundleid=124, 
service.description=Request Logger Filter, service.id=427, 
service.ranking=32768, service.scope=bundle, service.vendor=The Apache Software 
Foundation}] Ignoring unmatching Filter service
[DEBUG] [ServiceReference 430 from bundle 124 : org.apache.sling.engine:2.7.2 
ref=[javax.servlet.Filter] properties={component.id=219, 
component.name=org.apache.sling.engine.parameters, file.max=-1, 
file.threshold=256000, objectClass=[javax.servlet.Filter], 
osgi.http.whiteboard.context.select=(osgi.http.whiteboard.context.name=org.apache.sling),
 osgi.http.whiteboard.filter.pattern=[/], request.max=-1, service.bundleid=124, 
service.description=Filter for request parameter support, service.id=430, 
service.ranking=2147483647, service.scope=bundle, service.vendor=The Apache 
Software Foundation, sling.default.max.parameters=1, 
sling.default.parameter.checkForAdditionalContainerParameters=false, 
sling.default.parameter.encoding=ISO-8859-1}] Ignoring unmatching Filter service
[INFO] Apachde Felix Http Whiteboard Service stopped
[INFO] Stopped Jetty.
[INFO] 
[INFO] --- ianal-maven-plugin:1.0-alpha-1:verify-legal-files (default) @ 
org.apache.sling.launchpad.testing ---
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by 
org.codehaus.groovy.reflection.CachedConstructor 
(file:/home/jenkins/.m2/repository/org/codehaus/groovy/groovy-all-minimal/1.5.6/groovy-all-minimal-1.5.6.jar)
 to constructor java.io.File(java.lang.String,java.io.File)
WARNING: Please consider reporting this to the maintainers of 
org.codehaus.groovy.reflection.CachedConstructor
WARNING: Use --illegal-access=warn to enable warnings of further illegal 
reflective access operations
WARNING: All illegal access operations will be denied in a future release
[INFO] Checking legal files in: 
org.apache.sling.launchpad.testing-12-SNAPSHOT.jar
[INFO] Checking legal files in: 
org.apache.sling.launchpad.testing-12-SNAPSHOT-sources.jar
[INFO] 
[INFO] --- apache-rat-plugin:0.11:check (default) @ 
org.apache.sling.launchpad.testing ---
[INFO] 51 implicit excludes (use -debug for more details).
[INFO] Exclude: DEPENDENCIES
[INFO] Exclude: src/main/appended-resources/META-INF/*
[INFO] Exclude: velocity.log
[INFO] Exclude: target/*
[INFO] Exclude: README.md
[INFO] Exclude: maven-eclipse.xml
[INFO] Exclude: .*
[INFO] Exclude: .*/**
[INFO] Exclude: **/*.json
[INFO] Exclude: DEPENDENCIES
[INFO] Exclude: **/*.rej
[INFO] Exclude: hs_err_*.log
[INFO] Exclude: **/repository/index/*/index-details.txt
[INFO] Exclude: bnd.bnd
[INFO] 6 resources included (use -debug for more details)
[INFO] Rat check: Summary of files. Unapproved: 0 unknown: 0 generated: 0 
approved: 5 licence.
[INFO] 
[INFO] --- maven-failsafe-plugin:2.21.0:verify (default) @ 
org.apache.sling.launchpad.testing ---
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time:  03:12 min
[INFO] Finished at: 2020-08-24T22:37:27Z
[INFO] 
[INFO] [jenkins-event-spy] Generated 
/home/jenkins/jenkins-agent/workspace/e-sling-launchpad-testing_master@tmp/withMaven13af1c7e/maven-spy-20200824-223414-17822331126203689604.log
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-failsafe-plugin:2.21.0:verify (default) on 
project org.apache.sling.launchpad.testing: There are test failures.
[ERROR] 
[ERROR] Please refer to 
/home/jenkins/jenkins-agent/workspace/e-sling-launchpad-testing_master/target/failsafe-reports
 for the individual test results.
[ERROR] Please refer to dump files (if any exist) [date]-jvmRun[N].dump, 
[date].dumpstream and [date]-jvmRun[N].dumpstream.
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache

Re: [DISCUSS] Resource Mapping SPI

2020-08-24 Thread Georg Henzler

Hi Carsten,

And if you still need this, you can do this differently without using
the resource mapping functionality.

This happens too often today because of the missing extensibility of
the resource resolver. The point of the Resource Mapping SPI is to
improve the situation and to be able to fully rely on rr.map()
That way we can make default mapping happen in HTL and get rid
of the rewriter pipeline for 95% of the projects IMHO, if rr.map()
only does "half the job" this cannot easily be achieved

...but that comes with the penalty
of doing these things twice - first in auth core and then again with
the user context - and hopefully both operations provide the same
result (another reason why per user context mapping is dangerous).

The idea was to check the authentication requirement only once in
auth core (for the alias/vanity path case the resolve method will
have to make use of the same map, but I'd expect it to not be too
much of a problem)

Mapping is different from resolving and I think we should start
treating it differently.

IMHO both yes and no:

Yes: Mapping happens at a completely different time than resolving,
mapping creates links to be resolved in the future (even if you
provide the current request to map(), it'll act as example for a
future request.

No: map/resolve "amendments" to the setup should always be made
symmetrically - ResourceToUriMapper with both map() and resolve()
ensures exactly that by forcing SPI providers to think about both
aspects.

Now for SLING-9622 it's actually the rr.resolve() path that is
causing the headache (and "unauthenticated map()" would not help
here). If you like I can give it a try with an SPI interface
ResourceUriAuthRequirementChecker...

-Georg

On 2020-08-24 18:32, Carsten Ziegeler wrote:

Hi Georg,

at least today, the user context is not really taken into account for
mapping. And I think everything stays nicer and cleaner if we don't
open this up - otherwise you need to think about setting correct
caching headers etc.
And if you still need this, you can do this differently without using
the resource mapping functionality.

The primary concern is that authentication handlers and requirements
can be handled correctly and without much effort. Of course we can add
more methods to the SPI and potentially other services to allow the
auth core to do the correct lookups, but that comes with the penalty
of doing these things twice - first in auth core and then again with
the user context - and hopefully both operations provide the same
result (another reason why per user context mapping is dangerous).

Mapping is different from resolving and I think we should start
treating it differently. If we can agree that mapping is independent
of the user context (and today that is the case), then we can simplify
things and make them cleaner.

Regards
Carsten

Am 24.08.2020 um 17:09 schrieb Georg Henzler:

Hi Carsten,

good opportunity to rethink mapping / resolving in general.

so you are referring to SLING-9622 and more specifically to comment
[1] I suppose... I have thought it a bit through and I think there
are valid use cases for having "the user context" (=rr) available
for both resolve() and map(). But if it's really just about a
knowing early (in processor) if the incoming request requires
authentication or not, why not just add a method
requiresAuthentication(resourceUri) to SPI at [2]? Or maybe cleaner,
a second interface ResourceUriAuthenticationRequirementChecker could
be introduced (that "interested" ResourceToUriMapper could also
implement). Once vanity path and alias handling are migrated to this
new setup, the SPI method can access the readily available data
structure, so this should not have a performance impact... WDYT?

-Georg

[1]
https://issues.apache.org/jira/browse/SLING-9622?focusedCommentId=17182336=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17182336
[2]
https://github.com/apache/sling-org-apache-sling-api/blob/3eedd71ec46e75ec93848282f7d3cb4a7ce862b5/src/main/java/org/apache/sling/api/resource/mapping/spi/ResourceToUriMapper.java#L35
On 2020-08-23 11:24, Carsten Ziegeler wrote:

Thanks for taking this up.

As noted in the issue, I think we should investigate whether this is
a

good opportunity to rethink mapping / resolving in general. In
hindsight, we probably shouldn't have added the mapping part to the
resource resolver. The resolve() method does two things: it applies
mappings (which is independent of the current user) and it resolves
to

a resource (finding the resource and figuring out the selectors,
extensions etc.) based on the user.

So how about moving the mapping part out of the resource resolver? As
we've seen recently other parts of Sling like auth core could benefit
from this as well.

I haven't fully thought this through, but this is the rough idea:

We create a new OSGi service, PathMapperFactory (its probably not a
good name but I don't want to invest time into naming at this

[Jenkins] Sling » Modules » sling-org-apache-sling-launchpad-testing » master #44 is BROKEN

Please see 
https://ci-builds.apache.org/job/Sling/job/modules/job/sling-org-apache-sling-launchpad-testing/job/master/44/
 for details.

No further emails will be sent until the status of the build is changed.
Build log follows below:

[...truncated 1446 lines...]
at 
org.apache.sling.settings.impl.SlingPropertiesPrinter.(SlingPropertiesPrinter.java:64)
... 31 more
INFO : org.apache.felix.webconsole.plugins.memoryusage (59): Storing Memory 
Dumps in 
/home/jenkins/jenkins-agent/workspace/e-sling-launchpad-testing_master/target/launchers/sling-12-oak-tar/framework/bundle59/data/dumps
INFO : org.apache.felix.webconsole.plugins.memoryusage (59): Setting Automatic 
Memory Dump Threshold to 0% for pools [CodeHeap 'non-nmethods', CodeHeap 
'non-profiled nmethods', CodeHeap 'profiled nmethods', Compressed Class Space, 
G1 Old Gen, Metaspace]
INFO : org.apache.felix.webconsole.plugins.memoryusage (59): Automatic Memory 
Dump cannot be set for pools [G1 Eden Space, G1 Survivor Space]
INFO : org.apache.felix.webconsole.plugins.memoryusage (59): Setting Automatic 
Memory Dump Interval to 21600 seconds
INFO : org.apache.felix.webconsole.plugins.memoryusage (59): Setting Automatic 
Memory Dump Threshold to 0% for pools [CodeHeap 'non-nmethods', CodeHeap 
'non-profiled nmethods', CodeHeap 'profiled nmethods', Compressed Class Space, 
G1 Old Gen, Metaspace]
INFO : org.apache.felix.webconsole.plugins.memoryusage (59): Automatic Memory 
Dump cannot be set for pools [G1 Eden Space, G1 Survivor Space]
INFO : org.apache.felix.webconsole.plugins.memoryusage (59): Setting Automatic 
Memory Dump Interval to 21600 seconds
INFO : org.apache.felix.webconsole.plugins.memoryusage (59): Storing Memory 
Dumps in 
/home/jenkins/jenkins-agent/workspace/e-sling-launchpad-testing_master/target/launchers/sling-12-oak-tar/framework/bundle59/data/dumps
[INFO] Framework started
[INFO] 
[INFO] --- maven-failsafe-plugin:2.21.0:integration-test (default) @ 
org.apache.sling.launchpad.testing ---
[INFO] 
[INFO] ---
[INFO]  T E S T S
[INFO] ---
[INFO] Running org.apache.sling.launchpad.webapp.integrationtest.FiltersTest
18:50:27,849 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could 
NOT find resource [logback.groovy]
18:50:27,851 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found 
resource [logback-test.xml] at 
[file:/home/jenkins/jenkins-agent/workspace/e-sling-launchpad-testing_master/target/test-classes/logback-test.xml]
18:50:27,852 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource 
[logback-test.xml] occurs multiple times on the classpath.
18:50:27,852 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource 
[logback-test.xml] occurs at 
[file:/home/jenkins/jenkins-agent/workspace/e-sling-launchpad-testing_master/target/test-classes/logback-test.xml]
18:50:27,852 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource 
[logback-test.xml] occurs at 
[jar:file:/home/jenkins/.m2/repository/org/apache/sling/org.apache.sling.launchpad.integration-tests/12-SNAPSHOT/org.apache.sling.launchpad.integration-tests-12-SNAPSHOT.jar!/logback-test.xml]
18:50:27,994 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction 
- debug attribute not set
18:50:28,000 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About 
to instantiate appender of type [ch.qos.logback.core.FileAppender]
18:50:28,007 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming 
appender as [file]
18:50:28,040 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA 
- Assuming default type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] 
for [encoder] property
18:50:28,107 |-INFO in ch.qos.logback.core.FileAppender[file] - File property 
is set to [target/sling-tests.log]
18:50:28,109 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About 
to instantiate appender of type [ch.qos.logback.classic.sift.SiftingAppender]
18:50:28,112 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming 
appender as [sift]
18:50:28,124 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA 
- Assuming default type [ch.qos.logback.classic.sift.MDCBasedDiscriminator] for 
[discriminator] property
18:50:28,132 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - 
Setting level of logger [org.apache.sling.launchpad] to DEBUG
18:50:28,132 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - 
Setting level of ROOT logger to INFO
18:50:28,132 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - 
Attaching appender named [file] to Logger[ROOT]
18:50:28,132 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - 
Attaching appender named [sift] to Logger[ROOT]
18:50:28,133 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction 
- End of configuration.
18:50:28,134 |-INFO in

[Jenkins] Sling » Modules » sling-org-apache-sling-launchpad-testing » master #42 is FIXED

Please see 
https://ci-builds.apache.org/job/Sling/job/modules/job/sling-org-apache-sling-launchpad-testing/job/master/42/
 for details.

No further emails will be sent until the status of the build is changed.

[GitHub] [sling-org-apache-sling-launchpad-integration-tests] sonarcloud[bot] removed a comment on pull request #1: [SLING-9417] Added test for an nt:file child of a versioned node



sonarcloud[bot] removed a comment on pull request #1:
URL: 
https://github.com/apache/sling-org-apache-sling-launchpad-integration-tests/pull/1#issuecomment-674438610


   SonarCloud Quality Gate failed.
   
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=BUG)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=BUG)
 [0 
Bugs](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=BUG)
  
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=VULNERABILITY)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=VULNERABILITY)
 [0 
Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=VULNERABILITY)
 (and [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launch
 pad-integration-tests=1=false=SECURITY_HOTSPOT) [0 
Security 
Hotspots](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=SECURITY_HOTSPOT)
 to review)  
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=CODE_SMELL)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=CODE_SMELL)
 [0 Code 
Smells](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=CODE_SMELL)
   
   [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=new_coverage=list)
 [0.0% 
Coverage](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=new_coverage=list)
  
   [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=new_duplicated_lines_density=list)
 [0.0% 
Duplication](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=new_duplicated_lines_density=list)
   
The version of Java (1.8.0_252) you 
have used to run this analysis is deprecated and we will stop accepting it from 
October 2020. Please update to at least Java 11.
   Read more [here](https://sonarcloud.io/documentation/upcoming/)
   
   
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [sling-org-apache-sling-launchpad-integration-tests] sonarcloud[bot] commented on pull request #1: [SLING-9417] Added test for an nt:file child of a versioned node



sonarcloud[bot] commented on pull request #1:
URL: 
https://github.com/apache/sling-org-apache-sling-launchpad-integration-tests/pull/1#issuecomment-679298315


   SonarCloud Quality Gate failed.
   
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=BUG)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=BUG)
 [0 
Bugs](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=BUG)
  
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=VULNERABILITY)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=VULNERABILITY)
 [0 
Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=VULNERABILITY)
 (and [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launch
 pad-integration-tests=1=false=SECURITY_HOTSPOT) [0 
Security 
Hotspots](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=SECURITY_HOTSPOT)
 to review)  
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=CODE_SMELL)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=CODE_SMELL)
 [0 Code 
Smells](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=false=CODE_SMELL)
   
   [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=new_coverage=list)
 [0.0% 
Coverage](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=new_coverage=list)
  
   [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=new_duplicated_lines_density=list)
 [0.0% 
Duplication](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-launchpad-integration-tests=1=new_duplicated_lines_density=list)
   
The version of Java (1.8.0_252) you 
have used to run this analysis is deprecated and we will stop accepting it from 
October 2020. Please update to at least Java 11.
   Read more [here](https://sonarcloud.io/documentation/upcoming/)
   
   
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Comment Edited] (SLING-9686) Update project badges to point to ci-builds.apache.org

2020-08-24 Thread Dan Klco (Jira)



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

Dan Klco edited comment on SLING-9686 at 8/24/20, 6:39 PM:
---

Oh, shoot [~radu] I was working on this on SLING-9681 as well. 


was (Author: dklco):
Oh, shoot [~radu] I was working on this on SLING-9686 as well. 

> Update project badges to point to ci-builds.apache.org
> --
>
> Key: SLING-9686
> URL: https://issues.apache.org/jira/browse/SLING-9686
> Project: Sling
>  Issue Type: Improvement
>  Components: Tooling
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
>
> The project badges from their {{README.md}} files should point to the new CI 
> server.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SLING-9686) Update project badges to point to ci-builds.apache.org

2020-08-24 Thread Dan Klco (Jira)



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

Dan Klco commented on SLING-9686:
-

Oh, shoot [~radu] I was working on this on SLING-9686 as well. 

> Update project badges to point to ci-builds.apache.org
> --
>
> Key: SLING-9686
> URL: https://issues.apache.org/jira/browse/SLING-9686
> Project: Sling
>  Issue Type: Improvement
>  Components: Tooling
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
>
> The project badges from their {{README.md}} files should point to the new CI 
> server.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[Jenkins] Sling » Modules » sling-org-apache-sling-launchpad-testing » master #41 is BROKEN

er service
[DEBUG] [ServiceReference 430 from bundle 124 : org.apache.sling.engine:2.7.2 
ref=[javax.servlet.Filter] properties={component.id=219, 
component.name=org.apache.sling.engine.parameters, file.max=-1, 
file.threshold=256000, objectClass=[javax.servlet.Filter], 
osgi.http.whiteboard.context.select=(osgi.http.whiteboard.context.name=org.apache.sling),
 osgi.http.whiteboard.filter.pattern=[/], request.max=-1, service.bundleid=124, 
service.description=Filter for request parameter support, service.id=430, 
service.ranking=2147483647, service.scope=bundle, service.vendor=The Apache 
Software Foundation, sling.default.max.parameters=1, 
sling.default.parameter.checkForAdditionalContainerParameters=false, 
sling.default.parameter.encoding=ISO-8859-1}] Ignoring unmatching Filter service
[INFO] Apachde Felix Http Whiteboard Service stopped
[INFO] Stopped Jetty.
[INFO] 
[INFO] --- ianal-maven-plugin:1.0-alpha-1:verify-legal-files (default) @ 
org.apache.sling.launchpad.testing ---
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by 
org.codehaus.groovy.reflection.CachedConstructor 
(file:/home/jenkins/.m2/repository/org/codehaus/groovy/groovy-all-minimal/1.5.6/groovy-all-minimal-1.5.6.jar)
 to constructor java.io.File(java.lang.String,java.io.File)
WARNING: Please consider reporting this to the maintainers of 
org.codehaus.groovy.reflection.CachedConstructor
WARNING: Use --illegal-access=warn to enable warnings of further illegal 
reflective access operations
WARNING: All illegal access operations will be denied in a future release
[INFO] Checking legal files in: 
org.apache.sling.launchpad.testing-12-SNAPSHOT.jar
[INFO] Checking legal files in: 
org.apache.sling.launchpad.testing-12-SNAPSHOT-sources.jar
[INFO] 
[INFO] --- apache-rat-plugin:0.11:check (default) @ 
org.apache.sling.launchpad.testing ---
[INFO] 51 implicit excludes (use -debug for more details).
[INFO] Exclude: DEPENDENCIES
[INFO] Exclude: src/main/appended-resources/META-INF/*
[INFO] Exclude: velocity.log
[INFO] Exclude: target/*
[INFO] Exclude: README.md
[INFO] Exclude: maven-eclipse.xml
[INFO] Exclude: .*
[INFO] Exclude: .*/**
[INFO] Exclude: **/*.json
[INFO] Exclude: DEPENDENCIES
[INFO] Exclude: **/*.rej
[INFO] Exclude: hs_err_*.log
[INFO] Exclude: **/repository/index/*/index-details.txt
[INFO] Exclude: bnd.bnd
[INFO] 6 resources included (use -debug for more details)
[INFO] Rat check: Summary of files. Unapproved: 0 unknown: 0 generated: 0 
approved: 5 licence.
[INFO] 
[INFO] --- maven-failsafe-plugin:2.21.0:verify (default) @ 
org.apache.sling.launchpad.testing ---
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time:  03:21 min
[INFO] Finished at: 2020-08-24T18:36:23Z
[INFO] 
[INFO] [jenkins-event-spy] Generated 
/home/jenkins/workspace/e-sling-launchpad-testing_master@tmp/withMaven5a397be2/maven-spy-20200824-183302-217445821295306362490.log
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-failsafe-plugin:2.21.0:verify (default) on 
project org.apache.sling.launchpad.testing: There are test failures.
[ERROR] 
[ERROR] Please refer to 
/home/jenkins/workspace/e-sling-launchpad-testing_master/target/failsafe-reports
 for the individual test results.
[ERROR] Please refer to dump files (if any exist) [date]-jvmRun[N].dump, 
[date].dumpstream and [date]-jvmRun[N].dumpstream.
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[Pipeline] }
[DevOpticsMavenPublisher] dependencies consumed: 0, artifacts produced: 0
[withMaven] Publishers: CloudBees DevOptics Gate Artifact Publisher: 54645 ms
[Pipeline] // withMaven
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // timeout
[Pipeline] stage
[Pipeline] { (Notifications)
[Pipeline] echo
Status change is BROKEN, notifications will be sent.
[Pipeline] emailext

[jira] [Resolved] (SLING-9686) Update project badges to point to ci-builds.apache.org



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

Radu Cotescu resolved SLING-9686.
-
Resolution: Fixed

> Update project badges to point to ci-builds.apache.org
> --
>
> Key: SLING-9686
> URL: https://issues.apache.org/jira/browse/SLING-9686
> Project: Sling
>  Issue Type: Improvement
>  Components: Tooling
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
>
> The project badges from their {{README.md}} files should point to the new CI 
> server.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SLING-9686) Update project badges to point to ci-builds.apache.org



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

Oliver Lietz commented on SLING-9686:
-

[~radu], The script used to update the badges trashes {{\n}}, see 
[5efeed11d7ecb46b5be7fed4b1e92f30b50c9f12 
|https://github.com/apache/sling-org-apache-sling-commons-messaging-mail/commit/5efeed11d7ecb46b5be7fed4b1e92f30b50c9f12].

> Update project badges to point to ci-builds.apache.org
> --
>
> Key: SLING-9686
> URL: https://issues.apache.org/jira/browse/SLING-9686
> Project: Sling
>  Issue Type: Improvement
>  Components: Tooling
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
>
> The project badges from their {{README.md}} files should point to the new CI 
> server.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SLING-9594) Move Sling builds to ci-builds.apache.org



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

Radu Cotescu commented on SLING-9594:
-

I've created SLING-9686 for updating the badges. [~dklco] updated the main 
script we need to use and I'm pushing the changes as I write this comment.

With this batch of commits I'll probably become the most active Sling 
contributor for 2020. :D

> Move Sling builds to ci-builds.apache.org
> -
>
> Key: SLING-9594
> URL: https://issues.apache.org/jira/browse/SLING-9594
> Project: Sling
>  Issue Type: Task
>  Components: Build and Source Control
>Reporter: Robert Munteanu
>Priority: Critical
>
> The ASF Jenkins infrastructure is moving to to a new
> Cloudbees based Client Master called https://ci-builds.apache.org, see 
> https://lists.apache.org/thread.html/re974eed417a1bc294694701d5c91b4bf92689fcf32a4c91f169be87d%40%3Cbuilds.apache.org%3E
>  .  The migrations of all jobs needs to be done before the switch off date of 
> 15th August 2020, so we have a maximum about three weeks from now to make the 
> move.
> There is no automatic way of migrating the jobs, but thankfully our current 
> set up is very much automated and reasonably well documented at 
> https://cwiki.apache.org/confluence/display/SLING/Sling+Jenkins+Setup .
> It very well may be that we can simply set up another GitHub org on the new 
> Jenkins master, provide the secrets and be done with it. But it needs 
> investigation though.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (SLING-9651) Committer CLI release checks should use ci-builds.apache.org



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

Radu Cotescu reassigned SLING-9651:
---

Assignee: Radu Cotescu

> Committer CLI release checks should use ci-builds.apache.org
> 
>
> Key: SLING-9651
> URL: https://issues.apache.org/jira/browse/SLING-9651
> Project: Sling
>  Issue Type: Bug
>  Components: Tooling
>Reporter: Robert Munteanu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Committer CLI 1.0.0
>
>
> CI checks are failing as we are in the process of moving to 
> https://ci-builds.apache.org/ . Repository format will be
> https://ci-builds.apache.org/job/Sling/job/modules/job/${MODULE}/job/${BRANCH}.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [DISCUSS] Resource Mapping SPI

2020-08-24 Thread Carsten Ziegeler

Yes, backwards compatibility is important and I think if we introduce 
new methods in the ResourceResolver (deprecating the old ones), we'll 
get that easily. For now, I wouldn't introduce a different content model 
for the mapping in /etc - that could be done independently if required


Regards
Carsten

Am 24.08.2020 um 10:21 schrieb Bertrand Delacretaz:

Hi,

On Sun, Aug 23, 2020 at 11:24 AM Carsten Ziegeler  wrote:


...PathMapperFactory (its probably not a good name...


I think "rewriter" instead of "mapper" might be a good term, in the
end it's similar to the famous mod_rewrite?


...So how about moving the mapping part out of the resource resolver? As
we've seen recently other parts of Sling like auth core could benefit
from this as well...


I think that makes sense but I'm not sure how we can guarantee
backwards compatibility if we do that.

We might need to keep the existing mechanisms in parallel, but deprecate them?

The "global" configs in /etc/map might be a problem then but we could
move that to /etc/rewrite and design the new rewriter to ignore
/etc/map if a rewrite already happened. So that Sling users can turn
off /etc/map after some time, once counters or logs show that it's not
used anymore in their setup.


...This way we have a clear separation between mapping and resolving and
in which contexts the operations happen


I like that, assuming we can cleanly take care of backwards compatibility.

-Bertrand



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

Re: [DISCUSS] Resource Mapping SPI

2020-08-24 Thread Carsten Ziegeler

Hi Georg,

at least today, the user context is not really taken into account for
mapping. And I think everything stays nicer and cleaner if we don't open
this up - otherwise you need to think about setting correct caching
headers etc.
And if you still need this, you can do this differently without using
the resource mapping functionality.

The primary concern is that authentication handlers and requirements can
be handled correctly and without much effort. Of course we can add more
methods to the SPI and potentially other services to allow the auth core
to do the correct lookups, but that comes with the penalty of doing
these things twice - first in auth core and then again with the user
context - and hopefully both operations provide the same result (another
reason why per user context mapping is dangerous).

Mapping is different from resolving and I think we should start treating
it differently. If we can agree that mapping is independent of the user
context (and today that is the case), then we can simplify things and
make them cleaner.

Regards
Carsten

Am 24.08.2020 um 17:09 schrieb Georg Henzler:

Hi Carsten,

good opportunity to rethink mapping / resolving in general.

-Georg

[1]
https://issues.apache.org/jira/browse/SLING-9622?focusedCommentId=17182336=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17182336

[2]
https://github.com/apache/sling-org-apache-sling-api/blob/3eedd71ec46e75ec93848282f7d3cb4a7ce862b5/src/main/java/org/apache/sling/api/resource/mapping/spi/ResourceToUriMapper.java#L35

On 2020-08-23 11:24, Carsten Ziegeler wrote:

Thanks for taking this up.

As noted in the issue, I think we should investigate whether this is a
good opportunity to rethink mapping / resolving in general. In
hindsight, we probably shouldn't have added the mapping part to the
resource resolver. The resolve() method does two things: it applies
mappings (which is independent of the current user) and it resolves to
a resource (finding the resource and figuring out the selectors,
extensions etc.) based on the user.

So how about moving the mapping part out of the resource resolver? As
we've seen recently other parts of Sling like auth core could benefit
from this as well.

I haven't fully thought this through, but this is the rough idea:

We create a new OSGi service, PathMapperFactory (its probably not a
good name but I don't want to invest time into naming at this stage).
It has one method:

PathMapper newPathMapper(HttpServletRequest request)

where the request parameter is optional. PathMapper has the
resolve/map methods doing the mapping (based on the newly suggested
SPI). If a request has been provided to the factory method, that
object is used for resolving/mapping.
I'm unsure about the exact methods of PathMapper, but it needs a
resolve method taking in a path (the request path) and returning the
resolved path (vanity path, aliases etc are applied) and a flag
whether a redirect should happen.

Sling's main servlet (or more precise the processor) is changed: for
an incoming request it calls the PathMapperFactory with the request
and then the resolve method on PathMapper. If the result is absolut or
the redirect flag is set, the redirect happens.

Otherwise, authentication is invoked with the resolved path - this
frees auth core (and all auth handlers etc) from dealing with
mappings.

If authentication is successful, a new resource resolver is created
and the PathMapper is passed to the resource resolver via the
attributes of the resource resolver factory. ResourceResolver gets a
new method "getPathMapper()" - if no PathMapper is passed to the
resource resolver factory, the factory creates a new one by invoking
newPathMapper(null) on the PathMapperFactory. In all cases, a resource
resolver has a PathMapper.

We add a new method to Resource Resolver, similar to the resolve()
method but just doing the resolution part - no mapping. This method is
used by the main servlet instead of the existing resolve() method. We
deprecate resolve() and map() and change the implementation to
internally use the passed in PathMapper instance.

This way we have a clear separation between mapping and resolving and

[jira] [Created] (SLING-9686) Update project badges to point to ci-builds.apache.org

Radu Cotescu created SLING-9686:
---

 Summary: Update project badges to point to ci-builds.apache.org
 Key: SLING-9686
 URL: https://issues.apache.org/jira/browse/SLING-9686
 Project: Sling
  Issue Type: Improvement
  Components: Tooling
Reporter: Radu Cotescu
Assignee: Radu Cotescu


The project badges from their {{README.md}} files should point to the new CI 
server.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

RE: [VOTE] Release Apache Sling JCR Oak Server 1.2.6

+1

[VOTE] Release Apache Sling JCR Oak Server 1.2.6

Hi,

We solved 1 issue in this release:
https://issues.apache.org/jira/browse/SLING/fixforversion/12347866

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

You can use this UNIX script to download the release and verify the signatures:
https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD

Usage:
sh check_staged_release.sh 2322 /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,
Robert Munteanu

[jira] [Resolved] (SLING-9685) Support principal-based authentication



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

Robert Munteanu resolved SLING-9685.

Resolution: Fixed

Fixed with [sling-org-apache-sling-starter commit 
f813756|https://github.com/apache/sling-org-apache-sling-starter/commit/f813756]


> Support principal-based authentication
> --
>
> Key: SLING-9685
> URL: https://issues.apache.org/jira/browse/SLING-9685
> Project: Sling
>  Issue Type: Improvement
>  Components: Starter
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
>  Labels: Sling-12-ReleaseNotes
> Fix For: Starter 12
>
>
> The [oak principal-based 
> authentication|https://jackrabbit.apache.org/oak/docs/security/authorization/principalbased.html]
>  is an alternate way of supporting access control entries, with the main 
> difference being that the policy entries are stored together with the user 
> itself, rather than with the content they target.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (SLING-9685) Support principal-based authentication



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

Robert Munteanu updated SLING-9685:
---
Labels: Sling-12-ReleaseNotes  (was: )

> Support principal-based authentication
> --
>
> Key: SLING-9685
> URL: https://issues.apache.org/jira/browse/SLING-9685
> Project: Sling
>  Issue Type: Improvement
>  Components: Starter
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
>  Labels: Sling-12-ReleaseNotes
> Fix For: Starter 12
>
>
> The [oak principal-based 
> authentication](https://jackrabbit.apache.org/oak/docs/security/authorization/principalbased.html)
>  is an alternate way of supporting access control entries, with the main 
> difference being that the policy entries are stored together with the user 
> itself, rather than with the content they target.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (SLING-9685) Support principal-based authentication



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

Robert Munteanu updated SLING-9685:
---
Description: The [oak principal-based 
authentication|https://jackrabbit.apache.org/oak/docs/security/authorization/principalbased.html]
 is an alternate way of supporting access control entries, with the main 
difference being that the policy entries are stored together with the user 
itself, rather than with the content they target.  (was: The [oak 
principal-based 
authentication](https://jackrabbit.apache.org/oak/docs/security/authorization/principalbased.html)
 is an alternate way of supporting access control entries, with the main 
difference being that the policy entries are stored together with the user 
itself, rather than with the content they target.)

> Support principal-based authentication
> --
>
> Key: SLING-9685
> URL: https://issues.apache.org/jira/browse/SLING-9685
> Project: Sling
>  Issue Type: Improvement
>  Components: Starter
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
>  Labels: Sling-12-ReleaseNotes
> Fix For: Starter 12
>
>
> The [oak principal-based 
> authentication|https://jackrabbit.apache.org/oak/docs/security/authorization/principalbased.html]
>  is an alternate way of supporting access control entries, with the main 
> difference being that the policy entries are stored together with the user 
> itself, rather than with the content they target.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (SLING-9685) Support principal-based authentication

Robert Munteanu created SLING-9685:
--

 Summary: Support principal-based authentication
 Key: SLING-9685
 URL: https://issues.apache.org/jira/browse/SLING-9685
 Project: Sling
  Issue Type: Improvement
  Components: Starter
Reporter: Robert Munteanu
Assignee: Robert Munteanu
 Fix For: Starter 12


The [oak principal-based 
authentication](https://jackrabbit.apache.org/oak/docs/security/authorization/principalbased.html)
 is an alternate way of supporting access control entries, with the main 
difference being that the policy entries are stored together with the user 
itself, rather than with the content they target.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [DISCUSS] Resource Mapping SPI

2020-08-24 Thread Georg Henzler

Hi Carsten,

good opportunity to rethink mapping / resolving in general.

-Georg

On 2020-08-23 11:24, Carsten Ziegeler wrote:

Thanks for taking this up.

So how about moving the mapping part out of the resource resolver? As
we've seen recently other parts of Sling like auth core could benefit
from this as well.

I haven't fully thought this through, but this is the rough idea:

We create a new OSGi service, PathMapperFactory (its probably not a
good name but I don't want to invest time into naming at this stage).
It has one method:

PathMapper newPathMapper(HttpServletRequest request)

Otherwise, authentication is invoked with the resolved path - this
frees auth core (and all auth handlers etc) from dealing with
mappings.

This way we have a clear separation between mapping and resolving and
in which contexts the operations happen. With adding the PathMapper to
the resource resolver we make it available to all parts in the system
which need to call todays map() method - and as the PathMapper
instance knows the request, there is no need to pass it around
anymore.

Now, again, just a rough write down of the idea, don't get hung up on
the naming that can and needs to improve. Its also not directly about
the new SPI, but rather how we make the SPI available to the rest of
the system.

Regards
Carsten

[jira] [Closed] (SLING-9657) Same-name JS Use dependencies are not always correctly resolved



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

Radu Cotescu closed SLING-9657.
---

> Same-name JS Use dependencies are not always correctly resolved
> ---
>
> Key: SLING-9657
> URL: https://issues.apache.org/jira/browse/SLING-9657
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting HTL JS Use Provider 1.2.4
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting HTL Testing 1.0.22-1.4.0, Scripting HTL JS Use 
> Provider 1.2.6, Scripting HTL Testing Content 1.0.20-1.4.0
>
>
> When solving JS dependencies using the resource-type hierarchy, the 
> resolution is not always correct.
> Example content structure:
> {noformat}
> /apps/page/
> page.html
> head.js
> /apps/project/page
> [sling:resourceSuperType=page]
> page.html
> partials/
> head.html
> head.js
> {noformat}
> Example calling model:
> {{/apps/project/page/page.html}}
> {code:html}
> 
> {code}
> {{/apps/project/page/partials/head.html}}
> {code:html}
> 
> {code}
> With the above setup, the {{head.js}} script being select is the one from 
> {{/apps/page/head.js}}, instead of the file inside {{partials}}. While this 
> takes the resource type hierarchy into consideration, the correct caller is 
> {{partials/head.html}}, hence why the resolution should happen "locally".



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (SLING-9671) Allow non-bundled inheriting resource types to override Use-API templates



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

Radu Cotescu closed SLING-9671.
---

> Allow non-bundled inheriting resource types to override Use-API templates
> -
>
> Key: SLING-9671
> URL: https://issues.apache.org/jira/browse/SLING-9671
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting HTL Engine 1.4.0-1.4.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting HTL Testing 1.0.22-1.4.0, Scripting HTL Engine 
> 1.4.2-1.4.0, Scripting HTL Testing Content 1.0.20-1.4.0
>
>
> SLING-9328 added support for loading templates via the 
> {{org.apache.sling.servlets.resolver.bundle.tracker.BundledRenderUnit}} API. 
> However, when working with a bundled HTL script (precompiled or not), only 
> template libraries available via the bundled script's 
> {{org.apache.sling.servlets.resolver.bundle.tracker.TypeProvider}} hierarchy 
> are considered, not allowing scripts from the resource tree to override the 
> behaviour.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (SLING-9677) Remove redundant org.apache.sling.scripting.core.impl.bundled.ProtectedBindings class



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

Radu Cotescu closed SLING-9677.
---

> Remove redundant 
> org.apache.sling.scripting.core.impl.bundled.ProtectedBindings class
> -
>
> Key: SLING-9677
> URL: https://issues.apache.org/jira/browse/SLING-9677
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Scripting Core 2.3.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting Core 2.3.2
>
>
> SLING-9406 merged the Apache Sling Scripting Bundle Tracker to Scripting Core 
> and introduced the 
> {{org.apache.sling.scripting.core.impl.bundled.ProtectedBindings}} class, 
> which is a copy of 
> {{org.apache.sling.scripting.core.impl.helper.ProtectedBindings}}, with the 
> difference that the former does not extend 
> {{org.apache.sling.api.scripting.LazyBindings}}, although it should.
> However, only one of these classes should be kept, namely 
> {{org.apache.sling.scripting.core.impl.helper.ProtectedBindings}}.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (SLING-9607) Fix conflicting dependency to commons-io where two different versions are listed



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

Radu Cotescu closed SLING-9607.
---

> Fix conflicting dependency to commons-io where two different versions are 
> listed
> 
>
> Key: SLING-9607
> URL: https://issues.apache.org/jira/browse/SLING-9607
> Project: Sling
>  Issue Type: Bug
>Reporter: Eric Norman
>Assignee: Eric Norman
>Priority: Major
> Fix For: Scripting Core 2.3.2
>
>
> Fix conflicting dependency to commons-io where two different versions are 
> listed causing the following warning in the build:
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for org.apache.sling:org.apache.sling.scripting.core:jar:2.3.1-SNAPSHOT
> [WARNING] 'dependencies.dependency.(groupId:artifactId:type:classifier)' must 
> be unique: commons-io:commons-io:jar -> version 2.6 vs 2.4 @ line 209, column 
> 21
> [WARNING] 
> [WARNING] It is highly recommended to fix these problems because they 
> threaten the stability of your build.
> [WARNING] 
> [WARNING] For this reason, future Maven versions might no longer support 
> building such malformed projects.
> [WARNING]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (SLING-9679) Add the executable name in the servlet properties for the BundledScriptServlet



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

Radu Cotescu closed SLING-9679.
---

> Add the executable name in the servlet properties for the BundledScriptServlet
> --
>
> Key: SLING-9679
> URL: https://issues.apache.org/jira/browse/SLING-9679
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Affects Versions: Servlets Resolver 2.7.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Servlets Resolver 2.7.8
>
>
> The 
> {{org.apache.sling.servlets.resolver.bundle.tracker.internal.BundledScriptServlet}}
>  should be registered in a way that allows the {{RequestProgressTracker}} to 
> show the script / resource type for which the servlet was registered.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[RESULT] [VOTE] Release Apache Sling Scripting HTL Testing Content 1.0.20-1.4.0, Apache Sling Scripting HTL JS Use Provider 1.2.6, Apache Sling Scripting HTL Engine 1.4.2-1.4.0, Apache Sling Scripting

2020-08-24 Thread Radu Cotescu

Hi,

The vote has passed with the following result:

+1 (binding): Robert Munteanu, Andrei Dulvac, Nicolas Peltier, Karl Pauls, 
Stefan Seifert
+1 (non-binding): none

I will copy this release to the Sling dist directory and
promote the artifacts to the central Maven repository.

Regards,
Radu Cotescu

[RESULT] [VOTE] Release Apache Sling Servlets Resolver 2.7.8

2020-08-24 Thread Radu Cotescu

Hi,

The vote has passed with the following result:

+1 (binding): Robert Munteanu, Dan Klco, Eric Norman, Stefan Seifert, Karl Pauls
+1 (non-binding): none

I will copy this release to the Sling dist directory and
promote the artifacts to the central Maven repository.

Regards,
Radu Cotescu

[RESULT] [VOTE] Release Apache Sling Scripting Core 2.3.2

2020-08-24 Thread Radu Cotescu

Hi,

The vote has passed with the following result:

+1 (binding): Robert Munteanu, Nicolas Peltier, Karl Pauls, Stefan Seifert
+1 (non-binding): none

I will copy this release to the Sling dist directory and
promote the artifacts to the central Maven repository.

Regards,
Radu Cotescu

Re: [DISCUSS] Resource Mapping SPI

2020-08-24 Thread Ruben Reusser


Georg, thanks for the reply - agree my use cases should be covered with that

On 8/24/2020 7:42 AM, Georg Henzler wrote:

Hi Ruben,


One use case that probably also should be considered here is the case
where static pages are generated with sling. In that case the
rendering of the page is not tied to a request.


While [1] has a request in the signature, the idea is not that this
needs to be "a currently active" request. It can be

Re: [DISCUSS] Resource Mapping SPI

2020-08-24 Thread Georg Henzler


Hi Ruben,


One use case that probably also should be considered here is the case
where static pages are generated with sling. In that case the
rendering of the page is not tied to a request.


While [1] has a request in the signature, the idea is not that this
needs to be "a currently active" request. It can be

1. null for default behaviour
2. the current request (if mapping should be aligned with current 
request)

3. an example request (or maybe better "reference request") that holds
the same properties (server name, headers, etc.) as a request that will
be issued for the generated URI in the future. The expectation is that
resolve() of the same ResourceToUriMapper service will take care of such
a mapped URI.

The last option (or maybe the first) covers the use case for generating
static pages.

-Georg

[1] 
https://github.com/apache/sling-org-apache-sling-api/blob/3eedd71ec46e75ec93848282f7d3cb4a7ce862b5/src/main/java/org/apache/sling/api/resource/mapping/spi/ResourceToUriMapper.java#L51



Ruben

[jira] [Resolved] (SLING-9663) Properly set authentication information when performing pre-authenticated login



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

Robert Munteanu resolved SLING-9663.

Resolution: Fixed

Fixed with 
https://github.com/apache/sling-org-apache-sling-jcr-oak-server/pull/3

> Properly set authentication information when performing pre-authenticated 
> login
> ---
>
> Key: SLING-9663
> URL: https://issues.apache.org/jira/browse/SLING-9663
> Project: Sling
>  Issue Type: Bug
>  Components: JCR, Oak
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: JCR Oak Server 1.2.6
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Using pre-authenticated service users does not seem to work with the Sling 
> Starter. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [sling-org-apache-sling-jcr-oak-server] rombert merged pull request #3: SLING-9663 - Properly set authentication information when performing pre-authenticated login



rombert merged pull request #3:
URL: https://github.com/apache/sling-org-apache-sling-jcr-oak-server/pull/3


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (SLING-9681) Update Badges to use ci-build.apache.org

2020-08-24 Thread Bertrand Delacretaz (Jira)



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

Bertrand Delacretaz commented on SLING-9681:


That sounds good, in general we love modularity!

> Update Badges to use ci-build.apache.org
> 
>
> Key: SLING-9681
> URL: https://issues.apache.org/jira/browse/SLING-9681
> Project: Sling
>  Issue Type: Task
>Reporter: Dan Klco
>Assignee: Dan Klco
>Priority: Major
>
> In SLING-9594, we moved the builds to ci-build.apache.org, we should 
> similarly update the 
> [add-badges.sh|https://github.com/apache/sling-aggregator/blob/master/add-badges.sh]
>  script to use ci-build.apache.org.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SLING-9681) Update Badges to use ci-build.apache.org

2020-08-24 Thread Dan Klco (Jira)



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

Dan Klco commented on SLING-9681:
-

Good point [~bdelacretaz] -- Honestly I've been thinking that the script does 
too much. I'm thinking of stripping it down to just handle the badges for a 
single project and adding snippets of how one would update all of the projects 
via Repo. 

> Update Badges to use ci-build.apache.org
> 
>
> Key: SLING-9681
> URL: https://issues.apache.org/jira/browse/SLING-9681
> Project: Sling
>  Issue Type: Task
>Reporter: Dan Klco
>Assignee: Dan Klco
>Priority: Major
>
> In SLING-9594, we moved the builds to ci-build.apache.org, we should 
> similarly update the 
> [add-badges.sh|https://github.com/apache/sling-aggregator/blob/master/add-badges.sh]
>  script to use ci-build.apache.org.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [RT] Moving slingshot to a content package

On Sat, 2020-08-22 at 14:24 +0200, Carsten Ziegeler wrote:
> I always liked the fact, that there are no high requirements for 
> installing the demo

Yes, that is correct. A single bundle (well, with repoinit and configs
in the sling starter feature model ) is quite simple. On the other hand
we would be looking at 3 modules for the content package version

- sample content
- apps
- bundle

We can wrap this up into a single 'all' content package for ease of
deployment, but I'm not sure that's the kind of simplicity you were
thinking of :-)

> 
> I think the setup service can now be replaced with a repoinit, so
> from 
> that point of view a content package is not really necessary.

The SetupService changes some resource types, and that's (AFAIU) not
supported by repoinit.

> 
> But if a content package makes people happier I'm not against it

Let's see how far I can get with a content package, for now I'm hitting
some limitations of various components. But it's a good exercise for
content-pacakge based development anyway :-)

Thanks,
Robert

> 
> Regards
> Carsten
> 
> Am 21.08.2020 um 16:01 schrieb Robert Munteanu:
> > Hi,
> > 
> > I was thinking about converting the Slingshot sample [1] to a
> > content
> > package build.
> > 
> > The advantages would be:
> > 
> > - we demonstrate how to use content packages with Sling
> > - better supported by the IDE tooling
> > - remove the need for code that alters the repository on startup
> > such
> > as [2]
> > - increased validation for content package tooling as part of the
> > starter
> > 
> > The main disadvantage that I see would be a more complex repository
> > structure ( reactor build with bundle + content package +
> > (probably)
> > apps package ).
> > 
> > Thoughts?
> > 
> > Robert
> > 
> > [1]: https://github.com/apache/sling-samples/tree/master/slingshot
> > [2]:
> > https://github.com/apache/sling-samples/blob/47388d327fd19b629448192a9692dd3ac01ddab5/slingshot/src/main/java/org/apache/sling/sample/slingshot/impl/SetupService.java
> >

[jira] [Created] (SLING-9684) Support resolving variables within variables

Robert Munteanu created SLING-9684:
--

 Summary: Support resolving variables within variables
 Key: SLING-9684
 URL: https://issues.apache.org/jira/browse/SLING-9684
 Project: Sling
  Issue Type: Improvement
  Components: Feature Model
Reporter: Robert Munteanu
 Fix For: Feature Model 1.2.8


It would be very useful to support resolving variables withing other variables, 
just like we do in configuration values and framework properties, e.g. if 
"sling.home" is a variable pointing to "/work", I should be able to define

{code}
{
  "variables": {
"data.home": "${sling.home}/data"
  }
}
{code}

and have "data.home" resolve to "/work/data".



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [feature] Support for variables within variables?

Thanks Carsten and David.

I created https://issues.apache.org/jira/browse/SLING-9684 for this.

Robert

On Mon, 2020-08-24 at 12:05 +0100, David Bosschaert wrote:
> HI all,
> 
> I also thought that recursively replacing variables was supported,
> but I
> tried it this morning quickly and apparently it's not.
> 
> Maybe create a JIRA for it?
> 
> Best regards,
> 
> David
> 
> On Mon, 24 Aug 2020 at 12:00, Carsten Ziegeler 
> wrote:
> 
> > Hi Robert,
> > 
> > ok, thanks for clarifying. Yes, I agree it makes sense to support
> > a) as
> > well - and actually I'm a little bit surprised that it is not :)
> > I guess the only change needed is to recursively process
> > replacements of
> > variables which should be an easy fix
> > 
> > Regards
> > Carsten
> > 
> > Am 24.08.2020 um 12:55 schrieb Robert Munteanu:
> > > Hi Carsten,
> > > 
> > > On Sat, 2020-08-22 at 14:27 +0200, Carsten Ziegeler wrote:
> > > > Hi,
> > > > 
> > > > I guess it depends on how this support should look like. I
> > > > would
> > > > assume,
> > > > that "-V persistence.dir=/data" with your example works and
> > > > uses
> > > > "/data"
> > > > for the persistence. It will not use "${sling.home}/data" - not
> > > > sure
> > > > if
> > > > that was your intention?
> > > 
> > > I wanted to achieve both scenarios:
> > > 
> > > a) if no variable is passed from the CLI, persistence.dir should
> > > point
> > > to the resovled value of "sling.home" and "/persistence"
> > > b) if the variable value is overridden, the override should be
> > > used
> > > 
> > > b) works today, but a) does not. I tried to give my problem a bit
> > > more
> > > context with an exampe, but I guess I ended up creating confusion
> > > :-)
> > > 
> > > So basically I would like "${sling.home}/repository" to be
> > > properly
> > > resolved for variables like it is done for configurations for
> > > instance.
> > > 
> > > Thanks,
> > > Robert
> > > 
> > 
> > --
> > --
> > Carsten Ziegeler
> > Adobe Research Switzerland
> > cziege...@apache.org
> >

Re: [feature] Support for variables within variables?

2020-08-24 Thread David Bosschaert

HI all,

I also thought that recursively replacing variables was supported, but I
tried it this morning quickly and apparently it's not.

Maybe create a JIRA for it?

Best regards,

David

On Mon, 24 Aug 2020 at 12:00, Carsten Ziegeler  wrote:

> Hi Robert,
>
> ok, thanks for clarifying. Yes, I agree it makes sense to support a) as
> well - and actually I'm a little bit surprised that it is not :)
> I guess the only change needed is to recursively process replacements of
> variables which should be an easy fix
>
> Regards
> Carsten
>
> Am 24.08.2020 um 12:55 schrieb Robert Munteanu:
> > Hi Carsten,
> >
> > On Sat, 2020-08-22 at 14:27 +0200, Carsten Ziegeler wrote:
> >> Hi,
> >>
> >> I guess it depends on how this support should look like. I would
> >> assume,
> >> that "-V persistence.dir=/data" with your example works and uses
> >> "/data"
> >> for the persistence. It will not use "${sling.home}/data" - not sure
> >> if
> >> that was your intention?
> >
> > I wanted to achieve both scenarios:
> >
> > a) if no variable is passed from the CLI, persistence.dir should point
> > to the resovled value of "sling.home" and "/persistence"
> > b) if the variable value is overridden, the override should be used
> >
> > b) works today, but a) does not. I tried to give my problem a bit more
> > context with an exampe, but I guess I ended up creating confusion :-)
> >
> > So basically I would like "${sling.home}/repository" to be properly
> > resolved for variables like it is done for configurations for instance.
> >
> > Thanks,
> > Robert
> >
>
> --
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

Re: [feature] Support for variables within variables?

2020-08-24 Thread Carsten Ziegeler


Hi Robert,

ok, thanks for clarifying. Yes, I agree it makes sense to support a) as 
well - and actually I'm a little bit surprised that it is not :)
I guess the only change needed is to recursively process replacements of 
variables which should be an easy fix


Regards
Carsten

Am 24.08.2020 um 12:55 schrieb Robert Munteanu:

Hi Carsten,

On Sat, 2020-08-22 at 14:27 +0200, Carsten Ziegeler wrote:

Hi,

I guess it depends on how this support should look like. I would
assume,
that "-V persistence.dir=/data" with your example works and uses
"/data"
for the persistence. It will not use "${sling.home}/data" - not sure
if
that was your intention?


I wanted to achieve both scenarios:

a) if no variable is passed from the CLI, persistence.dir should point
to the resovled value of "sling.home" and "/persistence"
b) if the variable value is overridden, the override should be used

b) works today, but a) does not. I tried to give my problem a bit more
context with an exampe, but I guess I ended up creating confusion :-)

So basically I would like "${sling.home}/repository" to be properly
resolved for variables like it is done for configurations for instance.

Thanks,
Robert



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

[jira] [Commented] (SLING-9622) Avoid registration of auth requirements for aliases and vanity paths



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

Robert Munteanu commented on SLING-9622:


+1, I think the situation is already improved ( both from a functional and code 
coherence point of view ).

> Avoid registration of auth requirements for aliases and vanity paths
> 
>
> Key: SLING-9622
> URL: https://issues.apache.org/jira/browse/SLING-9622
> Project: Sling
>  Issue Type: Improvement
>  Components: Authentication
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: Auth Core 1.5.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> Right now when auth requirements are registered, they need to be registered 
> for the resource path, as well as all vanity paths and potentially all 
> combinations of aliases for that path. First of all, this creates potentially 
> a lot of auth requirements for a single path, but as well requires that the 
> registrar of the auth requirement to be aware of vanity paths and aliases and 
> do the right thing and update the auth requirements whenever there are 
> changes.
> We should avoid these additional registrations and processing.
> The SlingAuthenticator is currently checking the request path against the 
> auth requirements. We could change this with checking the resolved path. So 
> the authenticator could use a service user resolver and resolve the path and 
> then check the auth requirements.
> This avoids all the extra work for the registrar of the auth requirements, 
> but comes with the additional cost of a resolve call per request



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

RE: [VOTE] Release Apache Sling Scripting HTL Testing Content 1.0.20-1.4.0, Apache Sling Scripting HTL JS Use Provider 1.2.6, Apache Sling Scripting HTL Engine 1.4.2-1.4.0, Apache Sling Scripting HTL

+1

Re: [feature] Support for variables within variables?

Hi Carsten,

On Sat, 2020-08-22 at 14:27 +0200, Carsten Ziegeler wrote:
> Hi,
> 
> I guess it depends on how this support should look like. I would
> assume, 
> that "-V persistence.dir=/data" with your example works and uses
> "/data" 
> for the persistence. It will not use "${sling.home}/data" - not sure
> if 
> that was your intention?

I wanted to achieve both scenarios:

a) if no variable is passed from the CLI, persistence.dir should point
to the resovled value of "sling.home" and "/persistence"
b) if the variable value is overridden, the override should be used

b) works today, but a) does not. I tried to give my problem a bit more
context with an exampe, but I guess I ended up creating confusion :-)

So basically I would like "${sling.home}/repository" to be properly
resolved for variables like it is done for configurations for instance.

Thanks,
Robert

Re: [VOTE] Release Apache Sling Servlets Resolver 2.7.8

+1

regards,

Karl

On Mon, Aug 24, 2020 at 12:36 PM Stefan Seifert  wrote:
>
> +1
>
>


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

RE: [VOTE] Release Apache Sling Servlets Resolver 2.7.8

+1

RE: [VOTE] Release Apache Sling Scripting Core 2.3.2

+1

[jira] [Commented] (SLING-9681) Update Badges to use ci-build.apache.org

2020-08-24 Thread Bertrand Delacretaz (Jira)



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

Bertrand Delacretaz commented on SLING-9681:


While you're at it, it would be nice IMHO to add a brief description of what 
the script does, either as script comments or as information when starting it.

IIUC from reading the code, it adds badges to the README, previews it using 
grip (which must be installed as per https://github.com/joeyespo/grip and 
offers to commit the result, but does not push it. It would be good to have 
(the correct variant of) this info somewhere!

> Update Badges to use ci-build.apache.org
> 
>
> Key: SLING-9681
> URL: https://issues.apache.org/jira/browse/SLING-9681
> Project: Sling
>  Issue Type: Task
>Reporter: Dan Klco
>Assignee: Dan Klco
>Priority: Major
>
> In SLING-9594, we moved the builds to ci-build.apache.org, we should 
> similarly update the 
> [add-badges.sh|https://github.com/apache/sling-aggregator/blob/master/add-badges.sh]
>  script to use ci-build.apache.org.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Scripting (Core) depending on Servlets (Resolver)

2020-08-24 Thread Bertrand Delacretaz

Hi,

On Mon, Aug 24, 2020 at 10:50 AM Karl Pauls  wrote:
> ...the old tracker can either be deprecated or maybe be
> repurposed (see above)...

For now, I have added a note mentioning this at
https://github.com/apache/sling-org-apache-sling-scripting-bundle-tracker

-Bertrand

Re: Scripting (Core) depending on Servlets (Resolver)

Hi,

the bundle.tracker was merged into the resolver mostly for efficiency
reasons - however, it isn't a bad fit there so I wouldn't say that is
a problem. That there is now a dependency from the scripting core to
the resolver is a side-effect of the whiteboard pattern used in this
case and I don't necessarily know about why that would mean we "give
up modularization".

That said, however, I can see the point about the increased coupling.
Towards that end, I think there are ways we can improve on that. From
the top of my head, we could either try to make the import optional as
this really is an optional feature or we could try to move the bundled
part out of the core and make it a standalone bridge bundle (I think
that should be possible but we'd have to have a closer look at it).

Maybe we should create an improvement JIRA issue to track this and
work on it to make the dependency from the scripting core to the
resolver either optional or factored out into an additional "bridge"
bundle?

And yeah, the old tacker can either be deprecated or maybe be
repurposed (see above).

regards,

Karl

On Mon, Aug 24, 2020 at 10:29 AM Bertrand Delacretaz
 wrote:
>
> Hi,
>
> On Sun, Aug 23, 2020 at 9:33 PM Oliver Lietz  wrote:
> > ...Why was the (standalone) module o.a.s.scripting.bundle.tracker merged 
> > into
> > o.a.s.servlets.resolver?..
>
> That's strange indeed, we now have very similar code at [1] and [2].
>
> If there was a good reason for that (I don't know about that) we
> should at least mark [1] as deprecated.
>
> -Bertrand
>
> [1] 
> https://github.com/apache/sling-org-apache-sling-scripting-bundle-tracker/tree/master/src/main/java/org/apache/sling/scripting/bundle/tracker
>
> [2]  
> https://github.com/apache/sling-org-apache-sling-servlets-resolver/tree/master/src/main/java/org/apache/sling/servlets/resolver/bundle/tracker

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

Re: Scripting (Core) depending on Servlets (Resolver)

2020-08-24 Thread Bertrand Delacretaz

Hi,

On Sun, Aug 23, 2020 at 9:33 PM Oliver Lietz  wrote:
> ...Why was the (standalone) module o.a.s.scripting.bundle.tracker merged into
> o.a.s.servlets.resolver?..

That's strange indeed, we now have very similar code at [1] and [2].

If there was a good reason for that (I don't know about that) we
should at least mark [1] as deprecated.

-Bertrand

[1] 
https://github.com/apache/sling-org-apache-sling-scripting-bundle-tracker/tree/master/src/main/java/org/apache/sling/scripting/bundle/tracker

[2]  
https://github.com/apache/sling-org-apache-sling-servlets-resolver/tree/master/src/main/java/org/apache/sling/servlets/resolver/bundle/tracker

Re: [DISCUSS] Resource Mapping SPI

2020-08-24 Thread Bertrand Delacretaz

Hi,

On Sun, Aug 23, 2020 at 11:24 AM Carsten Ziegeler  wrote:

> ...PathMapperFactory (its probably not a good name...

I think "rewriter" instead of "mapper" might be a good term, in the
end it's similar to the famous mod_rewrite?

> ...So how about moving the mapping part out of the resource resolver? As
> we've seen recently other parts of Sling like auth core could benefit
> from this as well...

I think that makes sense but I'm not sure how we can guarantee
backwards compatibility if we do that.

We might need to keep the existing mechanisms in parallel, but deprecate them?

The "global" configs in /etc/map might be a problem then but we could
move that to /etc/rewrite and design the new rewriter to ignore
/etc/map if a rewrite already happened. So that Sling users can turn
off /etc/map after some time, once counters or logs show that it's not
used anymore in their setup.

> ...This way we have a clear separation between mapping and resolving and
> in which contexts the operations happen

I like that, assuming we can cleanly take care of backwards compatibility.

-Bertrand

Re: [VOTE] Release Apache Sling Scripting Core 2.3.2

+1

regards,

Karl

On Mon, Aug 24, 2020 at 9:13 AM Nicolas Peltier
 wrote:
>
> builds & signatures check worked for me, so here's my +1
>
> Le ven. 21 août 2020 à 18:01, Radu Cotescu  a écrit :
>
> > Hi Daniel,
> >
> > > On 21 Aug 2020, at 15:40, Daniel Klco  wrote:
> > >
> > > Hm, I am seeing some test failures:
> > >
> > >
> > https://ci-builds.apache.org/job/Sling/job/modules/job/sling-org-apache-sling-scripting-core/job/master/6/testReport/junit/
> > >
> > https://ci-builds.apache.org/blue/organizations/jenkins/Sling%2Fmodules%2Fsling-org-apache-sling-scripting-core/detail/master/6/pipeline
> > >
> >
> > I haven’t had any issue locally and the standard output doesn’t tell me
> > much. If you check the next build [0] (no code change) you’ll see that
> > everything went fine. Building from the tag also works on on my end [1].
> >
> > Regards,
> > Radu
> >
> > [0] -
> > https://ci-builds.apache.org/job/Sling/job/modules/job/sling-org-apache-sling-scripting-core/job/master/7/
> > <
> > https://ci-builds.apache.org/job/Sling/job/modules/job/sling-org-apache-sling-scripting-core/job/master/7/>[1]
> > - https://gist.github.com/raducotescu/f2309e62300f3d9d99a883696df2ac3e <
> > https://gist.github.com/raducotescu/f2309e62300f3d9d99a883696df2ac3e>



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

Re: [VOTE] Release Apache Sling Scripting HTL Testing Content 1.0.20-1.4.0, Apache Sling Scripting HTL JS Use Provider 1.2.6, Apache Sling Scripting HTL Engine 1.4.2-1.4.0, Apache Sling Scripting HTL