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

[Apache Jenkins Server]

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

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

[jira] [Updated] (SLING-9675) Update to Oak 1.32.0

[Robert Munteanu (Jira)]

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

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

> Update to Oak 1.32.0
> 
>
> Key: SLING-9675
> URL: https://issues.apache.org/jira/browse/SLING-9675
> Project: Sling
>  Issue Type: Improvement
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
>  Labels: Sling-12-ReleaseNotes
> Fix For: Starter 12
>
>




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

[jira] [Resolved] (SLING-9675) Update to Oak 1.32.0

[Robert Munteanu (Jira)]

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

Robert Munteanu resolved SLING-9675.

Resolution: Fixed

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

> Update to Oak 1.32.0
> 
>
> Key: SLING-9675
> URL: https://issues.apache.org/jira/browse/SLING-9675
> Project: Sling
>  Issue Type: Improvement
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: Starter 12
>
>




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

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

[Apache Jenkins Server]

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

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

[...truncated 1985 lines...]
[INFO] 
[INFO] ---
[INFO]  T E S T S
[INFO] ---
[INFO] Running 
org.apache.sling.launchpad.webapp.integrationtest.GeneratedNodeNameTest
22:50:20,066 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could 
NOT find resource [logback.groovy]
22:50:20,067 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found 
resource [logback-test.xml] at 
[file:/home/jenkins/workspace/e-sling-launchpad-testing_master/target/test-classes/logback-test.xml]
22:50:20,068 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource 
[logback-test.xml] occurs multiple times on the classpath.
22:50:20,068 |-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]
22:50:20,068 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource 
[logback-test.xml] occurs at 
[file:/home/jenkins/workspace/e-sling-launchpad-testing_master/target/test-classes/logback-test.xml]
22:50:20,426 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction 
- debug attribute not set
22:50:20,428 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About 
to instantiate appender of type [ch.qos.logback.core.FileAppender]
22:50:20,445 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming 
appender as [file]
22:50:20,481 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA 
- Assuming default type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] 
for [encoder] property
22:50:20,568 |-INFO in ch.qos.logback.core.FileAppender[file] - File property 
is set to [target/sling-tests.log]
22:50:20,573 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About 
to instantiate appender of type [ch.qos.logback.classic.sift.SiftingAppender]
22:50:20,579 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming 
appender as [sift]
22:50:20,598 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA 
- Assuming default type [ch.qos.logback.classic.sift.MDCBasedDiscriminator] for 
[discriminator] property
22:50:20,610 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - 
Setting level of logger [org.apache.sling.launchpad] to DEBUG
22:50:20,610 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - 
Setting level of ROOT logger to INFO
22:50:20,610 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - 
Attaching appender named [file] to Logger[ROOT]
22:50:20,611 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - 
Attaching appender named [sift] to Logger[ROOT]
22:50:20,612 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction 
- End of configuration.
22:50:20,614 |-INFO in ch.qos.logback.classic.joran.JoranConfigurator@34bf66af 
- Registering current configuration as safe fallback point

