from:"Georg Henzler"



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

Georg Henzler resolved SLING-9859.
--
Resolution: Fixed

Fixed in 
[7c331cde0c821c|https://github.com/apache/sling-org-apache-sling-hc-support/commit/7c331cde0c821c35e60cd2c8e7323a4e765f5ba4]

> Avoid import of package of o.a.felix.hc.generalchecks.util
> --
>
> Key: SLING-9859
> URL: https://issues.apache.org/jira/browse/SLING-9859
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check
>Affects Versions: Health Check Support 1.0.6
>    Reporter: Georg Henzler
>    Assignee: Georg Henzler
>Priority: Major
> Fix For: Health Check Support 1.0.8
>
>
> Depending on setup, some Sling instances do not make 
> org.apache.felix.hc.generalchecks.util available to bundle 
> org.apache.sling.hc.support du to API region restrictions. To ensure 
> org.apache.sling.hc.support  can be used in all setups, use 
> Conditional-Package to inline the util package



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

[jira] [Created] (SLING-9859) Avoid import of package of o.a.felix.hc.generalchecks.util

Georg Henzler created SLING-9859:


 Summary: Avoid import of package of o.a.felix.hc.generalchecks.util
 Key: SLING-9859
 URL: https://issues.apache.org/jira/browse/SLING-9859
 Project: Sling
  Issue Type: Improvement
  Components: Health Check
Affects Versions: Health Check Support 1.0.6
Reporter: Georg Henzler
Assignee: Georg Henzler
 Fix For: Health Check Support 1.0.8


Depending on setup, some Sling instances do not make 
org.apache.felix.hc.generalchecks.util available to bundle 
org.apache.sling.hc.support du to API region restrictions. To ensure 
org.apache.sling.hc.support  can be used in all setups, use Conditional-Package 
to inline the util package



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

[jira] [Closed] (SLING-7246) Document changes for SLING-6855 and SLING-6946



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

Georg Henzler closed SLING-7246.


> Document changes for SLING-6855 and SLING-6946
> --
>
> Key: SLING-7246
> URL: https://issues.apache.org/jira/browse/SLING-7246
> Project: Sling
>  Issue Type: Task
>  Components: Health Check
>Reporter: Karl Pauls
>    Assignee: Georg Henzler
>Priority: Major
>
> Moving out the pending documentation for SLING-6855 and SLING-6946 to this 
> issue. [~henzlerg], please follow-up wrt. the missing documentation (if any) 
> using this issue.



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

[jira] [Updated] (SLING-7246) Document changes for SLING-6855 and SLING-6946



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

Georg Henzler updated SLING-7246:
-
Fix Version/s: (was: Health Check Core 1.2.12)

> Document changes for SLING-6855 and SLING-6946
> --
>
> Key: SLING-7246
> URL: https://issues.apache.org/jira/browse/SLING-7246
> Project: Sling
>  Issue Type: Task
>  Components: Health Check
>Reporter: Karl Pauls
>    Assignee: Georg Henzler
>Priority: Major
>
> Moving out the pending documentation for SLING-6855 and SLING-6946 to this 
> issue. [~henzlerg], please follow-up wrt. the missing documentation (if any) 
> using this issue.



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

[jira] [Resolved] (SLING-9777) Better handling for invalid URIs when using SlingUri (special characters, spaces)

2020-10-08 Thread Georg Henzler (Jira)



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

Georg Henzler resolved SLING-9777.
--
Resolution: Fixed

> Better handling for invalid URIs when using SlingUri (special characters, 
> spaces) 
> --
>
> Key: SLING-9777
> URL: https://issues.apache.org/jira/browse/SLING-9777
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Affects Versions: API 2.23.0
>    Reporter: Georg Henzler
>Assignee: Georg Henzler
>Priority: Major
> Fix For: API 2.23.2
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> SlingUri should not "have an opinion" about when URIs should be encoded or 
> not. It should be able to deal with invalid URIs in a best effort manner 
> (e.g. URIs containing a space in the path are already invalid) and always try 
> to not change the identity of the URI (means: 
> {{UriBuilder.parse(inputStr,null).build().toString()}} should almost always 
> be equal to the original {{inputStr}}). This also means if the SlingUri 
> contains escape sequences (e.g. %20), it should keep them, if escape 
> sequences are unescaped already this is also fine when using the builder 
> (when using parse() this can lead to invalid URIs, best effort parsing shall 
> be used for those cases). 



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

[jira] [Commented] (SLING-9777) Better handling for invalid URIs when using SlingUri (special characters, spaces)

2020-10-01 Thread Georg Henzler (Jira)



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

Georg Henzler commented on SLING-9777:
--

PR: https://github.com/apache/sling-org-apache-sling-api/pull/24

> Better handling for invalid URIs when using SlingUri (special characters, 
> spaces) 
> --
>
> Key: SLING-9777
> URL: https://issues.apache.org/jira/browse/SLING-9777
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Affects Versions: API 2.23.0
>    Reporter: Georg Henzler
>Assignee: Georg Henzler
>Priority: Major
> Fix For: API 2.23.2
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> SlingUri should not "have an opinion" about when URIs should be encoded or 
> not. It should be able to deal with invalid URIs in a best effort manner 
> (e.g. URIs containing a space in the path are already invalid) and always try 
> to not change the identity of the URI (means: 
> {{UriBuilder.parse(inputStr,null).build().toString()}} should almost always 
> be equal to the original {{inputStr}}). This also means if the SlingUri 
> contains escape sequences (e.g. %20), it should keep them, if escape 
> sequences are unescaped already this is also fine when using the builder 
> (when using parse() this can lead to invalid URIs, best effort parsing shall 
> be used for those cases). 



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

Re: [DISCUSS] Sling URI Mapping SPI (was Resource Mapping SPI)

2020-09-30 Thread Georg Henzler


Hi all,

so I created the PRs:
https://github.com/apache/sling-org-apache-sling-api/pull/25
https://github.com/apache/sling-org-apache-sling-resourceresolver/pull/22
https://github.com/apache/sling-org-apache-sling-engine/pull/10
https://github.com/apache/sling-org-apache-sling-auth-core/pull/6

Jenkins is failing due to not having the API SNAPSHOT from the branch,
I'll try to create/deploy a dedicated SNAPSHOT version from the API
branch to Maven Central (as I assume the PRs will be open for a bit
for testing and it would be nice to have the builds green).

-Georg


On 2020-09-30 12:09, Georg Henzler wrote:

Hi Carsten,


@Georg - I think it would be good if you create PRs, so we can better
review and comment on the changes


Thanks a lot - I'll quickly cross-test and create a PR this evening
(I have an improvement for SlingUri as well, but that's independent)

-Georg

[jira] [Commented] (SLING-9777) Better handling for invalid URIs when using SlingUri (special characters, spaces)

2020-09-30 Thread Georg Henzler (Jira)



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

Georg Henzler commented on SLING-9777:
--

The PR for SLING-7000 https://github.com/apache/sling-old-svn-mirror/pull/247 
introduced {{unescapePercentInQuery}} in 
https://github.com/Buuhuu/sling/blob/72516b5072c2b22e2c95adc094446eaaee835d02/bundles/scripting/sightly/engine/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/URIManipulationFilterExtension.java#L126
 - with the approach as described in this ticket and after using SlingUri 
there, this should not be needed anymore - FYI [~kwin] [~diru]

> Better handling for invalid URIs when using SlingUri (special characters, 
> spaces) 
> --
>
> Key: SLING-9777
> URL: https://issues.apache.org/jira/browse/SLING-9777
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Affects Versions: API 2.23.0
>    Reporter: Georg Henzler
>Assignee: Georg Henzler
>Priority: Major
> Fix For: API 2.23.2
>
>
> SlingUri should not "have an opinion" about when URIs should be encoded or 
> not. It should be able to deal with invalid URIs in a best effort manner 
> (e.g. URIs containing a space in the path are already invalid) and always try 
> to not change the identity of the URI (means: 
> {{UriBuilder.parse(inputStr,null).build().toString()}} should almost always 
> be equal to the original {{inputStr}}). This also means if the SlingUri 
> contains escape sequences (e.g. %20), it should keep them, if escape 
> sequences are unescaped already this is also fine when using the builder 
> (when using parse() this can lead to invalid URIs, best effort parsing shall 
> be used for those cases). 



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

[jira] [Created] (SLING-9777) Better handling for invalid URIs when using SlingUri (special characters, spaces)

2020-09-30 Thread Georg Henzler (Jira)

Georg Henzler created SLING-9777:


 Summary: Better handling for invalid URIs when using SlingUri 
(special characters, spaces) 
 Key: SLING-9777
 URL: https://issues.apache.org/jira/browse/SLING-9777
 Project: Sling
  Issue Type: Improvement
  Components: API
Affects Versions: API 2.23.0
Reporter: Georg Henzler
Assignee: Georg Henzler
 Fix For: API 2.23.2


SlingUri should not "have an opinion" about when URIs should be encoded or not. 
It should be able to deal with invalid URIs in a best effort manner (e.g. URIs 
containing a space in the path are already invalid) and always try to not 
change the identity of the URI (means: 
{{UriBuilder.parse(inputStr,null).build().toString()}} should almost always be 
equal to the original {{inputStr}}). This also means if the SlingUri contains 
escape sequences (e.g. %20), it should keep them, if escape sequences are 
unescaped already this is also fine when using the builder (when using parse() 
this can lead to invalid URIs, best effort parsing shall be used for those 
cases). 





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

Re: [DISCUSS] Sling URI Mapping SPI (was Resource Mapping SPI)

2020-09-30 Thread Georg Henzler


Hi Carsten,


@Georg - I think it would be good if you create PRs, so we can better
review and comment on the changes


Thanks a lot - I'll quickly cross-test and create a PR this evening
(I have an improvement for SlingUri as well, but that's independent)

-Georg



Regards
Carsten

Am 29.09.2020 um 11:44 schrieb Carsten Ziegeler:

Thanks Georg,

I had a quick look at the auth.core changes. They cover the basic 
flow, but we also need to remove the usage of the ResourceMapper (in 
the service listener). Unfortunately, this requires a rewrite of most 
of the tests, I'll try to have a look at this in the next days.


Regards
Carsten

Am 23.09.2020 um 11:06 schrieb Georg Henzler:

Hi all,

so "SlingUri" (with now improved name) as prerequisite for
the Mapping SPI has now been fixed via SLING-9745 and is on
master. This alone is just a utility - no behaviour of
resolve() or map() has been changed (yet).

With the changes [1] [2] [3] [4] (only on branches so far)
the URI mapping is moved before authentication - this will
improve the situation for auth requirements as Carsten
outlined in [5]. I have tested this in both Sling Starter
and the famous Sling-based CMS and it works well.

For now the updated proposal keeps out context hints (like
e.g. "link invalid") for simplicity, we can can add this
later (if we wanted to allow for link checking to get rid
of the need for the rewriter pipeline that takes this
responsibility in a Sling-based CMS)

I think it'll good to discuss this at the round table next
Monday, however it would be great if people could already
provide feedback to the API changes in [1] to see if that
makes sense for everyone.

-Georg

[1] Sling API Changes
https://github.com/apache/sling-org-apache-sling-api/compare/master...feature/SLING-9662-Introduce-SlingUri-Mapping-SPI-v3 
[2] Auth Core
https://github.com/apache/sling-org-apache-sling-auth-core/compare/master...feature/SLING-9662-Introduce-SlingUri-Mapping-SPI-v3 
[3] Engine
https://github.com/apache/sling-org-apache-sling-engine/compare/master...feature/SLING-9662-Introduce-SlingUri-Mapping-SPI-v3 
[4] Resource Resolver
https://github.com/apache/sling-org-apache-sling-resourceresolver/compare/master...feature/SLING-9662-Introduce-SlingUri-Mapping-SPI-v3 
[5]
https://issues.apache.org/jira/browse/SLING-9622?focusedCommentId=17182336=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17182336 
On 2020-09-20 21:46, Georg Henzler wrote:

Considering that URIs like 'mailto:j...@example.com', '?name=val'
or '#fragment' do not relate to a resource and thinking about it
a bit more, I would now propose to change the name of
ResourceUri/ResourceUriBuilder to SlingUri/SlingUriBuilder
(see also [1]) - objections?

-Georg

[1]
https://github.com/apache/sling-org-apache-sling-api/pull/23#discussion_r491726353 
On 2020-09-18 11:14, Georg Henzler wrote:

Hi all,

to not have too many changes in one issue and PR to review,
I created SLING-9745 and PR [1] for the ResourceUri and
its builder. The unit test coverage is good (~85%) and also
covers the tests from SlingRequestPathInfoTest [2] to
ensure compatibility. Timely feedback would be appreciated
as I would like to build upon this on Mon (with the next PR).

-Georg

[1]
https://github.com/apache/sling-org-apache-sling-api/pull/23
[2]
https://github.com/apache/sling-org-apache-sling-engine/blob/43673bddb4a2e79ef9bba813ec86a7faa89e7649/src/test/java/org/apache/sling/engine/impl/request/SlingRequestPathInfoTest.java#L28

[jira] [Updated] (SLING-9745) Introduce SlingUri API to simplify creation/manipulation of Sling URIs

2020-09-26 Thread Georg Henzler (Jira)



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

Georg Henzler updated SLING-9745:
-
Description: General purpose class to represent a SlingUri (like e.g. a 
link in an html  tag). Immutable itself but adjustable using the builder 
pattern (SlingUriBuilder). Part of the Sling API and can be used anywhere to 
simplify handling/modification of Sling Uris and implements RequestPathInfo. 
SlingUris can be created easily from a String, a Request, a Resource, a URI or 
a RequestPathInfo.  (was: General purpose class to represent a SlingUri (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.)

> Introduce SlingUri API to simplify creation/manipulation of Sling URIs
> --
>
> Key: SLING-9745
> URL: https://issues.apache.org/jira/browse/SLING-9745
> Project: Sling
>  Issue Type: New Feature
>  Components: API
>    Reporter: Georg Henzler
>    Assignee: Georg Henzler
>Priority: Major
> Fix For: API 2.23.0
>
>  Time Spent: 8h 50m
>  Remaining Estimate: 0h
>
> General purpose class to represent a SlingUri (like e.g. a link in an html 
>  tag). Immutable itself but adjustable using the builder pattern 
> (SlingUriBuilder). Part of the Sling API and can be used anywhere to simplify 
> handling/modification of Sling Uris and implements RequestPathInfo. SlingUris 
> can be created easily from a String, a Request, a Resource, a URI or a 
> RequestPathInfo.



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

Re: [VOTE] Release Apache Sling Scripting HTL Compiler 1.2.8-1.4.0, Apache Sling Scripting HTL Java Compiler 1.2.2-1.4.0, Apache Sling Scripting HTL Engine 1.4.4-1.4.0, Apache Sling Scripting HTL Runt

2020-09-26 Thread Georg Henzler


+1

-Georg

On 2020-09-25 20:32, Radu Cotescu wrote:

Hi,

We solved 6 issues in these releases:
https://issues.apache.org/jira/browse/SLING/fixforversion/12348731

https://issues.apache.org/jira/browse/SLING/fixforversion/12348730

https://issues.apache.org/jira/browse/SLING/fixforversion/12348726

https://issues.apache.org/jira/browse/SLING/fixforversion/12348719

https://issues.apache.org/jira/browse/SLING/fixforversion/12348751

https://issues.apache.org/jira/browse/SLING/fixforversion/12348732

https://issues.apache.org/jira/browse/SLING/fixforversion/12348677


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

https://repository.apache.org/content/repositories/orgapachesling-2342

https://repository.apache.org/content/repositories/orgapachesling-2343


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 2341 /tmp/sling-staging
sh check_staged_release.sh 2342 /tmp/sling-staging
sh check_staged_release.sh 2343 /tmp/sling-staging

Running the tests from Apache Sling Scripting HTL Testing 1.0.24-1.4.0
requires Apache Sling Scripting Core 2.3.4, currently under release as
well.

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,
Radu Cotescu

[RESULT][VOTE] Release Apache Sling API 2.23.0

2020-09-26 Thread Georg Henzler


Hi,

The vote has passed with the following result:

+1 (binding): Daniel Klco, Konrad Windszus, Radu Cotescu, Georg Henzler
+1 (non binding): Andreas Schaefer

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

-Georg

Re: [VOTE] Release Apache Sling Scripting Core 2.3.4

2020-09-26 Thread Georg Henzler


+1

-Georg

On 2020-09-25 20:14, Radu Cotescu wrote:

Hi,

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

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

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 2340 /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,
Radu Cotescu

Re: [VOTE] Release Apache Sling API 2.23.0

2020-09-25 Thread Georg Henzler


+1

-Georg

On 2020-09-23 20:58, Georg Henzler wrote:

Hi all,

We solved 6 issues in this release:
https://issues.apache.org/jira/projects/SLING/versions/12346965

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

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 2338 /tmp/sling-staging

Please vote to approve this release:

   [ ] +1 Approve the release
   [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Best regards,
Georg

[VOTE] Release Apache Sling API 2.23.0

2020-09-23 Thread Georg Henzler


Hi all,

We solved 6 issues in this release:
https://issues.apache.org/jira/projects/SLING/versions/12346965

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

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 2338 /tmp/sling-staging

Please vote to approve this release:

   [ ] +1 Approve the release
   [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Best regards,
Georg

Re: [VOTE] Release Apache Sling Feature Model 1.2.10, Feature Model API Regions Extension 1.1.8, OSGi Feature Maven Plugin 1.4.0

2020-09-23 Thread Georg Henzler


+1

Georg

On 2020-09-23 12:59, dav...@apache.org wrote:

Hi all,

I would like to call the release on the following Apache Sling Feature
Model related components:

Feature Model 1.2.10
https://issues.apache.org/jira/projects/SLING/versions/12348776

Feature Model API Regions Extension 1.1.8
https://issues.apache.org/jira/projects/SLING/versions/12348591

OSGi Feature Maven Plugin 1.4.0
https://issues.apache.org/jira/projects/SLING/versions/12348816

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

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 2337 /tmp/sling-staging

Please vote to approve this release:

   [ ] +1 Approve the release
   [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Best regards,

David

[jira] [Commented] (SLING-9762) Automatic Mapping of URIs in HTL



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

Georg Henzler commented on SLING-9762:
--

So for now it would be 
[rr.map()|https://sling.apache.org/apidocs/sling11/org/apache/sling/api/resource/ResourceResolver.html#map-javax.servlet.http.HttpServletRequest-java.lang.String-]
 - mid-term the idea would be to use [PathToUriMappingService.map(request, 
path)|https://github.com/apache/sling-org-apache-sling-api/blob/415ec0d4b3dfb184d653571364a07d821a890a10/src/main/java/org/apache/sling/api/resource/mapping/PathToUriMappingService.java#L67]
 (once this is implemented rr.map() will just call 
PathToUriMappingService.map())

With SLING-9662 implemented, the SPI interface 
[SlingUriMapper|https://github.com/apache/sling-org-apache-sling-api/blob/415ec0d4b3dfb184d653571364a07d821a890a10/src/main/java/org/apache/sling/spi/urimapping/SlingUriMapper.java]
 will allow to contribute custom mappings (while others might be fine with 
today's /etc/maps that will come as one ootb SlingUriMapper in the chain)

> Automatic Mapping of URIs in HTL
> 
>
> Key: SLING-9762
> URL: https://issues.apache.org/jira/browse/SLING-9762
> Project: Sling
>  Issue Type: New Feature
>  Components: Scripting
>    Reporter: Georg Henzler
>Assignee: Radu Cotescu
>Priority: Major
>
> There should be the possibility to automatically map non-absolute URIs in HTL 
> (that is 
> [URI.isAbsolute()|https://docs.oracle.com/javase/8/docs/api/java/net/URI.html#isAbsolute--]
>  = false). If all URIs are mapped automatically or not should be globally 
> configurable and then be overridden if necessary in HTL as follows:
> {code}
> 
> {code}
> If auto-mapping is globally deactivated, the following should allow to 
> activate it:
> {code}
> 
> {code}
> See https://www.mail-archive.com/dev@sling.apache.org/msg98145.html for 
> initial discussion



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

[jira] [Commented] (SLING-9762) Automatic Mapping of URIs in HTL



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

Georg Henzler commented on SLING-9762:
--

The idea is to map non-absolute URIs only, I updated the description.

> Automatic Mapping of URIs in HTL
> 
>
> Key: SLING-9762
> URL: https://issues.apache.org/jira/browse/SLING-9762
> Project: Sling
>  Issue Type: New Feature
>  Components: Scripting
>    Reporter: Georg Henzler
>Priority: Major
>
> There should be the possibility to automatically map non-absolute URIs in HTL 
> (that is 
> [URI.isAbsolute()|https://docs.oracle.com/javase/8/docs/api/java/net/URI.html#isAbsolute--]
>  = false). If all URIs are mapped automatically or not should be globally 
> configurable and then be overridden if necessary in HTL as follows:
> {code}
> 
> {code}
> If auto-mapping is globally deactivated, the following should allow to 
> activate it:
> {code}
> 
> {code}
> See https://www.mail-archive.com/dev@sling.apache.org/msg98145.html for 
> initial discussion



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

[jira] [Updated] (SLING-9762) Automatic Mapping of URIs in HTL



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

Georg Henzler updated SLING-9762:
-
Description: 
There should be the possibility to automatically map non-absolute URIs in HTL 
(that is 
[URI.isAbsolute()|https://docs.oracle.com/javase/8/docs/api/java/net/URI.html#isAbsolute--]
 = false). If all URIs are mapped automatically or not should be globally 
configurable and then be overridden if necessary in HTL as follows:

{code}

{code}

If auto-mapping is globally deactivated, the following should allow to activate 
it:
{code}

{code}

See https://www.mail-archive.com/dev@sling.apache.org/msg98145.html for initial 
discussion

  was:
There should be the possibility to automatically map URIs in HTL. If all URIs 
are mapped automatically or not should be globally configurable and then be 
overridden if necessary in HTL as follows:

{code}

{code}

If auto-mapping is globally deactivated, the following should allow to activate 
it:
{code}

{code}

See https://www.mail-archive.com/dev@sling.apache.org/msg98145.html for initial 
discussion


> Automatic Mapping of URIs in HTL
> 
>
> Key: SLING-9762
> URL: https://issues.apache.org/jira/browse/SLING-9762
> Project: Sling
>  Issue Type: New Feature
>  Components: Scripting
>    Reporter: Georg Henzler
>Priority: Major
>
> There should be the possibility to automatically map non-absolute URIs in HTL 
> (that is 
> [URI.isAbsolute()|https://docs.oracle.com/javase/8/docs/api/java/net/URI.html#isAbsolute--]
>  = false). If all URIs are mapped automatically or not should be globally 
> configurable and then be overridden if necessary in HTL as follows:
> {code}
> 
> {code}
> If auto-mapping is globally deactivated, the following should allow to 
> activate it:
> {code}
> 
> {code}
> See https://www.mail-archive.com/dev@sling.apache.org/msg98145.html for 
> initial discussion



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

Re: [DISCUSS] Sling URI Mapping SPI (was Resource Mapping SPI)

2020-09-23 Thread Georg Henzler


Hi all,

so "SlingUri" (with now improved name) as prerequisite for
the Mapping SPI has now been fixed via SLING-9745 and is on
master. This alone is just a utility - no behaviour of
resolve() or map() has been changed (yet).

With the changes [1] [2] [3] [4] (only on branches so far)
the URI mapping is moved before authentication - this will
improve the situation for auth requirements as Carsten
outlined in [5]. I have tested this in both Sling Starter
and the famous Sling-based CMS and it works well.

For now the updated proposal keeps out context hints (like
e.g. "link invalid") for simplicity, we can can add this
later (if we wanted to allow for link checking to get rid
of the need for the rewriter pipeline that takes this
responsibility in a Sling-based CMS)

I think it'll good to discuss this at the round table next
Monday, however it would be great if people could already
provide feedback to the API changes in [1] to see if that
makes sense for everyone.

-Georg

[1] Sling API Changes
https://github.com/apache/sling-org-apache-sling-api/compare/master...feature/SLING-9662-Introduce-SlingUri-Mapping-SPI-v3

[2] Auth Core
https://github.com/apache/sling-org-apache-sling-auth-core/compare/master...feature/SLING-9662-Introduce-SlingUri-Mapping-SPI-v3

[3] Engine
https://github.com/apache/sling-org-apache-sling-engine/compare/master...feature/SLING-9662-Introduce-SlingUri-Mapping-SPI-v3

[4] Resource Resolver
https://github.com/apache/sling-org-apache-sling-resourceresolver/compare/master...feature/SLING-9662-Introduce-SlingUri-Mapping-SPI-v3

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


On 2020-09-20 21:46, Georg Henzler wrote:

Considering that URIs like 'mailto:j...@example.com', '?name=val'
or '#fragment' do not relate to a resource and thinking about it
a bit more, I would now propose to change the name of
ResourceUri/ResourceUriBuilder to SlingUri/SlingUriBuilder
(see also [1]) - objections?

-Georg

[1]
https://github.com/apache/sling-org-apache-sling-api/pull/23#discussion_r491726353

On 2020-09-18 11:14, Georg Henzler wrote:

Hi all,

to not have too many changes in one issue and PR to review,
I created SLING-9745 and PR [1] for the ResourceUri and
its builder. The unit test coverage is good (~85%) and also
covers the tests from SlingRequestPathInfoTest [2] to
ensure compatibility. Timely feedback would be appreciated
as I would like to build upon this on Mon (with the next PR).

-Georg

[1]
https://github.com/apache/sling-org-apache-sling-api/pull/23
[2]
https://github.com/apache/sling-org-apache-sling-engine/blob/43673bddb4a2e79ef9bba813ec86a7faa89e7649/src/test/java/org/apache/sling/engine/impl/request/SlingRequestPathInfoTest.java#L28

Re: [DISCUSS] Automatic Mapping of URIs in HTL

2020-09-23 Thread Georg Henzler


I created issue SLING-9762 [1] for this.

-Georg

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

On 2020-09-11 16:55, Georg Henzler wrote:

Hi Paul


The reason I think both the global config and the local config are
necessary


good point, +1 (both "global on/disable for one uri locally" and
"global off/enable for one uri locally" are valid use cases)


.. JSON or some JS objects in HTL scripts (thinking on how many
times I had to go back and change a Sling Model to add URI mapping, 
because
a specific Sling-based product that uses a servlet filter does 
not/cannot

map values in JS/JSON).


IIRC for this product only html paths are mapped (and js/json paths 
need to be
mapped manually). The idea of this proposal is to map _any_ uri or 
_none_
depending on the global config (and allow to override per uri via 
param)



-Georg

[jira] [Created] (SLING-9762) Automatic Mapping of URIs in HTL

Georg Henzler created SLING-9762:


 Summary: Automatic Mapping of URIs in HTL
 Key: SLING-9762
 URL: https://issues.apache.org/jira/browse/SLING-9762
 Project: Sling
  Issue Type: New Feature
  Components: Scripting
Reporter: Georg Henzler


There should be the possibility to automatically map URIs in HTL. If all URIs 
are mapped automatically or not should be globally configurable and then be 
overridden if necessary in HTL as follows:

{code}

{code}

If auto-mapping is globally deactivated, the following should allow to activate 
it:
{code}

{code}



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

[jira] [Updated] (SLING-9762) Automatic Mapping of URIs in HTL



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

Georg Henzler updated SLING-9762:
-
Description: 
There should be the possibility to automatically map URIs in HTL. If all URIs 
are mapped automatically or not should be globally configurable and then be 
overridden if necessary in HTL as follows:

{code}

{code}

If auto-mapping is globally deactivated, the following should allow to activate 
it:
{code}

{code}

See https://www.mail-archive.com/dev@sling.apache.org/msg98145.html for initial 
discussion

  was:
There should be the possibility to automatically map URIs in HTL. If all URIs 
are mapped automatically or not should be globally configurable and then be 
overridden if necessary in HTL as follows:

{code}

{code}

If auto-mapping is globally deactivated, the following should allow to activate 
it:
{code}

{code}


> Automatic Mapping of URIs in HTL
> 
>
> Key: SLING-9762
> URL: https://issues.apache.org/jira/browse/SLING-9762
> Project: Sling
>  Issue Type: New Feature
>  Components: Scripting
>    Reporter: Georg Henzler
>Priority: Major
>
> There should be the possibility to automatically map URIs in HTL. If all URIs 
> are mapped automatically or not should be globally configurable and then be 
> overridden if necessary in HTL as follows:
> {code}
> 
> {code}
> If auto-mapping is globally deactivated, the following should allow to 
> activate it:
> {code}
> 
> {code}
> See https://www.mail-archive.com/dev@sling.apache.org/msg98145.html for 
> initial discussion



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

[jira] [Updated] (SLING-9662) Introduce an URI Mapping SPI



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

Georg Henzler updated SLING-9662:
-
Description: 
_an earlier version used the terms ResourceUri/ResourceToUriMapper (updated 
this description during the discussion)_ 

Introduce a simple SPI that allows to contribute to the resource resolver's 
map() and resolve() methods:

Prerequisite *SlingUri:* (SLING-9745 to be completed first)

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.

*SlingUriMapper:*

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 SlingUriMapper chain member may or may not make 
adjustments to the resource link.
 rr.resolve() passes through the chain starting at the SlingUriMapper with the 
highest service ranking and rr.map() passes through the chain 
starting at the SlingUriMapper with the lowest service ranking

*PathToUriMappingService:* 

The new OSGi service to provide path to URI resolution and path to URI mapping. 
The methods rr.resolve() and rr.map() and should delegate to this service.

 

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

  was:
_an earlier version used the terms ResourceUri/ResourceToUriMapper (updated 
this description during the discussion)_ 

Introduce a simple SPI that allows to contribute to the resource resolver's 
map() and resolve() methods:

Prerequisite *SlingUri:* (SLING-9745 to be completed first)

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.

*SlingUriMapper:*

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 SlingUriMapper chain member may or may not make 
adjustments to the resource link.
 rr.resolve() passes through the chain starting at the SlingUriMapper with the 
highest service ranking and rr.map() passes through the chain 
starting at the SlingUriMapper 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]


> Introduce an URI 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
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> _an earlier version used the terms ResourceUri/ResourceToUriMapper (updated 
> this description during the discussion)_ 
> Introduce a simple SPI that allows to contribute to the resource resolver's 
> map() and resolve() methods:
> Prerequisite *SlingUri:* (SLING-9745 to be completed first)
> 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.
> *SlingUriMapper:*
> 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 SlingUriMapper chain member may or may not 
> make adjustments to the resource link.
>  rr.resolve() passes through the chain starting at the SlingUriMapper with 
> the highest service ranking and rr.map() passes through the 
> chain starting at the SlingUriMapper with the lowest service 
> ranking
> *PathToUriMappingService:* 
> The new OSGi service to provide path to URI resolution and path to URI 
> mapping. The methods rr.resolve() and rr.map() and should delegate to this 
> service.
>  
> _Mailing Lis

Re: Jira version names vs Maven module names

2020-09-23 Thread Georg Henzler

Generally I'm also in favor of the artifactId because it
makes a proper id (as already stated). However it is a lot
of noise because all versions in JIRA project "SLING" will
start with "org.apache.sling.". So why not just use the
rule

substringAfter(artifactId, "org.apache.sling.") + "-" + version

That would give us versions like api-2.23.0, auth.core-1.5.1 etc.
The big advantage of this is that you see the actual version
number in JIRA UI (if the version string is very long, you only
see the prefix and the actual version is cut off, this really
has to be avoided and hence IMHO we cannot just use the
artifactID)

We don't need to change the past, we can just use the name
convention for the future for all releases... (and Robert can
fix the tooling to exactly one well-defined release name)

WDYT?

-Georg

On 2020-09-23 09:52, Carsten Ziegeler wrote:

Our base rule is that the BSN is the same as the artifact ID.
There might be some exceptions, sure, but that's probably neglectable.

At least I'm not arguing for doing a rename at this point in time -
but rather keep things just as they are. If someone feels strongely to
rename in Jira, that's fine.

Regards
Carsten

Am 23.09.2020 um 08:23 schrieb Konrad Windszus:

For bundles the artifact id is not that visible but the BSN is.
This is not necessarily the same.
So if we do a rename in JIRA we should take BSN for bundles and
artifact ID for Maven plugins.

Konrad

On 23. Sep 2020, at 08:08, David Bosschaert
wrote:

+1 to using Artifact IDs in JIRA. As mentioned by others, if for
example

someone finds a bug running the slingfeature-maven-plugin they would
probably have a hard time finding the component named 'OSGi Feature
Maven
Plugin'. To be sure they would have to go to the pom.xml of the
original

codebase and look for the name tag, which is:
Apache Sling OSGi Feature Maven Plugin
Then they'd have to take off the 'Apache Sling' prefix.

Another problem is that the name is not required to be unique. It
_should_

be, but with the ID you're sure that it's unique.

My 2c,

David

On Wed, 23 Sep 2020 at 06:09, Carsten Ziegeler
wrote:

Just to state it again, artifact name is really not useful for our
users
out there trying to file a bug against a module. Artifact id is in
their

face when they use these things, being it the plugin name, the maven
coordinates or the symbolic name. Everything is based on ids.
Ids are stable - names might change

Renaming the existing artifact ids in Jira to names, makes it worse.

We didn't have any problem with this for years, and I don't
understand

why a new tool developed by ourselves should force us now to change
things. Why can't the tool simply look for both, id and name - and
we're

done with this?

Regards
Carsten

Am 22.09.2020 um 20:38 schrieb Konrad Windszus:
I would also personally prefer artifact id instead of name in JIRA.
But
the majority of version names in JIRA is right now named after the
artifact

name (
https://issues.apache.org/jira/projects/SLING?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page=released).
Also our releases section currently uses artifact names (
https://sling.apache.org/releases.html).
We should do it consistently and I am not sure it is worth the
effort to
migrate all the release version names (would require some
scripting). I
would tend to say, for consistency and simplicity: Just turn the few
which

use artifact id right now into artifact name

Konrad

On 22. Sep 2020, at 18:59, Carsten Ziegeler

wrote:

I personally think its ok if we use the artifact name in jira,
like in
this case - especially as the name might change. Whatever we decide,
it
needs to be consistent across a module- meaning if we start to
rename with

version 1.4.0 then we also need to rename all previous versions.

Now from a customer perspective, if someone wants to file a bug
against
the slingfeature-maven-plugin (which is what is used and what is
visable in

the error from maven), I think someone finds
slingfeature-maven-plugin-1.4.0 much easier than 'OSGi Feature Maven
Plugin

1.4.0' which is nowhere visible in maven output.

Regards
Carsten

Am 22.09.2020 um 17:07 schrieb Robert Munteanu:

Hi,
I am in a middle of a release (and using the committer cli [1])
and I

got stuck due to an unexpected (for the tool) version:
java.lang.IllegalArgumentException: No releases found in
'slingfeature-maven-plugin-1.4.0'
To go for the quick fix, I renamed that version to 'OSGi Feature
Maven
Plugin 1.4.0', matching the module name. This is quickly
reversible so

I just did the change.
Of course, the tool can be changed, but there is some value IMO
in

having module names and Jira version names aligned, namely:
- it is clear for users and tools what release maps to which
module

- we don't have to invent a second name for the same thing :-)
I'm open to saying that version names can be arbitrary, but then
we can

simplify our life by having matching names.
Thanks,

Release of Sling API 2.23.0

2020-09-23 Thread Georg Henzler


Hi all,

for the Sling API, we had a version 2.22.2 that
was not released yet while the maven version is
already on 2.23.0-SNAPSHOT.

What I did now:

* moved fixed issues to API 2.23.0 [1]
* renamed API 2.22.2 to API 2.23.2 [2] (has 3 open issues now)

I would like to start a release vote for API 2.23.0
this evening, if somebody had something that should go
in now is a good time to speak up...

-Georg


[1] API 2.23.0
https://issues.apache.org/jira/projects/SLING/versions/12346965

[2] API 2.23.2
https://issues.apache.org/jira/projects/SLING/versions/12346686

[jira] [Updated] (SLING-9060) Improve Redirect handling for Resources that can be served from alternative URLs



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

Georg Henzler updated SLING-9060:
-
Fix Version/s: (was: Servlets Get 2.1.42)

> Improve Redirect handling for Resources that can be served from alternative 
> URLs
> 
>
> Key: SLING-9060
> URL: https://issues.apache.org/jira/browse/SLING-9060
> Project: Sling
>  Issue Type: Improvement
>  Components: API, Servlets
>Affects Versions: API 2.22.0, Servlets Get 2.1.40
>Reporter: Ian Boston
>Assignee: Ian Boston
>Priority: Major
>  Time Spent: 14h 20m
>  Remaining Estimate: 0h
>
> Improve the mechanism used to redirect streamed binary requests so that it 
> has the context of the request and can be extended without provider API 
> changes.
>  
> This was discussed on list at [https://markmail.org/message/msmxgulkmzx7czth 
> |https://markmail.org/message/msmxgulkmzx7czth]
> PR to follow



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

[jira] [Updated] (SLING-9060) Improve Redirect handling for Resources that can be served from alternative URLs



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

Georg Henzler updated SLING-9060:
-
Fix Version/s: (was: API 2.23.0)

> Improve Redirect handling for Resources that can be served from alternative 
> URLs
> 
>
> Key: SLING-9060
> URL: https://issues.apache.org/jira/browse/SLING-9060
> Project: Sling
>  Issue Type: Improvement
>  Components: API, Servlets
>Affects Versions: API 2.22.0, Servlets Get 2.1.40
>Reporter: Ian Boston
>Assignee: Ian Boston
>Priority: Major
> Fix For: Servlets Get 2.1.42
>
>  Time Spent: 14h 20m
>  Remaining Estimate: 0h
>
> Improve the mechanism used to redirect streamed binary requests so that it 
> has the context of the request and can be extended without provider API 
> changes.
>  
> This was discussed on list at [https://markmail.org/message/msmxgulkmzx7czth 
> |https://markmail.org/message/msmxgulkmzx7czth]
> PR to follow



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

[jira] [Commented] (SLING-9060) Improve Redirect handling for Resources that can be served from alternative URLs



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

Georg Henzler commented on SLING-9060:
--

Removed fix versions (to prepare API release)

> Improve Redirect handling for Resources that can be served from alternative 
> URLs
> 
>
> Key: SLING-9060
> URL: https://issues.apache.org/jira/browse/SLING-9060
> Project: Sling
>  Issue Type: Improvement
>  Components: API, Servlets
>Affects Versions: API 2.22.0, Servlets Get 2.1.40
>Reporter: Ian Boston
>Assignee: Ian Boston
>Priority: Major
>  Time Spent: 14h 20m
>  Remaining Estimate: 0h
>
> Improve the mechanism used to redirect streamed binary requests so that it 
> has the context of the request and can be extended without provider API 
> changes.
>  
> This was discussed on list at [https://markmail.org/message/msmxgulkmzx7czth 
> |https://markmail.org/message/msmxgulkmzx7czth]
> PR to follow



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

[jira] [Updated] (SLING-9140) utility to merge multiple value maps



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

Georg Henzler updated SLING-9140:
-
Fix Version/s: (was: API 2.22.2)
   API 2.23.0

>  utility to merge multiple value maps
> -
>
> Key: SLING-9140
> URL: https://issues.apache.org/jira/browse/SLING-9140
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Reporter: Nicolas Peltier
>Assignee: Julian Sedding
>Priority: Major
> Fix For: API 2.23.0
>
>  Time Spent: 10h 10m
>  Remaining Estimate: 0h
>
> utility class to provide a simple way to have a fallback valuemap
> discussed here 
> [https://lists.apache.org/thread.html/r0afe5f5d7c9537c25e7aedf466239047eedf4e88143376e10ae87b95%40%3Cdev.sling.apache.org%3E]
> and in the PR too https://github.com/apache/sling-org-apache-sling-api/pull/19
>  



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

[jira] [Updated] (SLING-9555) Define ResourceChange.ChangeType also as constant string values



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

Georg Henzler updated SLING-9555:
-
Fix Version/s: (was: API 2.22.2)
   API 2.23.0

> Define ResourceChange.ChangeType also as constant string values
> ---
>
> Key: SLING-9555
> URL: https://issues.apache.org/jira/browse/SLING-9555
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: API 2.23.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> As all annotation values have to be provided as constants (e.g. in 
> https://docs.osgi.org/javadoc/r6/residential/org/osgi/service/component/annotations/Component.html#property())
>  and conversion from {{Enum}} to {{String}} cannot be resolved at compile 
> time all enum values of {{ResourceChange.ChangeType}} should also be provided 
> as String constants.
> Something like this does not work
> {code}
> @Component(property = { 
> ResourceChangeListener.CHANGES+"="+ResourceChange.ChangeType.REMOVED.toString()}
> )
> {code}
> Compare with https://stackoverflow.com/a/13253879.



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

[jira] [Updated] (SLING-8984) SyntheticResource and ResourceWrapper: Add missing @NotNull annotations



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

Georg Henzler updated SLING-8984:
-
Fix Version/s: (was: API 2.22.2)
   API 2.23.0

> SyntheticResource and ResourceWrapper: Add missing @NotNull annotations
> ---
>
> Key: SLING-8984
> URL: https://issues.apache.org/jira/browse/SLING-8984
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Minor
> Fix For: API 2.23.0
>
>
> alle methods of SyntheticResource and ResourceWrapper should have the 
> approritate @NotNull anotations for mandatory parameters.



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

[jira] [Updated] (SLING-9312) LazyBindings.entrySet: hashCode of binding values is calculated



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

Georg Henzler updated SLING-9312:
-
Fix Version/s: (was: API 2.22.2)
   API 2.23.0

> LazyBindings.entrySet: hashCode of binding values is calculated
> ---
>
> Key: SLING-9312
> URL: https://issues.apache.org/jira/browse/SLING-9312
> Project: Sling
>  Issue Type: Bug
>  Components: API
>Affects Versions: API 2.21.0
>Reporter: Hans-Peter Stoerr
>Assignee: Radu Cotescu
>Priority: Minor
> Fix For: API 2.23.0
>
>
> The method entrySet in org.apache.sling.api.scripting.LazyBindings currently 
> has a bug that forces the hashCode of the entry values in Bindings are 
> calculated in each HTL request, when it should only be the hashCode of the 
> keys - if at all. This can be a performance problem if the value is e.g. a 
> large map, in our (complicated) case this even got us a StackOverflowError.
> The problematic code is:
> {code:java}
> public Set> entrySet() {
> HashSet> entrySet = new 
> HashSet<>(super.entrySet());
> for (Map.Entry supplierEntry : suppliers.entrySet()) {
> entrySet.add(supplierEntry);
> }
> return Collections.unmodifiableSet(entrySet);
> } {code}
> Since the entries are put together in a HashSet, each add will calculate the 
> hashCode of the entry - which sums the hashCode of the key *and the value* of 
> each binding entry. I suggest to replace this with a HashMap and return it's 
> entrySet. Another problem is that this could return several entries for the 
> same key, which is probably not intended.
> In case you are wondering, this is called in every HTL request like this:
> {code:java}
>  at java.base/java.util.HashSet.add(HashSet.java:220)
>   at 
> java.base/java.util.AbstractCollection.addAll(AbstractCollection.java:336)
>   at java.base/java.util.HashSet.(HashSet.java:120)
>   at 
> org.apache.sling.api.scripting.LazyBindings.entrySet(LazyBindings.java:117) 
> [org.apache.sling.api:2.21.0]
>   at 
> org.apache.sling.api.scripting.LazyBindings.putAll(LazyBindings.java:87) 
> [org.apache.sling.api:2.21.0]
>   at 
> org.apache.sling.scripting.sightly.impl.engine.SightlyCompiledScript.eval(SightlyCompiledScript.java:50)
>  [org.apache.sling.scripting.sightly:1.2.0.0]
>   at 
> org.apache.sling.scripting.core.impl.DefaultSlingScript.call(DefaultSlingScript.java:386)
>  [org.apache.sling.scripting.core:2.1.0]
>   at 
> org.apache.sling.scripting.core.impl.DefaultSlingScript.eval(DefaultSlingScript.java:184)
>  [org.apache.sling.scripting.core:2.1.0]
>   at 
> org.apache.sling.scripting.core.impl.DefaultSlingScript.service(DefaultSlingScript.java:491)
>  [org.apache.sling.scripting.core:2.1.0]
>   at 
> org.apache.sling.engine.impl.request.RequestData.service(RequestData.java:552)
>  [org.apache.sling.engine:2.6.20]
>   at 
> org.apache.sling.engine.impl.filter.SlingComponentFilterChain.render(SlingComponentFilterChain.java:44)
>  [org.apache.sling.engine:2.6.20] {code}
>  
>  



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

[jira] [Resolved] (SLING-9745) Introduce SlingUri API to simplify creation/manipulation of Sling URIs



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

Georg Henzler resolved SLING-9745.
--
Fix Version/s: API 2.23.0
   Resolution: Fixed

> Introduce SlingUri API to simplify creation/manipulation of Sling URIs
> --
>
> Key: SLING-9745
> URL: https://issues.apache.org/jira/browse/SLING-9745
> Project: Sling
>  Issue Type: New Feature
>  Components: API
>    Reporter: Georg Henzler
>    Assignee: Georg Henzler
>Priority: Major
> Fix For: API 2.23.0
>
>  Time Spent: 8h 50m
>  Remaining Estimate: 0h
>
> General purpose class to represent a SlingUri (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.



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

Re: [VOTE] Release Apache Sling JCR Base 3.1.6

2020-09-22 Thread Georg Henzler


+1

-Georg

On 2020-09-22 17:08, Robert Munteanu wrote:

Hi,

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

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

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 2336 /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] [Commented] (SLING-9662) Introduce an URI Mapping SPI



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

Georg Henzler commented on SLING-9662:
--

See 
[https://github.com/apache/sling-org-apache-sling-api/compare/feature/SLING-9662-Introduce-SlingUri-Mapping-SPI-v3]
 for the current draft version:
 * API: 
[PathToUriMappingService|https://github.com/apache/sling-org-apache-sling-api/blob/364ffe3ef4ced4267f112c8639e8ce5ab81e8b46/src/main/java/org/apache/sling/api/resource/mapping/PathToUriMappingService.java]
 (can be used instead of rr.map() and rr.resolve(), the idea is to change the 
implementation of those rr methods to use this service (and to gradually move 
the mapping functionality to the impl of this service)
 * SPI: 
[SlingUriMapper|https://github.com/apache/sling-org-apache-sling-api/blob/364ffe3ef4ced4267f112c8639e8ce5ab81e8b46/src/main/java/org/apache/sling/spi/urimapping/SlingUriMapper.java]
 (moved to SPI package). The context 
[MappingChainContext|https://github.com/apache/sling-org-apache-sling-api/blob/364ffe3ef4ced4267f112c8639e8ce5ab81e8b46/src/main/java/org/apache/sling/spi/urimapping/MappingChainContext.java]
 does provide a read-only resource resolver (but not the rr of the request to 
allow to move resolve() before authentication to fix the problems we have today 
as mentioned by [~cziegeler] above)

> Introduce an URI 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
>
> _an earlier version used the terms ResourceUri/ResourceToUriMapper (updated 
> this description during the discussion)_ 
> Introduce a simple SPI that allows to contribute to the resource resolver's 
> map() and resolve() methods:
> Prerequisite *SlingUri:* (SLING-9745 to be completed first)
> 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.
> *SlingUriMapper:*
> 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 SlingUriMapper chain member may or may not 
> make adjustments to the resource link.
>  rr.resolve() passes through the chain starting at the SlingUriMapper with 
> the highest service ranking and rr.map() passes through the 
> chain starting at the SlingUriMapper 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] [Updated] (SLING-9662) Introduce an URI Mapping SPI



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

Georg Henzler updated SLING-9662:
-
Summary: Introduce an URI Mapping SPI  (was: Introduce a Resource Mapping 
SPI)

> Introduce an URI 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
>
> _an earlier version used the terms ResourceUri/ResourceToUriMapper (updated 
> this description during the discussion)_ 
> Introduce a simple SPI that allows to contribute to the resource resolver's 
> map() and resolve() methods:
> Prerequisite *SlingUri:* (SLING-9745 to be completed first)
> 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.
> *SlingUriMapper:*
> 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 SlingUriMapper chain member may or may not 
> make adjustments to the resource link.
>  rr.resolve() passes through the chain starting at the SlingUriMapper with 
> the highest service ranking and rr.map() passes through the 
> chain starting at the SlingUriMapper 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] [Updated] (SLING-9662) Introduce a Resource Mapping SPI



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

Georg Henzler updated SLING-9662:
-
Description: 
_an earlier version used the terms ResourceUri/ResourceToUriMapper (updated 
this description during the discussion)_ 

Introduce a simple SPI that allows to contribute to the resource resolver's 
map() and resolve() methods:

Prerequisite *SlingUri:* (SLING-9745 to be completed first)

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.

*SlingUriMapper:*

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 SlingUriMapper chain member may or may not make 
adjustments to the resource link.
 rr.resolve() passes through the chain starting at the SlingUriMapper with the 
highest service ranking and rr.map() passes through the chain 
starting at the SlingUriMapper 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]

  was:
SlingUriMapper

 

Introduce a simple SPI that allows to contribute to the resource resolver's 
map() and resolve() methods:

Prerequisite *SlingUri:* (SLING-9745 to be completed first)

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.

*SlingUriMapper:*

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 SlingUriMapper chain member may or may not make 
adjustments to the resource link.
 rr.resolve() passes through the chain starting at the SlingUriMapper with the 
highest service ranking and rr.map() passes through the chain 
starting at the SlingUriMapper 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]


> 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
>
> _an earlier version used the terms ResourceUri/ResourceToUriMapper (updated 
> this description during the discussion)_ 
> Introduce a simple SPI that allows to contribute to the resource resolver's 
> map() and resolve() methods:
> Prerequisite *SlingUri:* (SLING-9745 to be completed first)
> 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.
> *SlingUriMapper:*
> 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 SlingUriMapper chain member may or may not 
> make adjustments to the resource link.
>  rr.resolve() passes through the chain starting at the SlingUriMapper with 
> the highest service ranking and rr.map() passes through the 
> chain starting at the SlingUriMapper 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] [Updated] (SLING-9662) Introduce a Resource Mapping SPI



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

Georg Henzler updated SLING-9662:
-
Description: 
SlingUriMapper

 

Introduce a simple SPI that allows to contribute to the resource resolver's 
map() and resolve() methods:

Prerequisite *SlingUri:* (SLING-9745 to be completed first)

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.

*SlingUriMapper:*

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 SlingUriMapper chain member may or may not make 
adjustments to the resource link.
 rr.resolve() passes through the chain starting at the SlingUriMapper with the 
highest service ranking and rr.map() passes through the chain 
starting at the SlingUriMapper 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]

  was:
Introduce a simple SPI that allows to contribute to the resource resolver's 
map() and resolve() methods:

Prerequisite *ResourceUri:* (SLING-9745 to be completed first)

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]


> 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
>
> SlingUriMapper
>  
> Introduce a simple SPI that allows to contribute to the resource resolver's 
> map() and resolve() methods:
> Prerequisite *SlingUri:* (SLING-9745 to be completed first)
> 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.
> *SlingUriMapper:*
> 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 SlingUriMapper chain member may or may not 
> make adjustments to the resource link.
>  rr.resolve() passes through the chain starting at the SlingUriMapper with 
> the highest service ranking and rr.map() passes through the 
> chain starting at the SlingUriMapper 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] [Updated] (SLING-9745) Introduce SlingUri API to simplify creation/manipulation of Sling URIs



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

Georg Henzler updated SLING-9745:
-
Description: General purpose class to represent a SlingUri (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.  (was: 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.)

> Introduce SlingUri API to simplify creation/manipulation of Sling URIs
> --
>
> Key: SLING-9745
> URL: https://issues.apache.org/jira/browse/SLING-9745
> Project: Sling
>  Issue Type: New Feature
>  Components: API
>    Reporter: Georg Henzler
>    Assignee: Georg Henzler
>Priority: Major
>  Time Spent: 5h 10m
>  Remaining Estimate: 0h
>
> General purpose class to represent a SlingUri (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.



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

[jira] [Updated] (SLING-9745) Introduce SlingUri API to simplify creation/manipulation of Sling URIs



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

Georg Henzler updated SLING-9745:
-
Summary: Introduce SlingUri API to simplify creation/manipulation of Sling 
URIs  (was: Introduce ResourceUri API to simplify creation/manipulation of 
Sling URIs)

> Introduce SlingUri API to simplify creation/manipulation of Sling URIs
> --
>
> Key: SLING-9745
> URL: https://issues.apache.org/jira/browse/SLING-9745
> Project: Sling
>  Issue Type: New Feature
>  Components: API
>    Reporter: Georg Henzler
>    Assignee: Georg Henzler
>Priority: Major
>  Time Spent: 5h 10m
>  Remaining Estimate: 0h
>
> 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.



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

Re: [DISCUSS] Resource Mapping SPI

2020-09-20 Thread Georg Henzler


Considering that URIs like 'mailto:j...@example.com', '?name=val'
or '#fragment' do not relate to a resource and thinking about it
a bit more, I would now propose to change the name of
ResourceUri/ResourceUriBuilder to SlingUri/SlingUriBuilder
(see also [1]) - objections?

-Georg

[1] 
https://github.com/apache/sling-org-apache-sling-api/pull/23#discussion_r491726353


On 2020-09-18 11:14, Georg Henzler wrote:

Hi all,

to not have too many changes in one issue and PR to review,
I created SLING-9745 and PR [1] for the ResourceUri and
its builder. The unit test coverage is good (~85%) and also
covers the tests from SlingRequestPathInfoTest [2] to
ensure compatibility. Timely feedback would be appreciated
as I would like to build upon this on Mon (with the next PR).

-Georg

[1]
https://github.com/apache/sling-org-apache-sling-api/pull/23
[2]
https://github.com/apache/sling-org-apache-sling-engine/blob/43673bddb4a2e79ef9bba813ec86a7faa89e7649/src/test/java/org/apache/sling/engine/impl/request/SlingRequestPathInfoTest.java#L28

Re: [DISCUSS] Resource Mapping SPI

2020-09-18 Thread Georg Henzler


Hi all,

to not have too many changes in one issue and PR to review,
I created SLING-9745 and PR [1] for the ResourceUri and
its builder. The unit test coverage is good (~85%) and also
covers the tests from SlingRequestPathInfoTest [2] to
ensure compatibility. Timely feedback would be appreciated
as I would like to build upon this on Mon (with the next PR).

-Georg

[1]
https://github.com/apache/sling-org-apache-sling-api/pull/23
[2] 
https://github.com/apache/sling-org-apache-sling-engine/blob/43673bddb4a2e79ef9bba813ec86a7faa89e7649/src/test/java/org/apache/sling/engine/impl/request/SlingRequestPathInfoTest.java#L28


On 2020-09-11 00:45, Georg Henzler wrote:

Hi Carsten,

so I followed the proposal and moved the resource mapping
SPI "resolve hook-in point" before authentication (in
sling engine) - see [1]. This will mean that once the
path mappings are migrated to the SPI, the authentication
requirements can be evaluated after the mapping.

The Sling API part is quite mature, ResourceUri has quite
intensive test coverage now [2]. ResourceUriMapper [3] is
the SPI interface (not called ResourceToUriMapper anymore
because the SPI interface is actually taking ResourceUri
as both input and output). The service calls all
ResourceUriMappers is now called PathToUriMappingService [4]
(was called ResourceUriMappingChain, now closer to your
proposal PathRewriter). This service is part of the API
now to allow to use is from the sling engine bundle.

The parts in resourceresolver and sling engine work well
with the sling starter (Slingshot, Composum) but will need
a bit of more testing...

-Georg

[1]
https://github.com/apache/sling-org-apache-sling-api/commits/feature/SLING-9662-Introduce-Resource-Mapping-SPI-v2
https://github.com/apache/sling-org-apache-sling-api/commit/c27db47a07ce7d85896e1c761f462653a7532e79

https://github.com/apache/sling-org-apache-sling-resourceresolver/commits/feature/SLING-9662-Introduce-Resource-Mapping-SPI-v2
https://github.com/apache/sling-org-apache-sling-resourceresolver/commit/de835ae65bc4e8b5b6955ee5e679706e0e0a2adf

https://github.com/apache/sling-org-apache-sling-engine/commits/feature/SLING-9662-Introduce-Resource-Mapping-SPI-v2
https://github.com/apache/sling-org-apache-sling-engine/commit/203f9a85a101749c070ea8c3d76ef194c8056b73

[2]
https://github.com/apache/sling-org-apache-sling-api/blob/feature/SLING-9662-Introduce-Resource-Mapping-SPI-v2/src/test/java/org/apache/sling/api/resource/uri/ResourceUriTest.java

[3]
https://github.com/apache/sling-org-apache-sling-api/blob/feature/SLING-9662-Introduce-Resource-Mapping-SPI-v2/src/main/java/org/apache/sling/spi/resource/mapping/ResourceUriMapper.java

[4]
https://github.com/apache/sling-org-apache-sling-api/blob/feature/SLING-9662-Introduce-Resource-Mapping-SPI-v2/src/main/java/org/apache/sling/api/resource/mapping/PathToUriMappingService.java


On 2020-09-04 07:09, Carsten Ziegeler wrote:

Hi Georg,



One question though:


PathRewriterFactory

So this class is currently called ResourceUriMappingChain and it is
*not* a factory - it is a regular OSG service that does not hold
any state as member variables - did you have a particular reason in
mind why it should be a factory or was this just following the
pattern from the ResourceResolver?
I wanted to have a factory that allows to create a PathRewriter which

contains a servlet request - this way such a PathRewriter can be
created for every incoming request as a first step and then simply be
passed - in my case to the ResourceResolverFactory and then the
ResourceResolver.
This way if you use the PathRewriter from the ResourceResolver it
already has the right context (request).

I thought it might be useful to manage some state (request in this
case) on the PathRewriter.

Regards
Carsten

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

[jira] [Commented] (SLING-9745) Introduce ResourceUri API to simplify creation/manipulation of Sling URIs

2020-09-18 Thread Georg Henzler (Jira)



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

Georg Henzler commented on SLING-9745:
--

PR: https://github.com/apache/sling-org-apache-sling-api/pull/23/

> Introduce ResourceUri API to simplify creation/manipulation of Sling URIs
> -
>
> Key: SLING-9745
> URL: https://issues.apache.org/jira/browse/SLING-9745
> Project: Sling
>  Issue Type: New Feature
>  Components: API
>    Reporter: Georg Henzler
>    Assignee: Georg Henzler
>Priority: Major
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> 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.



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

[jira] [Commented] (SLING-9660) Add RequestPathInfoBuilder for easily constructing Sling URLs

2020-09-18 Thread Georg Henzler (Jira)



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

Georg Henzler commented on SLING-9660:
--

SLING-9662 was a bit too big in what it contained, therefore ResourceURI and 
builder for it is done via separate issue SLING-9745 now

> Add RequestPathInfoBuilder for easily constructing Sling URLs
> -
>
> Key: SLING-9660
> URL: https://issues.apache.org/jira/browse/SLING-9660
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently Sling URLs with their parts outlined in 
> https://sling.apache.org/documentation/the-sling-engine/url-decomposition.html
>  must be constructed manually (i.e. by String operations). 
> To ease constructing such URLs a {{RequestPathInfoBuilder}} should be 
> provided which allows to create a URL out of the individual parts easily.
> Such a Builder should be either constructed from an existing URL or 
> RequestPathInfo and should allow to modify/extend each of the given parts.
> The Builder should work similarly to 
> https://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/client/utils/URIBuilder.html.



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

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

2020-09-17 Thread Georg Henzler (Jira)



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

Georg Henzler updated SLING-9662:
-
Description: 
Introduce a simple SPI that allows to contribute to the resource resolver's 
map() and resolve() methods:

Prerequisite *ResourceUri:* (SLING-9745 to be completed first)

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]

  was:
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]


> 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:
> Prerequisite *ResourceUri:* (SLING-9745 to be completed first)
> 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] [Created] (SLING-9745) Introduce ResourceUri API to simplify creation/manipulation of Sling URIs

2020-09-17 Thread Georg Henzler (Jira)

Georg Henzler created SLING-9745:


 Summary: Introduce ResourceUri API to simplify 
creation/manipulation of Sling URIs
 Key: SLING-9745
 URL: https://issues.apache.org/jira/browse/SLING-9745
 Project: Sling
  Issue Type: New Feature
  Components: API
Reporter: Georg Henzler
Assignee: Georg Henzler


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.



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

Re: [VOTE] Release Apache Sling Commons Scheduler 2.7.12

2020-09-15 Thread Georg Henzler


+1

-Georg


On 2020-09-14 19:02, Karl Pauls wrote:

We solved 3 issues in this release:
https://issues.apache.org/jira/projects/SLING/versions/12348801

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

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 2335 /tmp/sling-staging

Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

Re: [VOTE] Release Apache Sling OSGi Feature Maven Plugin 1.3.16, Apache Sling Feature Model 1.2.8, Apache Sling Feature Model Launcher 1.1.6

2020-09-11 Thread Georg Henzler


+1

-Georg

On 2020-09-09 15:54, Robert Munteanu wrote:

Hi,

We solved 2 issues in these releases:
https://issues.apache.org/jira/browse/SLING/fixforversion/12348775
https://issues.apache.org/jira/browse/SLING/fixforversion/12348707
https://issues.apache.org/jira/browse/SLING/fixforversion/12348405

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

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

Re: [DISCUSS] Automatic Mapping of URIs in HTL

2020-09-11 Thread Georg Henzler


Hi Paul


The reason I think both the global config and the local config are
necessary


good point, +1 (both "global on/disable for one uri locally" and
"global off/enable for one uri locally" are valid use cases)


.. JSON or some JS objects in HTL scripts (thinking on how many
times I had to go back and change a Sling Model to add URI mapping, 
because
a specific Sling-based product that uses a servlet filter does 
not/cannot

map values in JS/JSON).


IIRC for this product only html paths are mapped (and js/json paths need 
to be
mapped manually). The idea of this proposal is to map _any_ uri or 
_none_

depending on the global config (and allow to override per uri via param)


-Georg

Re: [VOTE] Release Apache Sling Content-Package to Feature Model Converter 1.0.14

2020-09-11 Thread Georg Henzler


+1

-Georg

On 2020-09-11 16:31, Carsten Ziegeler wrote:

+1

Carsten

Am 11.09.2020 um 12:25 schrieb Robert Munteanu:

Hi,

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

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

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

Re: [DISCUSS] Automatic Mapping of URIs in HTL

2020-09-11 Thread Georg Henzler


Hi Radu,



1. Per URI as mentioned in template:
 


This could work - it would be a Sling-specific option and we’ve done
this in the past in https://issues.apache.org/jira/browse/SLING-5812
. The option would
introduce a new runtime call to the new SPIs.


I quickly tested this with minor changes to 
URIManipulationFilterExtension

and URIManipulationFilter and it worked fine - but as said it's
tedious and error prone to go this route, it should rather be a cross
cutting concern


3. Per global OSGi configuration


How would we handle 3?


So one simple naive way would be to hook into [1], check for the
"uri" context and call the map API method on the value. The probably
clean way (I don't know this code very well) is to create a dedicated
filter that gets to see all properties similar to the XSSFilter (and
adjusts uri values only).

I also think conceptually it also fits in well with the "automatic
context sensitivity" in the spec [2] (just another aspect compared to
XSS). While the template/spec does not change, the implementation
takes care of the handling and configuration, this is true for XSS
today and would also hold true for mapping of URIs.

-Georg


[1] 
https://github.com/apache/sling-org-apache-sling-scripting-sightly-compiler/blob/eb8891e89caef2993f4cdab0fbe764a7695ec0e8/src/main/java/org/apache/sling/scripting/sightly/impl/filter/XSSFilter.java#L51


[2] 
https://github.com/adobe/htl-spec/blob/1.2/SPECIFICATION.md#113-context-sensitive

Re: [DISCUSS] Automatic Mapping of URIs in HTL

2020-09-11 Thread Georg Henzler

Hi Nicolas,

yes that makes sense, although maybe a bit overkill for
one boolean flag it's conceptually cleaner than OSGi config
with regex (no 3). Overall the question will be if this
needs to be controlled per content root path or rather per
(super)resourceType... Output Rewriting Pipelines allow for
both variants [1] but not sure if we need both here as well...

-Georg

[1]
https://sling.apache.org/documentation/bundles/output-rewriting-pipelines-org-apache-sling-rewriter.html#configuring-a-processor

On 2020-09-11 10:02, Nicolas Peltier wrote:

i like the idea! what about a context aware configuration?

Le ven. 11 sept. 2020 à 01:09, Georg Henzler a
écrit :

Hi all,

as briefly mentioned in the thread about the resource
mapping SPI [1], it would be really useful if HTL
could auto-map URIs (regardless of the SPI)
- that way many projects that use the rewriting
pipeline [2] today for that purpose could simplify
their setup (and make it more performant). Now the
question is how to do this best, the following
options come to my mind:

1. Per URI as mentioned in template:

2. Turned on/off with a wrapper element

...

3. Per global OSGi configuration

Now 1. is not very convenient (and would produce a
lot of noise in the template), 2. is probably the
most flexible and should make it fairly easy to run
the rewriting pipeline side by side with the new
approach at certain content paths, 3. is the easiest
to implement but it should at least allow to configure
a regex of content paths where auto-mapping applies
(to ensure the approaches can run side by side)

Are there other (better) ideas? Or more generally,
are there any concerns to move into this direction?

-Georg

[1] https://www.mail-archive.com/dev@sling.apache.org/msg97820.html
[2]

https://sling.apache.org/documentation/bundles/output-rewriting-pipelines-org-apache-sling-rewriter.html

[DISCUSS] Automatic Mapping of URIs in HTL

2020-09-10 Thread Georg Henzler


Hi all,

as briefly mentioned in the thread about the resource
mapping SPI [1], it would be really useful if HTL
could auto-map URIs (regardless of the SPI)
- that way many projects that use the rewriting
pipeline [2] today for that purpose could simplify
their setup (and make it more performant). Now the
question is how to do this best, the following
options come to my mind:

1. Per URI as mentioned in template:

  

2. Turned on/off with a wrapper element

  


...
  

3. Per global OSGi configuration

Now 1. is not very convenient (and would produce a
lot of noise in the template), 2. is probably the
most flexible and should make it fairly easy to run
the rewriting pipeline side by side with the new
approach at certain content paths, 3. is the easiest
to implement but it should at least allow to configure
a regex of content paths where auto-mapping applies
(to ensure the approaches can run side by side)

Are there other (better) ideas? Or more generally,
are there any concerns to move into this direction?

-Georg

[1] https://www.mail-archive.com/dev@sling.apache.org/msg97820.html
[2] 
https://sling.apache.org/documentation/bundles/output-rewriting-pipelines-org-apache-sling-rewriter.html

Re: [VOTE] Release Apache Sling Testing Sling Mock 2.6.2

2020-09-10 Thread Georg Henzler


+1 (checked signatures)

-Georg

On 2020-09-10 22:52, Stefan Seifert wrote:

Hi,

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

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

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

stefan

Re: [DISCUSS] Resource Mapping SPI

2020-09-10 Thread Georg Henzler


Hi Carsten,

so I followed the proposal and moved the resource mapping
SPI "resolve hook-in point" before authentication (in
sling engine) - see [1]. This will mean that once the
path mappings are migrated to the SPI, the authentication
requirements can be evaluated after the mapping.

The Sling API part is quite mature, ResourceUri has quite
intensive test coverage now [2]. ResourceUriMapper [3] is
the SPI interface (not called ResourceToUriMapper anymore
because the SPI interface is actually taking ResourceUri
as both input and output). The service calls all
ResourceUriMappers is now called PathToUriMappingService [4]
(was called ResourceUriMappingChain, now closer to your
proposal PathRewriter). This service is part of the API
now to allow to use is from the sling engine bundle.

The parts in resourceresolver and sling engine work well
with the sling starter (Slingshot, Composum) but will need
a bit of more testing...

-Georg

[1]
https://github.com/apache/sling-org-apache-sling-api/commits/feature/SLING-9662-Introduce-Resource-Mapping-SPI-v2
https://github.com/apache/sling-org-apache-sling-api/commit/c27db47a07ce7d85896e1c761f462653a7532e79

https://github.com/apache/sling-org-apache-sling-resourceresolver/commits/feature/SLING-9662-Introduce-Resource-Mapping-SPI-v2
https://github.com/apache/sling-org-apache-sling-resourceresolver/commit/de835ae65bc4e8b5b6955ee5e679706e0e0a2adf

https://github.com/apache/sling-org-apache-sling-engine/commits/feature/SLING-9662-Introduce-Resource-Mapping-SPI-v2
https://github.com/apache/sling-org-apache-sling-engine/commit/203f9a85a101749c070ea8c3d76ef194c8056b73

[2]
https://github.com/apache/sling-org-apache-sling-api/blob/feature/SLING-9662-Introduce-Resource-Mapping-SPI-v2/src/test/java/org/apache/sling/api/resource/uri/ResourceUriTest.java

[3]
https://github.com/apache/sling-org-apache-sling-api/blob/feature/SLING-9662-Introduce-Resource-Mapping-SPI-v2/src/main/java/org/apache/sling/spi/resource/mapping/ResourceUriMapper.java

[4]
https://github.com/apache/sling-org-apache-sling-api/blob/feature/SLING-9662-Introduce-Resource-Mapping-SPI-v2/src/main/java/org/apache/sling/api/resource/mapping/PathToUriMappingService.java


On 2020-09-04 07:09, Carsten Ziegeler wrote:

Hi Georg,



One question though:


PathRewriterFactory

So this class is currently called ResourceUriMappingChain and it is
*not* a factory - it is a regular OSG service that does not hold
any state as member variables - did you have a particular reason in
mind why it should be a factory or was this just following the
pattern from the ResourceResolver?
I wanted to have a factory that allows to create a PathRewriter which

contains a servlet request - this way such a PathRewriter can be
created for every incoming request as a first step and then simply be
passed - in my case to the ResourceResolverFactory and then the
ResourceResolver.
This way if you use the PathRewriter from the ResourceResolver it
already has the right context (request).

I thought it might be useful to manage some state (request in this
case) on the PathRewriter.

Regards
Carsten

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

Re: [VOTE] Release Apache Sling Feature Model Analyser 1.3.8

2020-09-03 Thread Georg Henzler


+1

Georg

On 2020-09-03 13:17, Carsten Ziegeler wrote:

+1

Carsten

Am 03.09.2020 um 12:10 schrieb Robert Munteanu:

Hi,

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

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

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

Re: [DISCUSS] Resource Mapping SPI

2020-09-03 Thread Georg Henzler


Hi Carsten,

so this is very similar to what I have on [1] already. I was busy
with other things this week but I'll start now to fix the conflicts
from the merges of SLING-9620 and SLING-9623. Also I'll move the SPI
package underneath org.apache.sling.spi and I'll try to incorporate
your ideas from branch pathmappingproposal.

One question though:


PathRewriterFactory

So this class is currently called ResourceUriMappingChain and it is
*not* a factory - it is a regular OSG service that does not hold
any state as member variables - did you have a particular reason in
mind why it should be a factory or was this just following the
pattern from the ResourceResolver?

-Georg

[1] 
https://github.com/apache/sling-org-apache-sling-api/blob/feature/Resource_Mapping_SPI/src/main/java/org/apache/sling/api/resource/mapping/spi/ResourceMapping.java



On 2020-09-02 14:19, Carsten Ziegeler wrote:

Hi,

in order to make it simpler to understand my proposal, I created an
api prototype [1]. It's really just to demonstrate - nothing else. For
class / method names, I just picked the first that came to my mind.

PathMapper is the SPI
(https://github.com/apache/sling-org-apache-sling-api/blob/feature/pathmappingproposal/src/main/java/org/apache/sling/spi/resource/mapping/PathMapper.java)
- I just a simpler String based interface - again just for
demonstration; it doesn't mean that the current proposed Resource
Mapping SPI is bad; but I want to focus on the overall design first.
The services implementing the SPI are called in a chain, the
difference to the current proposal is that they do not have access to
a ResourceResolver via the context/parameters

PathRewriterFactory
(https://github.com/apache/sling-org-apache-sling-api/blob/feature/pathmappingproposal/src/main/java/org/apache/sling/api/resource/mapping/PathRewriterFactory.java)
creates PathRewriter objects - either with or without a servlet
request.

The PathRewriter invokes the chain from above for mapping and reverse 
mapping.


ResourceResolver gets two new methods
(https://github.com/apache/sling-org-apache-sling-api/blob/feature/pathmappingproposal/src/main/java/org/apache/sling/api/resource/ResourceResolver.java#L198-205)
- one to just invoke the resolving part and one to get the associated
PathRewriter (which can be passed in via the RRF).

The map/resolve methods get deprecated, they will internally call the
PathRewriter.


Regards
Carsten



[1]
https://github.com/apache/sling-org-apache-sling-api/tree/feature/pathmappingproposal

Am 26.08.2020 um 10:10 schrieb Carsten Ziegeler:

Hi Georg,

Am 25.08.2020 um 18:53 schrieb Georg Henzler:



We should have an API that can be used for this, whether this is
rr.map() or something new is a different question. I have no problem
with having rr.map() doing this.


I'm in favour of not introducing a new API if it's not absolutely
needed. But calling out to another service from rr.map()/rr.resolve()
should work fine.

We need at least one new method for rr which replaces resolve() and 
only does resolving without mapping - as resolving would already be 
done pre authentication.




Ok fair enough - so your point was that the both map() and resolve()
do not (or should not) produce different results based on the user
context, my point was that to be future proof in the SPI, we need
"access to the repository" to address all use cases. So "that 
service"

in the current implementation would be ResourceUriMappingChain [1],
it currently has access to a rr via
MappingChainContext.getResourceResolver() [2] - I think a resolver
needs to be available to do lookups in the repository, but this
could also be one based on a service user (ready only rights on
the whole repo suffice).


Yes, ResourceUriMappingChain  would be such a service - but the 
methods would not have a RR as a argument but we would use a service 
user inside the implementation (which is then passed on using 
MappingChainContext).


Lets leave out the naming discussion for now, but my idea was to have 
a

ResourceUriMappingChainFactory as a service and that one creates new
ResourceUriMappingChain objects. An optional argument to the factory 
is the current request - so the request will be stored inside a 
ResourceUriMappingChain and there is no need to pass it to each and 
every call of a method of ResourceUriMappingChain.




So to start with it it could work fine to
hook in ResourceUriMappingChain.resolve() in the request processing
before the resource resolver is created.


Yes, something along those lines


Maybe then in the future
we could provide a service property to ResourceToUriMapping providers
that allows to be called with the request's user context after the
resource resolver is created (so moving the default mapping chain
before the authentication at least does not block the possibility
to allow user based resolutions for the future).


I think this is where it gets dangerous :) If we allow for user based 
mapping later on,

Re: [VOTE] Release Apache Sling Auth Core 1.5.0, Apache Sling Resource Resolver 1.7.0

2020-08-25 Thread Georg Henzler

+1

> On 25. Aug 2020, at 15:55, Radu Cotescu  wrote:
> 
> +1
> 
>> On 25 Aug 2020, at 11:09, Robert Munteanu  wrote:
>> 
>> Please vote to approve this release:
>> 
>> [ ] +1 Approve the release
>> [ ]  0 Don't care
>> [ ] -1 Don't release, because ...
>

Re: [DISCUSS] Resource Mapping SPI

2020-08-25 Thread Georg Henzler

Hi Carsten,

now, I totally agree that we should get rid of the rewriter pipeline.
With HTL we can do the rewriting links without reparsing the html
output.

perfect, for me that's one of the main goals of the new SPI. After
the hackathon last year there were some voices arguing pro rewriter
pipeline with valid use cases, but I think those are relevant for
only 5% of the projects (those can still use the pipeline, but
95% should be able to do without). Btw. the link checker use case
(that potentially removes tags) will bring a little bit
of complexity, but the plan is to allow "Resource URI context hints"
as result of a the mapping chain (and a hint "invalid uri" will make
HTL remove the surrounding tag)

We should have an API that can be used for this, whether this is
rr.map() or something new is a different question. I have no problem
with having rr.map() doing this.

I'm in favour of not introducing a new API if it's not absolutely
needed. But calling out to another service from rr.map()/rr.resolve()
should work fine.

Today mapping (and therefore reverse mapping) is not based on the
current user context - and I think we should keep it this way. Meaning
for any user mapping and reverse mapping creates the same result
regardless of the user. Following this logic, it doesn't make sense to
have this functionality in RR - as the RR is bound to a user. So I
suggest to make this a separate service which can be invoked without
having a RR. We can change the implementation of rr.map() to call that
service. rr.resolve can be changed to first call that service, too,
and then resolve the resulting path.

Ok fair enough - so your point was that the both map() and resolve()
do not (or should not) produce different results based on the user
context, my point was that to be future proof in the SPI, we need
"access to the repository" to address all use cases. So "that service"
in the current implementation would be ResourceUriMappingChain [1],
it currently has access to a rr via
MappingChainContext.getResourceResolver() [2] - I think a resolver
needs to be available to do lookups in the repository, but this
could also be one based on a service user (ready only rights on
the whole repo suffice). So to start with it it could work fine to
hook in ResourceUriMappingChain.resolve() in the request processing
before the resource resolver is created. Maybe then in the future
we could provide a service property to ResourceToUriMapping providers
that allows to be called with the request's user context after the
resource resolver is created (so moving the default mapping chain
before the authentication at least does not block the possibility
to allow user based resolutions for the future). Also the user
context could be generally be made available to rr.map(),
I suppose there it wouldn't hurt (and it would allow to add users
specific information to certain URLs, I think this can be quite
useful). But to start with, would it be ok for you to leave
MappingChainContext.getResourceResolver() [2] as is and provide
a service user rr for repository access to the resolve operation?

-Georg

[1]
https://github.com/apache/sling-org-apache-sling-resourceresolver/blob/feature/SLING-9662-Introduce-Resource-Mapping-SPI/src/main/java/org/apache/sling/resourceresolver/impl/mappingchain/ResourceUriMappingChain.java

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

Does that make sense?

Regards
Carsten

Am 24.08.2020 um 23:58 schrieb 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/resol

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.

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

IMHO both yes and no:

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
goo

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.

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

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

Re: Welcome Eric Norman as a Sling PMC member!

2020-08-19 Thread 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

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

2020-08-19 Thread 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] [Commented] (SLING-9662) Introduce a Resource Mapping SPI

2020-08-19 Thread 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)

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



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

Georg Henzler commented on SLING-9662:
--

[~rombert] So far there are only two "hook in points", so if there are 
conflicts they'll be easy to fix. Maybe the fixes for SLING-9620 and SLING-9623 
can already help improving the test coverage :) 

> 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] [Commented] (SLING-9662) Introduce a Resource Mapping SPI



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

Georg Henzler commented on SLING-9662:
--

[~bdelacretaz] I'm well aware of the cross cutting impact this change has (it's 
used everywhere!). To make it build I had to adjust a fair amount of JUnit 
tests already and I'd say the current state is 100% backwards compatible. But 
once I start refactoring (which is optional btw., we could also keep it 
side-by-side) the mentioned "status quo mechanisms" this has to be ensured also 
by integration test coverage. Would you add more integration tests to bundle 
org.apache.sling.resourceresolver (we have some "sort of integration tests" 
based on https://github.com/apache/sling-org-apache-sling-testing-osgi-mock) or 
extend tests in another place? 

> 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] [Comment Edited] (SLING-9660) Add RequestPathInfoBuilder for easily constructing Sling URLs



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

Georg Henzler edited comment on SLING-9660 at 8/14/20, 7:14 AM:


[~kwin] I think this is now already covered by SLING-9662, also constructing 
URLs works with it [~joerghoh], see 
https://github.com/apache/sling-org-apache-sling-api/tree/feature/SLING-9662-Introduce-Resource-Mapping-SPI/src/main/java/org/apache/sling/api/resource/uri
 and:

{code}
ResourceUriBuilder resourceUriBuilder = 
ResourceUriBuilder.forPath("/path/to/resouce.sel.html/suffix");
// this works because ResourceUri implements  RequestPathInfo
RequestPathInfo requestPathInfo = requestPathInfoBuilder.build();
{code}
 if you want to change this in a URL you can just use 
{code}
ResourceUriBuilder resourceUriBuilder = 
ResourceUriBuilder.forPath("/path/to/resouce.sel.html/suffix");
resourceUriBuilder.useSchemeAndAuthority(new URI("https://example.com:8443;))
ResourceUri resourceUri = requestPathInfoBuilder.build();
String resourceUriStr = resourceUri.toString();
URI resourceRealURI = resourceUri.toUri();
{code}
or you can create a full URI to start with
{code}
ResourceUriBuilder resourceUriBuilder = 
ResourceUriBuilder.parse("https://example.com/path/to/resouce.sel.html/suffix?test=1#frag;)
// and e.g. add a selector and change the suffix
.addSelector("sel2") // methods are chainable
.setSuffix("/anotherSuffix");
ResourceUri resourceUri = requestPathInfoBuilder.build();
// resourceUri.toString() will contain
// https://example.com/path/to/resouce.sel.sel2.html/anotherSuffix?test=1#frag
{code}



was (Author: henzlerg):
[~kwin] I think this is now already covered by SLING-9662, also constructing 
URLs works with it [~joerghoh], see 
https://github.com/apache/sling-org-apache-sling-api/tree/feature/SLING-9662-Introduce-Resource-Mapping-SPI/src/main/java/org/apache/sling/api/resource/uri
 and:

{code}
ResourceUriBuilder resourceUriBuilder = 
ResourceUriBuilder.forPath("/path/to/resouce.sel.html/suffix");
// this works because ResourceUri implements  RequestPathInfo
RequestPathInfo requestPathInfo = requestPathInfoBuilder.build();
{code}
 if you want to change this in a URL you can just use 
{code}
ResourceUriBuilder resourceUriBuilder = 
ResourceUriBuilder.forPath("/path/to/resouce.sel.html/suffix");
resourceUriBuilder.useSchemeAndAuthority(new URI("https://example.com:8443;))
ResourceUri resourceUri = requestPathInfoBuilder.build();
String resourceUriStr = resourceUri.toString();
URI resourceRealURI = resourceUri.toUri();
{code}
or you can create a full URI to start with
{code}
ResourceUriBuilder resourceUriBuilder = 
ResourceUriBuilder.parse("https://example.com/path/to/resouce.sel.html/suffix?test=1#frag;);
// and e.g. add a selector and change the suffix
resourceUriBuilder.addSelector("sel2")
resourceUriBuilder.setSuffix("/anotherSuffix")
ResourceUri resourceUri = requestPathInfoBuilder.build();
// resourceUri.toString() will contain
// https://example.com/path/to/resouce.sel.sel2.html/anotherSuffix?test=1#frag
{code}


> Add RequestPathInfoBuilder for easily constructing Sling URLs
> -
>
> Key: SLING-9660
> URL: https://issues.apache.org/jira/browse/SLING-9660
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: API 2.22.2
>
>
> Currently Sling URLs with their parts outlined in 
> https://sling.apache.org/documentation/the-sling-engine/url-decomposition.html
>  must be constructed manually (i.e. by String operations). 
> To ease constructing such URLs a {{RequestPathInfoBuilder}} should be 
> provided which allows to create a URL out of the individual parts easily.
> Such a Builder should be either constructed from an existing URL or 
> RequestPathInfo and should allow to modify/extend each of the given parts.
> The Builder should work similarly to 
> https://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/client/utils/URIBuilder.html.



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

[jira] [Comment Edited] (SLING-9660) Add RequestPathInfoBuilder for easily constructing Sling URLs



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

Georg Henzler edited comment on SLING-9660 at 8/14/20, 7:13 AM:


[~kwin] I think this is now already covered by SLING-9662, also constructing 
URLs works with it [~joerghoh], see 
https://github.com/apache/sling-org-apache-sling-api/tree/feature/SLING-9662-Introduce-Resource-Mapping-SPI/src/main/java/org/apache/sling/api/resource/uri
 and:

{code}
ResourceUriBuilder resourceUriBuilder = 
ResourceUriBuilder.forPath("/path/to/resouce.sel.html/suffix");
// this works because ResourceUri implements  RequestPathInfo
RequestPathInfo requestPathInfo = requestPathInfoBuilder.build();
{code}
 if you want to change this in a URL you can just use 
{code}
ResourceUriBuilder resourceUriBuilder = 
ResourceUriBuilder.forPath("/path/to/resouce.sel.html/suffix");
resourceUriBuilder.useSchemeAndAuthority(new URI("https://example.com:8443;))
ResourceUri resourceUri = requestPathInfoBuilder.build();
String resourceUriStr = resourceUri.toString();
URI resourceRealURI = resourceUri.toUri();
{code}
or you can create a full URI to start with
{code}
ResourceUriBuilder resourceUriBuilder = 
ResourceUriBuilder.parse("https://example.com/path/to/resouce.sel.html/suffix?test=1#frag;);
// and e.g. add a selector and change the suffix
resourceUriBuilder.addSelector("sel2")
resourceUriBuilder.setSuffix("/anotherSuffix")
ResourceUri resourceUri = requestPathInfoBuilder.build();
// resourceUri.toString() will contain
// https://example.com/path/to/resouce.sel.sel2.html/anotherSuffix?test=1#frag
{code}



was (Author: henzlerg):
[~kwin] I think this is now already covered by SLING-9662, also constructing 
URLs works with it [~joerghoh], see 
https://github.com/apache/sling-org-apache-sling-api/tree/feature/SLING-9662-Introduce-Resource-Mapping-SPI/src/main/java/org/apache/sling/api/resource/uri
 and:

{code}
ResourceUriBuilder resourceUriBuilder = 
ResourceUriBuilder.forPath("/path/to/resouce.sel.html/suffix");
// this works because ResourceUri implements  RequestPathInfo
RequestPathInfo requestPathInfo = requestPathInfoBuilder.build();
{code}
 if you want to change this in a URL you can just use 
{code}
ResourceUriBuilder resourceUriBuilder = 
ResourceUriBuilder.forPath("/path/to/resouce.sel.html/suffix");
resourceUriBuilder.useSchemeAndAuthority(new URI("https://example.com:8443;))
ResourceUri resourceUri = requestPathInfoBuilder.build();
String resourceUriStr = resourceUri.toString();
URI resourceRealURI = resourceUri.toUri();
{code}
or you can create a full URI to start with
{code}
ResourceUriBuilder resourceUriBuilder = 
ResourceUriBuilder.forPath("https://example.com/path/to/resouce.sel.html/suffix?test=1#frag;);
// and e.g. add a selector and change the suffix
resourceUriBuilder.addSelector("sel2")
resourceUriBuilder.setSuffix("/anotherSuffix")
ResourceUri resourceUri = requestPathInfoBuilder.build();
// resourceUri.toString() will contain
// https://example.com/path/to/resouce.sel.sel2.html/anotherSuffix?test=1#frag
{code}


> Add RequestPathInfoBuilder for easily constructing Sling URLs
> -
>
> Key: SLING-9660
> URL: https://issues.apache.org/jira/browse/SLING-9660
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: API 2.22.2
>
>
> Currently Sling URLs with their parts outlined in 
> https://sling.apache.org/documentation/the-sling-engine/url-decomposition.html
>  must be constructed manually (i.e. by String operations). 
> To ease constructing such URLs a {{RequestPathInfoBuilder}} should be 
> provided which allows to create a URL out of the individual parts easily.
> Such a Builder should be either constructed from an existing URL or 
> RequestPathInfo and should allow to modify/extend each of the given parts.
> The Builder should work similarly to 
> https://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/client/utils/URIBuilder.html.



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

[jira] [Commented] (SLING-9660) Add RequestPathInfoBuilder for easily constructing Sling URLs



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

Georg Henzler commented on SLING-9660:
--

[~kwin] I think this is now already covered by SLING-9662, also constructing 
URLs works with it [~joerghoh], see 
https://github.com/apache/sling-org-apache-sling-api/tree/feature/SLING-9662-Introduce-Resource-Mapping-SPI/src/main/java/org/apache/sling/api/resource/uri
 and:

{code}
ResourceUriBuilder resourceUriBuilder = 
ResourceUriBuilder.forPath("/path/to/resouce.sel.html/suffix");
// this works because ResourceUri implements  RequestPathInfo
RequestPathInfo requestPathInfo = requestPathInfoBuilder.build();
{code}
 if you want to change this in a URL you can just use 
{code}
ResourceUriBuilder resourceUriBuilder = 
ResourceUriBuilder.forPath("/path/to/resouce.sel.html/suffix");
resourceUriBuilder.useSchemeAndAuthority(new URI("https://example.com:8443;))
ResourceUri resourceUri = requestPathInfoBuilder.build();
String resourceUriStr = resourceUri.toString();
URI resourceRealURI = resourceUri.toUri();
{code}
or you can create a full URI to start with
{code}
ResourceUriBuilder resourceUriBuilder = 
ResourceUriBuilder.forPath("https://example.com/path/to/resouce.sel.html/suffix?test=1#frag;);
// and e.g. add a selector and change the suffix
resourceUriBuilder.addSelector("sel2")
resourceUriBuilder.setSuffix("/anotherSuffix")
ResourceUri resourceUri = requestPathInfoBuilder.build();
// resourceUri.toString() will contain
// https://example.com/path/to/resouce.sel.sel2.html/anotherSuffix?test=1#frag
{code}


> Add RequestPathInfoBuilder for easily constructing Sling URLs
> -
>
> Key: SLING-9660
> URL: https://issues.apache.org/jira/browse/SLING-9660
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: API 2.22.2
>
>
> Currently Sling URLs with their parts outlined in 
> https://sling.apache.org/documentation/the-sling-engine/url-decomposition.html
>  must be constructed manually (i.e. by String operations). 
> To ease constructing such URLs a {{RequestPathInfoBuilder}} should be 
> provided which allows to create a URL out of the individual parts easily.
> Such a Builder should be either constructed from an existing URL or 
> RequestPathInfo and should allow to modify/extend each of the given parts.
> The Builder should work similarly to 
> https://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/client/utils/URIBuilder.html.



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

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



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

Georg Henzler updated SLING-9662:
-
Description: 
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]

  was:
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. 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


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

Re: [DISCUSS] Resource Mapping SPI

2020-08-13 Thread Georg Henzler

Hi all,

so I eventually got around to continue on this. I created JIRA
issue [1] and the branches [2] in API and [3] in resourceresolver
with a first working version.

I definitely prefer immutable classes with a dedicated builder

@Konrad I was critical first because the verbosity of the code,
but it made implementing ResourceUriMappingChain actually easier.
My concern about the verbosity was not that much a problem with
Java 8 anymore.

...And I do believe that mapping is
about the relationship between requests and resources ...

and

- RequestMapper: it maps a "request" to a Resource OR it maps a
Resource to a form that can be requested.

@Julian: So these are very good points, I think RequestMapper is
not ideal because in async code (e.g. Sling jobs), you might
have the case that you have a resource and you map it to a URI
(e.g. for sending an email). in rr.map() you use no
request and usually some manual work is needed to add the host.
My idea for the future would be to provide a simple
ExampleRequest that can be used to provide a hostname or headers
which will then tell the active mappers to do the right thing for
the async, non-request use case. I ended up calling the
SPI interface itself ResourceToUriMapper (which I think is
best spot on for what it does).

So overall I have it all working now in the branches [2] and [3],
currently ResourceUriMappingChain is called from
ResourceResolverImpl.resolveInternal() and
ResourceMapperImpl.getAllMappings(). Other aspects like Sling
alias/vanity path handling, namespace mangling and context
paths are still handled there but could potentially be moved
to a ResourceToUriMapper in further steps. Also see [4]
for some examples on what ResourceToUriMapper can look like.

Let me know what you think!

-Georg

[1] https://issues.apache.org/jira/browse/SLING-9662
[2]
https://github.com/apache/sling-org-apache-sling-api/tree/feature/SLING-9662-Introduce-Resource-Mapping-SPI
[3]
https://github.com/apache/sling-org-apache-sling-resourceresolver/tree/feature/SLING-9662-Introduce-Resource-Mapping-SPI
[4]
https://github.com/apache/sling-org-apache-sling-resourceresolver/tree/feature/SLING-9662-Introduce-Resource-Mapping-SPI/src/main/java/org/apache/sling/resourceresolver/impl/mappingchain/defaultmappers

On 2020-04-01 10:04, Georg Henzler wrote:

Hi Julian,

I'm all for disentangling the mapping implementations (/etc/map,
vanity, alias etc.) and making the mapping pluggable.

great - this is really the main purpose of this thread, to sense
if our community will support the move (because it'll be a bit of
work and for that I'd like to have an agreement on the direction
first)

Despite your suggestion to discuss naming later, Georg, I believe that
naming helps structure thoughts.

yes, we shouldn't be too strict :)

- RequestMapper: it maps a "request" to a Resource OR it maps a
Resource to a form that can be requested.

or maybe UriMapper - while many use cases have a request at hand, there
is always the default mapping that kicks in when null is passed as
request (mostly relevant for for async processes like e.g. sling jobs)

I would rather give the Sling instance an identity (e.g.
protocol, hostname and port)

This is an interesting idea! It wouldn't have to be protocol, hostname
and port, just the protocol would make it a valid uri already, the
internal representation could be slinguri:/path/to/resource.sel.html,
ResourceUri.toString() could just return /path/to/resource.sel.html.

-Georg

On 2020-04-01 00:28, Julian Sedding wrote:

I'm all for disentangling the mapping implementations (/etc/map,
vanity, alias etc.) and making the mapping pluggable.

Over the years I have come to think that the ResourceResolver methods
"resolve" and "map" are actually in the "wrong" interface, because the
handle a different concern than the rest of the RR. Both "resolve" and
"map" are concerned about the HttpServletRequest, which is none of the
RR's business. We cannot fix this due to backwards compatibility, but
maybe we can improve the current situation.

Despite your suggestion to discuss naming later, Georg, I believe that
naming helps structure thoughts. And I do believe that mapping is
about the relationship between requests and resources. Pretty much
everything in Sling is about Resources. Therefore, I suggest
reflecting the request aspect in the naming. This does not
fundamentally change what you are suggesting, and I fully agree on the
ordered chaining of mappers.

- RequestMapper: it maps a "request" to a Resource OR it maps a
Resource to a form that can be requested.
- RequestUri: an abstraction that can be serialized to the string
representation of a URI

I'm not sure we need an external URI and a local one variant of
RequestUri. I would rather give the Sling instance an identity (e.g.
protocol, hostname and port) and use that in conjunction with the
RequestUri in order

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

2020-08-13 Thread Georg Henzler (Jira)

Georg Henzler created SLING-9662:


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


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. 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-8354) Migrate all existing Health Checks in Sling to Felix HC API



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

Georg Henzler resolved SLING-8354.
--
Resolution: Fixed

> Migrate all existing Health Checks in Sling to Felix HC API
> ---
>
> Key: SLING-8354
> URL: https://issues.apache.org/jira/browse/SLING-8354
> Project: Sling
>  Issue Type: New Feature
>  Components: Health Check
>    Reporter: Georg Henzler
>    Assignee: Georg Henzler
>Priority: Major
> Fix For: JUnit Health Check 1.0.8, Content Distribution Core 
> 0.4.4, Installer Health Checks 2.0.4, Commons Scheduler 2.7.8, Discovery Oak 
> 1.2.32
>
>
> Migrate all health checks in Sling project to use the new Felix HC API.
> Generally make the package import to {{org.apache.felix.hc.api}} optional (to 
> make the base functionality still available if the HC framework is not 
> available)



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

[jira] [Updated] (SLING-8354) Migrate all existing Health Checks in Sling to Felix HC API



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

Georg Henzler updated SLING-8354:
-
Summary: Migrate all existing Health Checks in Sling to Felix HC API  (was: 
Migrate all existing Sling Health Checks to Felix HC API)

> Migrate all existing Health Checks in Sling to Felix HC API
> ---
>
> Key: SLING-8354
> URL: https://issues.apache.org/jira/browse/SLING-8354
> Project: Sling
>  Issue Type: New Feature
>  Components: Health Check
>    Reporter: Georg Henzler
>    Assignee: Georg Henzler
>Priority: Major
> Fix For: JUnit Health Check 1.0.8, Content Distribution Core 
> 0.4.4, Installer Health Checks 2.0.4, Commons Scheduler 2.7.8, Discovery Oak 
> 1.2.32
>
>
> Migrate all health checks in Sling project to use the new Felix HC API.
> Generally make the package import to {{org.apache.felix.hc.api}} optional (to 
> make the base functionality still available if the HC framework is not 
> available)



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

[jira] [Updated] (SLING-8354) Migrate all existing Sling Health Checks to Felix HC API



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

Georg Henzler updated SLING-8354:
-
Fix Version/s: JUnit Health Check 1.0.8

> Migrate all existing Sling Health Checks to Felix HC API
> 
>
> Key: SLING-8354
> URL: https://issues.apache.org/jira/browse/SLING-8354
> Project: Sling
>  Issue Type: New Feature
>  Components: Health Check
>    Reporter: Georg Henzler
>    Assignee: Georg Henzler
>Priority: Major
> Fix For: JUnit Health Check 1.0.8, Content Distribution Core 
> 0.4.4, Installer Health Checks 2.0.4, Commons Scheduler 2.7.8, Discovery Oak 
> 1.2.32
>
>
> Migrate all health checks in Sling project to use the new Felix HC API.
> Generally make the package import to {{org.apache.felix.hc.api}} optional (to 
> make the base functionality still available if the HC framework is not 
> available)



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

[jira] [Commented] (SLING-8354) Migrate all existing Sling Health Checks to Felix HC API



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

Georg Henzler commented on SLING-8354:
--

Fixed for org-apache-sling-junit-healthcheck in 
[a9e947c25401db|https://github.com/apache/sling-org-apache-sling-junit-healthcheck/commit/a9e947c25401db062ae3cd7b5f1fde1db649c1b6]

> Migrate all existing Sling Health Checks to Felix HC API
> 
>
> Key: SLING-8354
> URL: https://issues.apache.org/jira/browse/SLING-8354
> Project: Sling
>  Issue Type: New Feature
>  Components: Health Check
>    Reporter: Georg Henzler
>    Assignee: Georg Henzler
>Priority: Major
> Fix For: Content Distribution Core 0.4.4, Installer Health Checks 
> 2.0.4, Commons Scheduler 2.7.8, Discovery Oak 1.2.32
>
>
> Migrate all health checks in Sling project to use the new Felix HC API.
> Generally make the package import to {{org.apache.felix.hc.api}} optional (to 
> make the base functionality still available if the HC framework is not 
> available)



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

[jira] [Updated] (SLING-8354) Migrate all existing Sling Health Checks to Felix HC API



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

Georg Henzler updated SLING-8354:
-
Fix Version/s: Installer Health Checks 2.0.4

> Migrate all existing Sling Health Checks to Felix HC API
> 
>
> Key: SLING-8354
> URL: https://issues.apache.org/jira/browse/SLING-8354
> Project: Sling
>  Issue Type: New Feature
>  Components: Health Check
>    Reporter: Georg Henzler
>    Assignee: Georg Henzler
>Priority: Major
> Fix For: Content Distribution Core 0.4.4, Installer Health Checks 
> 2.0.4, Commons Scheduler 2.7.8, Discovery Oak 1.2.32
>
>
> Migrate all health checks in Sling project to use the new Felix HC API.
> Generally make the package import to {{org.apache.felix.hc.api}} optional (to 
> make the base functionality still available if the HC framework is not 
> available)



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

[jira] [Commented] (SLING-8354) Migrate all existing Sling Health Checks to Felix HC API



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

Georg Henzler commented on SLING-8354:
--

Fixed for org-apache-sling-installer-hc in 
[e70731be8fcaf62|https://github.com/apache/sling-org-apache-sling-installer-hc/commit/e70731be8fcaf624c6df15260559d76f5c51f850]

> Migrate all existing Sling Health Checks to Felix HC API
> 
>
> Key: SLING-8354
> URL: https://issues.apache.org/jira/browse/SLING-8354
> Project: Sling
>  Issue Type: New Feature
>  Components: Health Check
>    Reporter: Georg Henzler
>    Assignee: Georg Henzler
>Priority: Major
> Fix For: Content Distribution Core 0.4.4, Commons Scheduler 
> 2.7.8, Discovery Oak 1.2.32
>
>
> Migrate all health checks in Sling project to use the new Felix HC API.
> Generally make the package import to {{org.apache.felix.hc.api}} optional (to 
> make the base functionality still available if the HC framework is not 
> available)



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

[jira] [Commented] (SLING-8354) Migrate all existing Sling Health Checks to Felix HC API



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

Georg Henzler commented on SLING-8354:
--

Fixed for 
sling-org-apache-sling-commons-scheduler in 
[f6a4f78a9fbfe37|https://github.com/apache/sling-org-apache-sling-commons-scheduler/commit/f6a4f78a9fbfe37e127f36fbb96e5615f963d4bf]

> Migrate all existing Sling Health Checks to Felix HC API
> 
>
> Key: SLING-8354
> URL: https://issues.apache.org/jira/browse/SLING-8354
> Project: Sling
>  Issue Type: New Feature
>  Components: Health Check
>    Reporter: Georg Henzler
>    Assignee: Georg Henzler
>Priority: Major
> Fix For: Content Distribution Core 0.4.4, Discovery Oak 1.2.32
>
>
> Migrate all health checks in Sling project to use the new Felix HC API.
> Generally make the package import to {{org.apache.felix.hc.api}} optional (to 
> make the base functionality still available if the HC framework is not 
> available)



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

[jira] [Updated] (SLING-8354) Migrate all existing Sling Health Checks to Felix HC API



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

Georg Henzler updated SLING-8354:
-
Fix Version/s: Commons Scheduler 2.7.8

> Migrate all existing Sling Health Checks to Felix HC API
> 
>
> Key: SLING-8354
> URL: https://issues.apache.org/jira/browse/SLING-8354
> Project: Sling
>  Issue Type: New Feature
>  Components: Health Check
>    Reporter: Georg Henzler
>    Assignee: Georg Henzler
>Priority: Major
> Fix For: Content Distribution Core 0.4.4, Commons Scheduler 
> 2.7.8, Discovery Oak 1.2.32
>
>
> Migrate all health checks in Sling project to use the new Felix HC API.
> Generally make the package import to {{org.apache.felix.hc.api}} optional (to 
> make the base functionality still available if the HC framework is not 
> available)



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

[jira] [Updated] (SLING-8354) Migrate all existing Sling Health Checks to Felix HC API



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

Georg Henzler updated SLING-8354:
-
Fix Version/s: Discovery Oak 1.2.32

> Migrate all existing Sling Health Checks to Felix HC API
> 
>
> Key: SLING-8354
> URL: https://issues.apache.org/jira/browse/SLING-8354
> Project: Sling
>  Issue Type: New Feature
>  Components: Health Check
>    Reporter: Georg Henzler
>    Assignee: Georg Henzler
>Priority: Major
> Fix For: Content Distribution Core 0.4.4, Discovery Oak 1.2.32
>
>
> Migrate all health checks in Sling project to use the new Felix HC API.
> Generally make the package import to {{org.apache.felix.hc.api}} optional (to 
> make the base functionality still available if the HC framework is not 
> available)



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

[jira] [Updated] (SLING-8354) Migrate all existing Sling Health Checks to Felix HC API



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

Georg Henzler updated SLING-8354:
-
Description: 
Migrate all health checks in Sling project to use the new Felix HC API.

Generally make the package import to {{org.apache.felix.hc.api}} optional (to 
make the base functionality still available if the HC framework is not 
available)

  was:
Migrate all health checks in Sling project to use the new Felix HC API.

Generally make the package import to optional (to make the base functionality 
still available if the HC framework is not available)


> Migrate all existing Sling Health Checks to Felix HC API
> 
>
> Key: SLING-8354
> URL: https://issues.apache.org/jira/browse/SLING-8354
> Project: Sling
>  Issue Type: New Feature
>  Components: Health Check
>    Reporter: Georg Henzler
>    Assignee: Georg Henzler
>Priority: Major
> Fix For: Content Distribution Core 0.4.4
>
>
> Migrate all health checks in Sling project to use the new Felix HC API.
> Generally make the package import to {{org.apache.felix.hc.api}} optional (to 
> make the base functionality still available if the HC framework is not 
> available)



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

[jira] [Commented] (SLING-8354) Migrate all existing Sling Health Checks to Felix HC API



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

Georg Henzler commented on SLING-8354:
--

Fixed for org.apache.sling.discovery.oak in 
[e84a875062ecc17ed6d5|https://github.com/apache/sling-org-apache-sling-distribution-core/commit/e84a875062ecc17ed6d5711ef6e666c932dbe7ab]

> Migrate all existing Sling Health Checks to Felix HC API
> 
>
> Key: SLING-8354
> URL: https://issues.apache.org/jira/browse/SLING-8354
> Project: Sling
>  Issue Type: New Feature
>  Components: Health Check
>    Reporter: Georg Henzler
>    Assignee: Georg Henzler
>Priority: Major
> Fix For: Content Distribution Core 0.4.4
>
>
> Migrate all health checks in Sling project to use the new Felix HC API.
> Generally make the package import to optional (to make the base functionality 
> still available if the HC framework is not available)



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

[jira] [Updated] (SLING-8354) Migrate all existing Sling Health Checks to Felix HC API



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

Georg Henzler updated SLING-8354:
-
Fix Version/s: Content Distribution Core 0.4.4

> Migrate all existing Sling Health Checks to Felix HC API
> 
>
> Key: SLING-8354
> URL: https://issues.apache.org/jira/browse/SLING-8354
> Project: Sling
>  Issue Type: New Feature
>  Components: Health Check
>    Reporter: Georg Henzler
>    Assignee: Georg Henzler
>Priority: Major
> Fix For: Content Distribution Core 0.4.4
>
>
> Migrate all health checks in Sling project to use the new Felix HC API.
> Generally make the package import to optional (to make the base functionality 
> still available if the HC framework is not available)



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

[jira] [Commented] (SLING-8354) Migrate all existing Sling Health Checks to Felix HC API



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

Georg Henzler commented on SLING-8354:
--

Fixed for sling-org-apache-sling-distribution-core in 
[e84a875062ecc17ed6d5|https://github.com/apache/sling-org-apache-sling-distribution-core/commit/e84a875062ecc17ed6d5711ef6e666c932dbe7ab]

> Migrate all existing Sling Health Checks to Felix HC API
> 
>
> Key: SLING-8354
> URL: https://issues.apache.org/jira/browse/SLING-8354
> Project: Sling
>  Issue Type: New Feature
>  Components: Health Check
>    Reporter: Georg Henzler
>    Assignee: Georg Henzler
>Priority: Major
>
> Migrate all health checks in Sling project to use the new Felix HC API.
> Generally make the package import to optional (to make the base functionality 
> still available if the HC framework is not available)



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

[jira] [Updated] (SLING-8354) Migrate all existing Sling Health Checks to Felix HC API



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

Georg Henzler updated SLING-8354:
-
Description: 
Migrate all health checks in Sling project to use the new Felix HC API.

Generally make the package import to optional (to make the base functionality 
still available if the HC framework is not available)

  was:Migrate all health checks in Sling project to use the new Felix HC API.


> Migrate all existing Sling Health Checks to Felix HC API
> 
>
> Key: SLING-8354
> URL: https://issues.apache.org/jira/browse/SLING-8354
> Project: Sling
>  Issue Type: New Feature
>  Components: Health Check
>    Reporter: Georg Henzler
>    Assignee: Georg Henzler
>Priority: Major
>
> Migrate all health checks in Sling project to use the new Felix HC API.
> Generally make the package import to optional (to make the base functionality 
> still available if the HC framework is not available)



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

Re: Please welcome Cris Rockwell, Sling committer

2020-07-23 Thread Georg Henzler

Hi Chris,

welcome to the team!

-Georg

On 2020-07-23 02:22, Cris Rockwell wrote:

Hi all

I'm excited to be here and looking forward to the long journey. I work 
at

the University of Michigan, which is an outstanding place to work an a
developer. Higher education has played an important role in open source
software, and U-M has sponsored many projects over the years. I hope 
the

SAML module will help organizations and companies build new enterprise
applications with Sling. I am also looking forward to contributing to 
other
parts of the project. Developing open source has been a goal of mine 
for a

long time, so very happy to do what I can.

Be well!
Cris

On Wed, Jul 22, 2020, 7:53 PM Andreas Schaefer 

wrote:

Hi Chris

Welcome to the team - well deserved I might say.

Cheers - Andy

> On Jul 22, 2020, at 2:09 AM, Robert Munteanu  wrote:
>
> Hi Sling community,
>
> Based on his ongoing and valuable contributions to the project, the
> Sling PMC has elected Cris Rockwell as a Sling committer, and he
> has accepted the invitation.
>
> Please join me in welcoming Cris!
>
> Cris - if you want to honor the old tradition of new committers
> briefly introducing themselves to the list, feel free.
>
> Welcome!
>
> Robert
>
>
>
>

[jira] [Commented] (SLING-9211) Startup detection not working reliable anymore



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

Georg Henzler commented on SLING-9211:
--

So I checked with 
{code}
java -jar org.apache.sling.feature.launcher-1.1.4.jar -f 
target/slingfeature-tmp/feature-oak_tar.json
{code}
that produced the log file  
[^startup-ServiceUnavailableFilter-first-startup-feature-launcher.log]. It 
works well and the ServiceUnavailableFilter is correctly activated at start 
level 5 on first start already. 

> Startup detection not working reliable anymore
> --
>
> Key: SLING-9211
> URL: https://issues.apache.org/jira/browse/SLING-9211
> Project: Sling
>  Issue Type: Improvement
>  Components: Starter
>    Reporter: Georg Henzler
>    Assignee: Georg Henzler
>Priority: Major
> Attachments: 
> startup-ServiceUnavailableFilter-2nd-startup-works-fine.log, 
> startup-ServiceUnavailableFilter-first-startup-feature-launcher.log, 
> startup-ServiceUnavailableFilter-too-late-registered.log
>
>
> It seems with SLING-8418 the 503 responses are not as reliable as with the 
> previous custom solution. 
> To be checked with script in 
> https://issues.apache.org/jira/browse/FELIX-6097?focusedCommentId=16813130=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16813130



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

[jira] [Updated] (SLING-9211) Startup detection not working reliable anymore



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

Georg Henzler updated SLING-9211:
-
Attachment: 
startup-ServiceUnavailableFilter-first-startup-feature-launcher.log

> Startup detection not working reliable anymore
> --
>
> Key: SLING-9211
> URL: https://issues.apache.org/jira/browse/SLING-9211
> Project: Sling
>  Issue Type: Improvement
>  Components: Starter
>    Reporter: Georg Henzler
>    Assignee: Georg Henzler
>Priority: Major
> Attachments: 
> startup-ServiceUnavailableFilter-2nd-startup-works-fine.log, 
> startup-ServiceUnavailableFilter-first-startup-feature-launcher.log, 
> startup-ServiceUnavailableFilter-too-late-registered.log
>
>
> It seems with SLING-8418 the 503 responses are not as reliable as with the 
> previous custom solution. 
> To be checked with script in 
> https://issues.apache.org/jira/browse/FELIX-6097?focusedCommentId=16813130=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16813130



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

[jira] [Commented] (SLING-9211) Startup detection not working reliable anymore



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

Georg Henzler commented on SLING-9211:
--

[~rombert] I think at the moment the feature model variant is marked as 
experimental README.md - but if we swap over soon we obviously don't need to 
fix "the old world" (I think the problem described is more in project 
org.apache.sling.launchpad.installer than in OSGi installer, but also that will 
be deprecated soon I suppose). I'm testing now the experimental feature model 
variant

> Startup detection not working reliable anymore
> --
>
> Key: SLING-9211
> URL: https://issues.apache.org/jira/browse/SLING-9211
> Project: Sling
>  Issue Type: Improvement
>  Components: Starter
>Reporter: Georg Henzler
>Assignee: Georg Henzler
>Priority: Major
> Attachments: 
> startup-ServiceUnavailableFilter-2nd-startup-works-fine.log, 
> startup-ServiceUnavailableFilter-too-late-registered.log
>
>
> It seems with SLING-8418 the 503 responses are not as reliable as with the 
> previous custom solution. 
> To be checked with script in 
> https://issues.apache.org/jira/browse/FELIX-6097?focusedCommentId=16813130=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16813130



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

[jira] [Comment Edited] (SLING-9211) Startup detection not working reliable anymore



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

Georg Henzler edited comment on SLING-9211 at 7/20/20, 10:28 AM:
-

[~rombert] I think at the moment the feature model variant is marked as 
experimental in README.md - but if we swap over soon we obviously don't need to 
fix "the old world" (I think the problem described is more in project 
org.apache.sling.launchpad.installer than in OSGi installer, but also that will 
be deprecated soon I suppose). I'm testing now the experimental feature model 
variant


was (Author: henzlerg):
[~rombert] I think at the moment the feature model variant is marked as 
experimental README.md - but if we swap over soon we obviously don't need to 
fix "the old world" (I think the problem described is more in project 
org.apache.sling.launchpad.installer than in OSGi installer, but also that will 
be deprecated soon I suppose). I'm testing now the experimental feature model 
variant

> Startup detection not working reliable anymore
> --
>
> Key: SLING-9211
> URL: https://issues.apache.org/jira/browse/SLING-9211
> Project: Sling
>  Issue Type: Improvement
>  Components: Starter
>Reporter: Georg Henzler
>Assignee: Georg Henzler
>Priority: Major
> Attachments: 
> startup-ServiceUnavailableFilter-2nd-startup-works-fine.log, 
> startup-ServiceUnavailableFilter-too-late-registered.log
>
>
> It seems with SLING-8418 the 503 responses are not as reliable as with the 
> previous custom solution. 
> To be checked with script in 
> https://issues.apache.org/jira/browse/FELIX-6097?focusedCommentId=16813130=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16813130



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

[jira] [Comment Edited] (SLING-9211) Startup detection not working reliable anymore