Checking if the required Sling services are started (timeout 60 seconds)...
(base URLs=http://localhost:41000 and http://localhost:41000; servlet context=; 
readiness type=.txt : text/plain
ESAPI: WARNING: System property [org.owasp.esapi.opsteam] is not set
ESAPI: WARNING: System property [org.owasp.esapi.devteam] is not set
ESAPI: Attempting to load ESAPI.properties via file I/O.
ESAPI: Attempting to load ESAPI.properties as resource file via file I/O.
ESAPI: Not found in 'org.owasp.esapi.resources' directory or file not readable: 
/home/jenkins/workspace/e-sling-launchpad-testing_master/target/launchers/ESAPI.properties
ESAPI: Not found in SystemResource Directory/resourceDirectory: 
.esapi/ESAPI.properties
ESAPI: Not found in 'user.home' (/home/jenkins) directory: 
/home/jenkins/esapi/ESAPI.properties
ESAPI: Loading ESAPI.properties via file I/O failed. Exception was: 
java.io.FileNotFoundException
ESAPI: Attempting to load ESAPI.properties via the classpath.
ESAPI: SUCCESSFULLY LOADED ESAPI.properties via the CLASSPATH from '/ (root)' 
using class loader for DefaultSecurityConfiguration class!
ESAPI: SecurityConfiguration for Validator.ConfigurationFile.MultiValued not 
found in ESAPI.properties. Using default: false
ESAPI: Attempting to load validation.properties via file I/O.
ESAPI: Attempting to load validation.properties as resource file via file I/O.
ESAPI: Not found in 'org.owasp.esapi.resources' directory or file not readable: 
/home/jenkins/workspace/e-sling-launchpad-testing_master/target/launchers/validation.properties
ESAPI: Not found in SystemResource Directory/resourceDirectory: 
.esapi/validation.properties
ESAPI: Not found 

[jira] [Created] (SLING-9675) Update to Oak 1.32.0

[Robert Munteanu (Jira)]

Robert Munteanu created SLING-9675:
--

 Summary: Update to Oak 1.32.0
 Key: SLING-9675
 URL: https://issues.apache.org/jira/browse/SLING-9675
 Project: Sling
  Issue Type: Improvement
Reporter: Robert Munteanu
Assignee: Robert Munteanu
 Fix For: Starter 12






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

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

[Robert Munteanu (Jira)]

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

Robert Munteanu commented on SLING-9622:


The changes from the auth.core module and the resourceresolver seem to work 
together quite well, but Angela discovered one scenario where this breaks down. 
Assume the following structure

{noformat}
 - parent [vanityPath:/p_vanity] 
 \- child [vanityPath:/c_vanity]
{noformat}

If {{/parent}} is a protected resource with a registered authentication 
requirement, {{/parent/child}} will be included in that requirement. Ance since 
we generate all variations, {{/p_vanity}} will be registered as a different 
authentication requirement.

Unfortunately {{/c_vanity}} will not be included, and this bypasses the 
authentication requirement for the parent node.

-

The {{ResourceMapper}} can not unfortunately help here, as the mapping comes 
from a child path, not from the one where the requirements are set. The 
{{SlingAuthenticatorServiceListener}} will not even know about the child path, 
as it just creates the authentication requirements, and those are based on the 
parent.

It would be simple ( I think ) to resolve the given path in the 
{{SlingAuthenticator}}, but I remember Carsten speaking against it due to 
performance issue - we really should only use the given path. There may be a 
way to just check if the request is a vanity path and then point it to the 
actual resources, but that would be moving truly unrelated concerns in the 
{{SlingAuthenticator}}, which is complex and sensitive. Moreover, it's 
completely against the spirit of the change we're trying to make.

Right now I don't have a great (or good) idea on how to fix this scenario.

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

[jira] [Closed] (SLING-7836) Resolving the error handling scripts should consider the request file extension

[Eric Norman (Jira)]

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

Eric Norman closed SLING-7836.
--

Completed in 2.7.6 release

> Resolving the error handling scripts should consider the request file 
> extension
> ---
>
> Key: SLING-7836
> URL: https://issues.apache.org/jira/browse/SLING-7836
> Project: Sling
>  Issue Type: Improvement
>Affects Versions: Servlets Resolver 2.4.20, Launchpad Integration Tests 
> 1.0.6
>Reporter: Eric Norman
>Assignee: Eric Norman
>Priority: Major
> Fix For: Servlets Resolver 2.7.6
>
>
> I am expecting that a request to [http://localhost:8080/bogus.json] should 
> return a JSON response with the 404 error details in JSON when the resource 
> doesn't exist.  (also similar behavior should be possible for a .txt or .xml 
> file extension)
>  
> What I see currently is that SlingServletResolver#handleError ignores the 
> incoming file extension and always returns the error page as html.
>  
> I would expect that an "errorhandler" script/servlet registered with 
> ("sling.servlet.resourceTypes=sling/servlet/errorhandler", 
> "sling.servlet.extensions=json", "sling.servlet.methods=404") should be 
> preferred when the incoming request has a .json extension, and then use the 
> original html error response as a fallback for all other scenarios.
>  
> Basically the client should get JSON back when something goes wrong instead 
> of html that won't parse as JSON.



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

[jira] [Commented] (SLING-7836) Resolving the error handling scripts should consider the request file extension

[Eric Norman (Jira)]

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

Eric Norman commented on SLING-7836:


Integration test added to confirm the fix at: 
[https://github.com/apache/sling-org-apache-sling-launchpad-integration-tests/commit/ce66b636685295fc467f3cc78f6ae66817db2a85]

> Resolving the error handling scripts should consider the request file 
> extension
> ---
>
> Key: SLING-7836
> URL: https://issues.apache.org/jira/browse/SLING-7836
> Project: Sling
>  Issue Type: Improvement
>Affects Versions: Servlets Resolver 2.4.20, Launchpad Integration Tests 
> 1.0.6
>Reporter: Eric Norman
>Assignee: Eric Norman
>Priority: Major
> Fix For: Servlets Resolver 2.7.6
>
>
> I am expecting that a request to [http://localhost:8080/bogus.json] should 
> return a JSON response with the 404 error details in JSON when the resource 
> doesn't exist.  (also similar behavior should be possible for a .txt or .xml 
> file extension)
>  
> What I see currently is that SlingServletResolver#handleError ignores the 
> incoming file extension and always returns the error page as html.
>  
> I would expect that an "errorhandler" script/servlet registered with 
> ("sling.servlet.resourceTypes=sling/servlet/errorhandler", 
> "sling.servlet.extensions=json", "sling.servlet.methods=404") should be 
> preferred when the incoming request has a .json extension, and then use the 
> original html error response as a fallback for all other scenarios.
>  
> Basically the client should get JSON back when something goes wrong instead 
> of html that won't parse as JSON.



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

[Jenkins] Sling » Modules » sling-org-apache-sling-starter » master #9 is FIXED

[Apache Jenkins Server]

Please see 
https://ci-builds.apache.org/job/Sling/job/modules/job/sling-org-apache-sling-starter/job/master/9/
 for details.

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

[jira] [Closed] (SLING-9661) Upgrade to parent 39

[Eric Norman (Jira)]

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

Eric Norman closed SLING-9661.
--

Completed with the 2.7.6 release

> Upgrade to parent 39
> 
>
> Key: SLING-9661
> URL: https://issues.apache.org/jira/browse/SLING-9661
> Project: Sling
>  Issue Type: Sub-task
>Reporter: Eric Norman
>Assignee: Eric Norman
>Priority: Minor
> Fix For: Servlets Resolver 2.7.6
>
>
> Update to version 39 of the {{sling-bundle-parent}} pom, in order to pick up 
> the latest fixes.



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

Re: [RESULT] [VOTE] Release Apache Sling Servlets Resolver 2.7.6

[Eric Norman]

FYI: I was granted sufficient rights to do the copy myself so I no longer
require PMC assistance to complete the release activities.

Regards,
Eric

On Tue, Aug 18, 2020 at 9:30 AM Eric Norman  wrote:

> Hi,
>
> The vote has passed with the following result :
>
> +1 (binding): Robert Munteanu, Nicolas Peltier, Radu Cotescu
> +1 (non binding): Eric Norman
>
> I need someone from the PMC to copy the release to the Sling dist
> directory. Once that is done I will promote this to the central Maven
> repository and update JIRA and the website.
>

[Jenkins] Sling » Modules » sling-org-apache-sling-starter » master #8 is BROKEN

[Apache Jenkins Server]

3f)
Maven home: /home/jenkins/tools/maven/latest
Java version: 1.8.0_252, vendor: Oracle Corporation, runtime: 
/usr/local/asfpackages/java/openjdk-8u252-b09/jre
Default locale: en_US, platform encoding: ISO-8859-1
OS name: "linux", version: "4.15.0-74-generic", arch: "amd64", family: "unix"
[INFO] [jenkins-event-spy] Generate 
/home/jenkins/workspace/_org-apache-sling-starter_master@tmp/withMaveneee83868/maven-spy-20200819-180108-978039676754004042775.log.tmp
 ...
[INFO] Scanning for projects...
[INFO] 
[INFO] -< org.apache.sling:org.apache.sling.starter >--
[INFO] Building Apache Sling Starter Application 12-SNAPSHOT
[INFO] [ jar ]-
[INFO] Downloading from central: 
https://repo.maven.apache.org/maven2/org/apache/sling/org.apache.sling.servlets.resolver/2.7.6/org.apache.sling.servlets.resolver-2.7.6.pom
[WARNING] The POM for 
org.apache.sling:org.apache.sling.servlets.resolver:jar:2.7.6 is missing, no 
dependency information available
[INFO] Downloading from central: 
https://repo.maven.apache.org/maven2/org/apache/sling/org.apache.sling.servlets.resolver/2.7.6/org.apache.sling.servlets.resolver-2.7.6.jar
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time:  7.446 s
[INFO] Finished at: 2020-08-19T18:01:15Z
[INFO] ----
[INFO] [jenkins-event-spy] Generated 
/home/jenkins/workspace/_org-apache-sling-starter_master@tmp/withMaveneee83868/maven-spy-20200819-180108-978039676754004042775.log
[ERROR] Failed to execute goal on project org.apache.sling.starter: Could not 
resolve dependencies for project 
org.apache.sling:org.apache.sling.starter:jar:12-SNAPSHOT: Could not find 
artifact org.apache.sling:org.apache.sling.servlets.resolver:jar:2.7.6 in 
central (https://repo.maven.apache.org/maven2) -> [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/DependencyResolutionException
[Pipeline] }
[DevOpticsMavenPublisher] dependencies consumed: 0, artifacts produced: 0
[withMaven] Publishers: Generated Artifacts Publisher: 1031 ms, Open Task 
Scanner Publisher: 278 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

Re: Welcome Eric Norman as a Sling PMC member!

[Nicolas Peltier]

Welcome Eric!

Nicolas

Le mer. 19 août 2020 à 16:50, Georg Henzler  a écrit :

> Welcome Eric!
>
> -Georg
>
> > On 19. Aug 2020, at 16:44, Bertrand Delacretaz 
> wrote:
> >
> > Hi,
> >
> >> On Wed, Aug 19, 2020 at 4:10 PM Robert Munteanu 
> wrote:
> >> ...I'm pleased to announce that the Sling PMC has just elected Eric as
> >> a new PMC member, and he has accepted...
> >
> > Welcome Eric!
> >
> > -Bertrand
>

Re: Welcome Eric Norman as a Sling PMC member!

[Georg Henzler]

Welcome Eric!

-Georg 

> On 19. Aug 2020, at 16:44, Bertrand Delacretaz  wrote:
> 
> Hi,
> 
>> On Wed, Aug 19, 2020 at 4:10 PM Robert Munteanu  wrote:
>> ...I'm pleased to announce that the Sling PMC has just elected Eric as
>> a new PMC member, and he has accepted...
> 
> Welcome Eric!
> 
> -Bertrand

Re: Welcome Eric Norman as a Sling PMC member!

[Bertrand Delacretaz]

Hi,

On Wed, Aug 19, 2020 at 4:10 PM Robert Munteanu  wrote:
> ...I'm pleased to announce that the Sling PMC has just elected Eric as
> a new PMC member, and he has accepted...

Welcome Eric!

-Bertrand

[jira] [Comment Edited] (SLING-9662) Introduce a Resource Mapping SPI

[Georg Henzler (Jira)]

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

Georg Henzler edited comment on SLING-9662 at 8/19/20, 2:18 PM:


One open question is how we deal with the lifecycle of ResourceResolvers (and 
ResourceResolverFactory resp.) compared to the ResourceToUriMapper services - 
ATM the lifecycle is independent [1], references to 
ResourceResolver/ResourceResolverFactory remain intact if a ResourceToUriMapper 
vanishes (e.g. during a deployment) and the respective mapping will just be 
"missing" during this time (which could potentially lead to problems, but a 
ServiceUnavailableFilter can be configured to mitigate). I think this behaviour 
is in line with changes to /etc/maps (here the bundle is also not restarted 
upon changes IIRC). We could introduce a config property 
"requiredResourceToUriMapperServices" that the activator for the 
ResourceResolverFactory waits for, but if not needed I would like to avoid the 
complexity.

[~cziegeler] [~rombert] Do you see a problem with the current referencing 
approach as it is on branch [1]? 

[1] 
https://github.com/apache/sling-org-apache-sling-resourceresolver/blob/9a703ac38bee64c6ebe73b5c4df3b56307fdaed0/src/main/java/org/apache/sling/resourceresolver/impl/mappingchain/ResourceUriMappingChain.java#L53


was (Author: henzlerg):
One open question is how we deal the the lifecycle of the ResourceResolver (and 
ResourceResolverFactory resp.) compared to the ResourceToUriMapper services - 
ATM the lifecycle is independent [1], references to 
ResourceResolver/ResourceResolverFactory remain intact if a ResourceToUriMapper 
vanishes (e.g. during a deployment) and the respective mapping will be just 
"missing" during this time (which could potentially lead to problems, but a 
ServiceUnavailableFilter can be configured to mitigate). I think this behaviour 
is in line with changes to /etc/maps (here the bundle is also not restarted 
upon changes IIRC). We could introduce a config property 
"requiredResourceToUriMapperServices" that the activator for the 
ResourceResolverFactory waits for, but if not needed I would like to avoid the 
complexity.

[~cziegeler] [~rombert] Do you see a problem with the current approach as it is 
on branch [1]? 

[1] 
https://github.com/apache/sling-org-apache-sling-resourceresolver/blob/9a703ac38bee64c6ebe73b5c4df3b56307fdaed0/src/main/java/org/apache/sling/resourceresolver/impl/mappingchain/ResourceUriMappingChain.java#L53

> Introduce a Resource Mapping SPI
> 
>
> Key: SLING-9662
> URL: https://issues.apache.org/jira/browse/SLING-9662
> Project: Sling
>  Issue Type: New Feature
>  Components: API
>Reporter: Georg Henzler
>Assignee: Georg Henzler
>Priority: Major
>
> Introduce a simple SPI that allows to contribute to the resource resolver's 
> map() and resolve() methods:
> *ResourceUri:*
> General purpose class to represent a ResourceUri (like e.g. a link in an html 
>  tag). Immutable itself but adjustable using the builder pattern. Part of 
> the Sling API and can be used anywhere to simplify handling/modification of 
> Sling ResourceUri. Implements RequestPathInfo. ResourceUri can be created 
> easily from a String, a Request, a Resource, a URI or a RequestPathInfo.
> *ResourceToUriMapper:*
> SPI interface to be implemented as OSGi Service. All registered services 
> build a conceptual chain sorted by service ranking. The resource link is 
> passed through the chain while any ResourceToUriMapper chain member may or 
> may not make adjustments to the resource link.
>  rr.resolve() passes through the chain starting at the ResourceToUriMapper 
> with the highest service ranking and rr.map() passes through 
> the chain starting at the ResourceToUriMapper with the 
> lowest service ranking
> _Mailing List References:_
>  [https://www.mail-archive.com/dev@sling.apache.org/msg93537.html] 
>  [https://www.mail-archive.com/dev@sling.apache.org/msg87736.html]



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

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

[Radu Cotescu (Jira)]

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

Radu Cotescu resolved SLING-9671.
-
Resolution: Fixed

Fixed in [commit 
5f34369|https://github.com/apache/sling-org-apache-sling-scripting-sightly/commit/5f34369].

> 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
>
> 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] [Resolved] (SLING-9672) Expose vanity paths from ResourceMapper.getAllMappings()

[Robert Munteanu (Jira)]

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

Robert Munteanu resolved SLING-9672.

Resolution: Fixed

> Expose vanity paths from ResourceMapper.getAllMappings()
> 
>
> Key: SLING-9672
> URL: https://issues.apache.org/jira/browse/SLING-9672
> Project: Sling
>  Issue Type: Improvement
>  Components: ResourceResolver
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: Resource Resolver 1.6.18
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> With SLING-9622 we have removed all the complexity of knowing about aliases, 
> vanity paths, mappings from the auth core bundle. However, the ResourceMapper 
> does not expose vanity paths.
> We can include this information and return more paths from 
> ResourceMapper.getAllMappings, as long as we make sure that we do not alter 
> the way the ResourceMapper.getMapping / ResourceResolver.map() methods work.



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

[GitHub] [sling-org-apache-sling-resourceresolver] rombert merged pull request #19: SLING-9672 - Expose vanity paths from ResourceMapper.getAllMappings()

[GitBox]

rombert merged pull request #19:
URL: https://github.com/apache/sling-org-apache-sling-resourceresolver/pull/19


   



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

Welcome Eric Norman as a Sling PMC member!

[Robert Munteanu]

Hi Sling community,

I'm pleased to announce that the Sling PMC has just elected Eric as
a new PMC member, and he has accepted.

Eric has been making steady and good contributions to Sling for
quite some time, so I think this is very well deserved.

Congrats and welcome!

Thanks,
Robert

[jira] [Commented] (SLING-9662) Introduce a Resource Mapping SPI

[Georg Henzler (Jira)]

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

Georg Henzler commented on SLING-9662:
--

One open question is how we deal the the lifecycle of the ResourceResolver (and 
ResourceResolverFactory resp.) compared to the ResourceToUriMapper services - 
ATM the lifecycle is independent [1], references to 
ResourceResolver/ResourceResolverFactory remain intact if a ResourceToUriMapper 
vanishes (e.g. during a deployment) and the respective mapping will be just 
"missing" during this time (which could potentially lead to problems, but a 
ServiceUnavailableFilter can be configured to mitigate). I think this behaviour 
is in line with changes to /etc/maps (here the bundle is also not restarted 
upon changes IIRC). We could introduce a config property 
"requiredResourceToUriMapperServices" that the activator for the 
ResourceResolverFactory waits for, but if not needed I would like to avoid the 
complexity.

[~cziegeler] [~rombert] Do you see a problem with the current approach as it is 
on branch [1]? 

[1] 
https://github.com/apache/sling-org-apache-sling-resourceresolver/blob/9a703ac38bee64c6ebe73b5c4df3b56307fdaed0/src/main/java/org/apache/sling/resourceresolver/impl/mappingchain/ResourceUriMappingChain.java#L53

> Introduce a Resource Mapping SPI
> 
>
> Key: SLING-9662
> URL: https://issues.apache.org/jira/browse/SLING-9662
> Project: Sling
>  Issue Type: New Feature
>  Components: API
>Reporter: Georg Henzler
>Assignee: Georg Henzler
>Priority: Major
>
> Introduce a simple SPI that allows to contribute to the resource resolver's 
> map() and resolve() methods:
> *ResourceUri:*
> General purpose class to represent a ResourceUri (like e.g. a link in an html 
>  tag). Immutable itself but adjustable using the builder pattern. Part of 
> the Sling API and can be used anywhere to simplify handling/modification of 
> Sling ResourceUri. Implements RequestPathInfo. ResourceUri can be created 
> easily from a String, a Request, a Resource, a URI or a RequestPathInfo.
> *ResourceToUriMapper:*
> SPI interface to be implemented as OSGi Service. All registered services 
> build a conceptual chain sorted by service ranking. The resource link is 
> passed through the chain while any ResourceToUriMapper chain member may or 
> may not make adjustments to the resource link.
>  rr.resolve() passes through the chain starting at the ResourceToUriMapper 
> with the highest service ranking and rr.map() passes through 
> the chain starting at the ResourceToUriMapper with the 
> lowest service ranking
> _Mailing List References:_
>  [https://www.mail-archive.com/dev@sling.apache.org/msg93537.html] 
>  [https://www.mail-archive.com/dev@sling.apache.org/msg87736.html]



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

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

[Apache Jenkins Server]

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

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

[jira] [Created] (SLING-9674) Allow SlingHttpServletRequest based adaptations for ChildResourceInjector

[Konrad Windszus (Jira)]

Konrad Windszus created SLING-9674:
--

 Summary: Allow SlingHttpServletRequest based adaptations for 
ChildResourceInjector
 Key: SLING-9674
 URL: https://issues.apache.org/jira/browse/SLING-9674
 Project: Sling
  Issue Type: Improvement
  Components: Sling Models
Reporter: Konrad Windszus
 Fix For: Sling Models Impl 1.4.14


The {{ChildResourceInjector}} always returns one/multiple Resource objects 
which makes it impossible to use those return values with another Sling Model 
requiring the adaptable {{SlingHttpServletRequest}}. 
A solution from ACS Commons introduced 
https://adobe-consulting-services.github.io/acs-aem-commons/features/sling-model-injectors/child-resource-from-request/index.html
 in https://github.com/Adobe-Consulting-Services/acs-aem-commons/pull/1920. 
There should be a solution built into Sling which allows for easier Sling Model 
aggregation.



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

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

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-9594:


Radu notes that we already have a script for badges at 
https://github.com/apache/sling-aggregator/blob/master/add-badges.sh - that 
needs to be adapted. I haven't tested how it handles updates in existing 
READMEs.

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

Re: [builds] badges and links to builds.a.o are broken - here's a script to fix them

[Radu Cotescu]

Hi Bertrand,

We already have a script [3] that manages all badges - we just need to update 
it.

Thanks,
Radu

[3] - https://github.com/apache/sling-aggregator/blob/master/add-badges.sh 


> On 19 Aug 2020, at 12:37, Bertrand Delacretaz  wrote:
> 
> Hi,
> 
> With the SLING-9594 move to https://ci-builds.apache.org/, the build
> badges and links in our README files are broken.
> 
> There was a discussion of infra implementing redirects but I'm not
> sure if that's happening and not sure if that would work for things
> like [1]) anyway, so I wrote a script at [2] to adapt the links.
> 
> I've tried it on 3 modules so far, if someone feels courageous feel
> free to write a loop over all our repositories ;-)
> 
> -Bertrand
> 
> [1] 
> https://img.shields.io/jenkins/t/https/ci-builds.apache.org/job/Sling/job/modules/job/sling-org-apache-sling-api/job/master.svg
> 
> [2] 
> https://github.com/apache/sling-tooling-jenkins/tree/master/move-to-ci-builds

[builds] badges and links to builds.a.o are broken - here's a script to fix them

[Bertrand Delacretaz]

Hi,

With the SLING-9594 move to https://ci-builds.apache.org/, the build
badges and links in our README files are broken.

There was a discussion of infra implementing redirects but I'm not
sure if that's happening and not sure if that would work for things
like [1]) anyway, so I wrote a script at [2] to adapt the links.

I've tried it on 3 modules so far, if someone feels courageous feel
free to write a loop over all our repositories ;-)

-Bertrand

[1] 
https://img.shields.io/jenkins/t/https/ci-builds.apache.org/job/Sling/job/modules/job/sling-org-apache-sling-api/job/master.svg

[2] 
https://github.com/apache/sling-tooling-jenkins/tree/master/move-to-ci-builds

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

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz edited comment on SLING-9594 at 8/19/20, 10:11 AM:
---

Thank you for this! One thing left is to adapt the build badges and links in 
our modules README files.

I have written a (first shot at a) script that does this at 
https://github.com/apache/sling-tooling-jenkins/tree/master/move-to-ci-builds 
and used it successfully for these modules:

* https://github.com/apache/sling-org-apache-sling-graphql-core/
* https://github.com/apache/sling-org-apache-sling-api
* https://github.com/apache/sling-samples

I've mentioned that script on our dev list.


was (Author: bdelacretaz):
Thank you for this! One thing left is to adapt the build badges and links in 
our modules README files.

I have written a (first shot at a) script that does this at 
https://github.com/apache/sling-tooling-jenkins/tree/master/move-to-ci-builds 
and used it successfully for these modules:

* https://github.com/apache/sling-org-apache-sling-graphql-core/
* https://github.com/apache/sling-org-apache-sling-api
* https://github.com/apache/sling-samples

> 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] [Commented] (SLING-9594) Move Sling builds to ci-builds.apache.org

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-9594:


Thank you for this! One thing left is to adapt the build badges and links in 
our modules README files.

I have written a (first shot at a) script that does this at 
https://github.com/apache/sling-tooling-jenkins/tree/master/move-to-ci-builds 
and used it successfully for these modules:

* https://github.com/apache/sling-org-apache-sling-graphql-core/
* https://github.com/apache/sling-org-apache-sling-api
* https://github.com/apache/sling-samples

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