date:20200925

[VOTE] Release Apache Sling Pipes 4.0.0

2020-09-25 Thread Nicolas Peltier

Hi,

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

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

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 2344 /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,
Nicolas Peltier

Re: [VOTE] Release Apache Sling Scripting Core 2.3.4

2020-09-25 Thread Nicolas Peltier

+1

Le ven. 25 sept. 2020 à 21:01, Andreas Schaefer 
a écrit :

> +1 (non-binding)
>
> - Andy
>
> > On Sep 25, 2020, at 11:14 AM, 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 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-25 Thread Nicolas Peltier

+1
(must have been fun to prepare :-D)

Nicolas

Le ven. 25 sept. 2020 à 20:58, Andreas Schaefer 
a écrit :

> +1 (non-binding)
>
> - Andy
>
> > On Sep 25, 2020, at 11:32 AM, 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/12348731>
> > https://issues.apache.org/jira/browse/SLING/fixforversion/12348730 <
> 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/12348726>
> > https://issues.apache.org/jira/browse/SLING/fixforversion/12348719 <
> 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/12348751>
> > https://issues.apache.org/jira/browse/SLING/fixforversion/12348732 <
> https://issues.apache.org/jira/browse/SLING/fixforversion/12348732>
> > https://issues.apache.org/jira/browse/SLING/fixforversion/12348677 <
> 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-2341>
> > https://repository.apache.org/content/repositories/orgapachesling-2342 <
> https://repository.apache.org/content/repositories/orgapachesling-2342>
> > https://repository.apache.org/content/repositories/orgapachesling-2343 <
> 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
>
>

[jira] [Commented] (SLING-7993) create some karate tests for pipes http api integration tests

2020-09-25 Thread Nicolas Peltier (Jira)



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

Nicolas Peltier commented on SLING-7993:


right, i tried a bit of it in 
[https://github.com/npeltier/sling-org-apache-sling-pipes/commit/405747f06948cc1b9402cb4605b8cb5f529b944b,]
 but have some issues:
 * test is not taken when among other "normal" tests,
 * when running that test specifying it, pax exam container with options from 
PipesTestSupport (that are working for other ITs) is not starting

will get back to this later

> create some karate tests for pipes http api integration tests
> -
>
> Key: SLING-7993
> URL: https://issues.apache.org/jira/browse/SLING-7993
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions, pipes
>Affects Versions: Pipes 3.0.2
>Reporter: Nicolas Peltier
>Priority: Major
>
> would be nice to have clear and "documenting" karate tests of pipes http API



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

[jira] [Updated] (SLING-7992) make package pipe folding its filters

2020-09-25 Thread Nicolas Peltier (Jira)



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

Nicolas Peltier updated SLING-7992:
---
Fix Version/s: (was: Pipes 4.0.0)

> make package pipe folding its filters
> -
>
> Key: SLING-7992
> URL: https://issues.apache.org/jira/browse/SLING-7992
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions, pipes
>Affects Versions: Pipes 3.0.2
>Reporter: Nicolas Peltier
>Priority: Major
>
> packaging resources about to change is pretty handy, but filters are not 
> meant to be used for each single resource to save.
> Would be nice to have something like {{maxFilters}} and {{reductionDepth}} 
> that transforms at best following set, with {{maxFilters=1}} and 
> {{reductionDepth=3}}
> - /content/foo/bar/1
> - /content/foo/bar/2
> in
> - /content/foo/bar
> if not possible to satisfy the constraints, it just does nothing



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

[jira] [Updated] (SLING-7993) create some karate tests for pipes http api integration tests

2020-09-25 Thread Nicolas Peltier (Jira)



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

Nicolas Peltier updated SLING-7993:
---
Fix Version/s: (was: Pipes 4.0.0)

> create some karate tests for pipes http api integration tests
> -
>
> Key: SLING-7993
> URL: https://issues.apache.org/jira/browse/SLING-7993
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions, pipes
>Affects Versions: Pipes 3.0.2
>Reporter: Nicolas Peltier
>Priority: Major
>
> would be nice to have clear and "documenting" karate tests of pipes http API



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

Re: [VOTE] Release Apache Sling Scripting Core 2.3.4

2020-09-25 Thread Andreas Schaefer

+1 (non-binding)

- Andy

> On Sep 25, 2020, at 11:14 AM, 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 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-25 Thread Andreas Schaefer

+1 (non-binding)

- Andy

> On Sep 25, 2020, at 11:32 AM, 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

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

2020-09-25 Thread Radu Cotescu

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

[jira] [Updated] (SLING-9653) HTL Maven Plugin: Include GitHub ribbon and edit button

2020-09-25 Thread Radu Cotescu (Jira)



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

Radu Cotescu updated SLING-9653:

Fix Version/s: (was: HTL Maven Plugin 2.0.2-1.4.0)
   HTL Maven Plugin 2.0.4-1.4.0

> HTL Maven Plugin: Include GitHub ribbon and edit button
> ---
>
> Key: SLING-9653
> URL: https://issues.apache.org/jira/browse/SLING-9653
> Project: Sling
>  Issue Type: Improvement
>  Components: Maven Plugins and Archetypes
>Reporter: Konrad Windszus
>Priority: Minor
> Fix For: HTL Maven Plugin 2.0.4-1.4.0
>
>
> We should include a GitHub ribbon in the header (like outlined 
> https://maven.apache.org/skins/maven-fluido-skin/#GitHub_ribbons) to ease 
> contributing PRs. Also an edit button should be enabled on all Doxia 
> generated documentation pages via 
> https://maven.apache.org/doxia/doxia-sitetools/doxia-decoration-model/decoration.html
>  (edit element in the site.xml)



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

[jira] [Updated] (SLING-9696) HTL does not correctly cast the "false" string to Boolean

2020-09-25 Thread Radu Cotescu (Jira)



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

Radu Cotescu updated SLING-9696:

Fix Version/s: HTL Maven Plugin 2.0.2-1.4.0

> HTL does not correctly cast the "false" string to Boolean
> -
>
> Key: SLING-9696
> URL: https://issues.apache.org/jira/browse/SLING-9696
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting Sightly Engine 1.0.0, Scripting HTL Engine 
> 1.0.20, Scripting HTL Engine 1.1.0-1.4.0, Scripting HTL Engine 1.2.0-1.4.0, 
> Scripting HTL Engine 1.3.0-1.4.0, Scripting HTL Engine 1.4.0-1.4.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: HTL Maven Plugin 2.0.2-1.4.0, Scripting HTL Runtime 
> 1.2.4-1.4.0, Scripting HTL Engine 1.4.4-1.4.0, Scripting HTL Java Compiler 
> 1.2.2-1.4.0, Scripting HTL Compiler 1.2.8-1.4.0, Scripting HTL Testing 
> 1.0.24-1.4.0
>
>
> The HTL engine implementation from Apache Sling seems to have never correctly 
> casted the "false" string to boolean. The HTL specification [0] mentions the 
> following:
> {noformat}
> These expressions evaluate to false:
> * false
> * 0 (zero)
> * '' or "" (empty string)
> * [] (empty iterable)
> These evaluate to true:
> * "false" (non-empty string)
> * [0] (non-empty iterable)
> {noformat}
> However, all implementations have returned the Boolean {{false}} for any 
> casing of the string "false".
> A change like this has the potential to break the functionality of existing 
> HTL code, relying on the fact that the string "false" (irrespective of its 
> casing) returns the Boolean {{false}}, however the implementation should obey 
> the specification. Therefore I think the fix should be behind a configuration 
> flag, which by default allows the engine to continue working with the wrong 
> behaviour. Deployers can then decide via configuration if they would like to 
> switch the engine to the correct behaviour.
>  
> [0] - 
> [https://github.com/adobe/htl-spec/blob/1.4/SPECIFICATION.md#115-casting]



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

[jira] [Updated] (SLING-9706) The HTL Java Compiler does not correctly negate equals

2020-09-25 Thread Radu Cotescu (Jira)



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

Radu Cotescu updated SLING-9706:

Fix Version/s: HTL Maven Plugin 2.0.2-1.4.0

> The HTL Java Compiler does not correctly negate equals
> --
>
> Key: SLING-9706
> URL: https://issues.apache.org/jira/browse/SLING-9706
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting HTL Java Compiler 1.0.4, Scripting HTL Java 
> Compiler 1.1.0-1.4.0, Scripting HTL Java Compiler 1.2.0-1.4.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: HTL Maven Plugin 2.0.2-1.4.0, Scripting HTL Java 
> Compiler 1.2.2-1.4.0
>
>
> Although the {{equals}} operation is only generated for internal HTL Compiler 
> commands, the operation is not correctly negated when using the 
> {{Binary.NEQ}} operator.



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

[VOTE] Release Apache Sling Scripting Core 2.3.4

2020-09-25 Thread Radu Cotescu

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

[jira] [Resolved] (SLING-9768) The org.apache.sling.api.scripting.SlingScript#getScriptResource implementations should not leak the scripting resolver

2020-09-25 Thread Radu Cotescu (Jira)



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

Radu Cotescu resolved SLING-9768.
-
Fix Version/s: Scripting HTL Testing Content 1.0.22-1.4.0
   Scripting HTL Testing 1.0.24-1.4.0
   Resolution: Fixed

Implemented changes in:
* [commit 
714cc2d|https://github.com/apache/sling-org-apache-sling-scripting-core/commit/714cc2d]
* [commit 
f34a9b3|https://github.com/apache/sling-org-apache-sling-scripting-sightly/commit/f34a9b3]
* [commit 
33c3f8f|https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing-content/commit/33c3f8f]
* [commit 
804f280|https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing/commit/804f280]

> The org.apache.sling.api.scripting.SlingScript#getScriptResource 
> implementations should not leak the scripting resolver
> ---
>
> Key: SLING-9768
> URL: https://issues.apache.org/jira/browse/SLING-9768
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting Core 2.3.0, Scripting HTL Engine 1.4.2-1.4.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting Core 2.3.4, Scripting HTL Engine 1.4.4-1.4.0, 
> Scripting HTL Testing 1.0.24-1.4.0, Scripting HTL Testing Content 1.0.22-1.4.0
>
>
> Since the {{SlingScript}} is usually made available via the {{bindings}} to 
> the current executing script, the resolver that can be accessed via 
> {{org.apache.sling.api.scripting.SlingScript#getScriptResource}} should not 
> give elevated access to the caller. This means that either the caller is 
> responsible for the mapped resolver (by getting a mapped resolver to the 
> bundle the caller comes from via script precompilation), or the resolver 
> should be the request resolver.



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

[jira] [Commented] (SLING-9769) Minor memory leak in MapEntries class

2020-09-25 Thread Julian Sedding (Jira)



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

Julian Sedding commented on SLING-9769:
---

[PR 
#21|https://github.com/apache/sling-org-apache-sling-resourceresolver/pull/21] 
is available.

> Minor memory leak in MapEntries class
> -
>
> Key: SLING-9769
> URL: https://issues.apache.org/jira/browse/SLING-9769
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.1.10
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> SLING-4216 introduced a limit to the number of cached vanity paths. If the 
> cache size is exceeded, it falls back to a repository search, which is 
> relatively costly. So in order to avoid most of the costly calls, a bloom 
> filter was introduced to answer the question whether a search is likely to 
> yield a result.
> The bloom filter is by default nearly 1MB in size (without Java overhead) and 
> it is persisted in a file and a {{java.util.Timer}} was introduced "for 
> persisting the bloom filter every minute".
> The memory leak is that the {{Timer}} is not cancelled when 
> {{MapEntries#dispose}} is called, and thus the timer's thread holds on to a 
> reference of the {{MapEntries}} instance. Now the severity of this issue is 
> low for two reasons:
> 1. MapEntries is a singleton in a normal Sling deployment.
> 2. A bug causes the {{TimerTask}} to be executed only once after 60 seconds 
> and not repeatedly. I.e. the thread disappeared after ~1 minute.
> I discovered the memory leak when running unit tests that use Sling-Mock. 
> During testing a new {{ResourceResolverFactory}} instance, together with its 
> associated {{MapEntries}} is created for every test method. In a module with 
> ~700 test methods that lead to an {{OutOfMemoryError}} with 1GB max heap size.
> Fixing the memory leak allowed the same module to run with only 96MB max heap.
> I intend to also fix the {{Timer}} to be scheduled to run once every minute. 
> This intention is indicated by a comment in the code.
> The use of a non-volatile boolean field also looks like it might be prone to 
> concurrency/visibility issues and may be better replaced by an 
> {{AtomicBoolean}}.
> cc [~asanso]
> [~sseifert] do you think it would make sense for Sling Mock to set 
> {{resource.resolver.vanitypath.bloomfilter.maxBytes = 0}} by default? 



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

[jira] [Updated] (SLING-9769) Minor memory leak in MapEntries class

2020-09-25 Thread Julian Sedding (Jira)



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

Julian Sedding updated SLING-9769:
--
Description: 
SLING-4216 introduced a limit to the number of cached vanity paths. If the 
cache size is exceeded, it falls back to a repository search, which is 
relatively costly. So in order to avoid most of the costly calls, a bloom 
filter was introduced to answer the question whether a search is likely to 
yield a result.

The bloom filter is by default nearly 1MB in size (without Java overhead) and 
it is persisted in a file and a {{java.util.Timer}} was introduced "for 
persisting the bloom filter every minute".

The memory leak is that the {{Timer}} is not cancelled when 
{{MapEntries#dispose}} is called, and thus the timer's thread holds on to a 
reference of the {{MapEntries}} instance. Now the severity of this issue is low 
for two reasons:

1. MapEntries is a singleton in a normal Sling deployment.
2. A bug causes the {{TimerTask}} to be executed only once after 60 seconds and 
not repeatedly. I.e. the thread disappeared after ~1 minute.

I discovered the memory leak when running unit tests that use Sling-Mock. 
During testing a new {{ResourceResolverFactory}} instance, together with its 
associated {{MapEntries}} is created for every test method. In a module with 
~700 test methods that lead to an {{OutOfMemoryError}} with 1GB max heap size.

Fixing the memory leak allowed the same module to run with only 96MB max heap.

I intend to also fix the {{Timer}} to be scheduled to run once every minute. 
This intention is indicated by a comment in the code.

The use of a non-volatile boolean field also looks like it might be prone to 
concurrency/visibility issues and may be better replaced by an 
{{AtomicBoolean}}.

cc [~asanso]

[~sseifert] do you think it would make sense for Sling Mock to set 
{{resource.resolver.vanitypath.bloomfilter.maxBytes = 0}} by default? 

  was:
SLING-4216 introduced a limit to the number of cached vanity paths. If the 
cache size is exceeded, it falls back to a repository search, which is 
relatively costly. So in order to avoid most of the costly calls, a bloom 
filter was introduced to answer the question whether a search is likely to 
yield a result.

The bloom filter is by default nearly 1MB in size (without Java overhead) and 
it is persisted in a file and a {{java.util.Timer}} was introduced "for 
persisting the bloom filter every minute".

The memory leak is that the {{Timer}} is not cancelled when 
{{MapEntries#dispose}} is called, and thus the timer's thread holds on to a 
reference of the {{MapEntries}} instance. Now the severity of this issue is low 
for two reasons:

1. MapEntries is a singleton in a normal Sling deployment.
2. A bug causes the {{TimerTask}} to be executed only once after 60 seconds and 
not repeatedly. I.e. the thread disappeared after ~1 minute.

I discovered the memory leak when running unit tests that use Sling-Mock. 
During testing a new {{ResourceResolverFactory}} instance, together with its 
associated {{MapEntries}} is created for every test method. In a module with 
~700 test methods that lead to an OutOfMemoryError}} with 1GB max heap size.

Fixing the memory leak allowed the same module to run with only 96MB max heap.

I intend to also fix the {{Timer}} to be scheduled to run once every minute. 
This intention is indicated by a comment in the code.

The use of a non-volatile boolean field also looks like it might be prone to 
concurrency/visibility issues and may be better replaced by an 
{{AtomicBoolean}}.

cc [~asanso]

[~sseifert] do you think it would make sense for Sling Mock to set 
{{resource.resolver.vanitypath.bloomfilter.maxBytes = 0}} by default? 


> Minor memory leak in MapEntries class
> -
>
> Key: SLING-9769
> URL: https://issues.apache.org/jira/browse/SLING-9769
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.1.10
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> SLING-4216 introduced a limit to the number of cached vanity paths. If the 
> cache size is exceeded, it falls back to a repository search, which is 
> relatively costly. So in order to avoid most of the costly calls, a bloom 
> filter was introduced to answer the question whether a search is likely to 
> yield a result.
> The bloom filter is by default nearly 1MB in size (without Java overhead) and 
> it is persisted in a file and a {{java.util.Timer}} was introduced "for 
> persisting the bloom filter every minute".
> The memory leak is that the {{Timer}} is not cancelled when 
> {{MapEntries#dispose}} is called, and thus the timer's thread holds on to a 
> reference of the {{MapEntries}}

[jira] [Updated] (SLING-9769) Minor memory leak in MapEntries class

2020-09-25 Thread Julian Sedding (Jira)



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

Julian Sedding updated SLING-9769:
--
Description: 
SLING-4216 introduced a limit to the number of cached vanity paths. If the 
cache size is exceeded, it falls back to a repository search, which is 
relatively costly. So in order to avoid most of the costly calls, a bloom 
filter was introduced to answer the question whether a search is likely to 
yield a result.

The bloom filter is by default nearly 1MB in size (without Java overhead) and 
it is persisted in a file and a {{java.util.Timer}} was introduced "for 
persisting the bloom filter every minute".

The memory leak is that the {{Timer}} is not cancelled when 
{{MapEntries#dispose}} is called, and thus the timer's thread holds on to a 
reference of the {{MapEntries}} instance. Now the severity of this issue is low 
for two reasons:

1. MapEntries is a singleton in a normal Sling deployment.
2. A bug causes the {{TimerTask}} to be executed only once after 60 seconds and 
not repeatedly. I.e. the thread disappeared after ~1 minute.

I discovered the memory leak when running unit tests that use Sling-Mock. 
During testing a new {{ResourceResolverFactory}} instance, together with its 
associated {{MapEntries}} is created for every test method. In a module with 
~700 test methods that lead to an OutOfMemoryError}} with 1GB max heap size.

Fixing the memory leak allowed the same module to run with only 96MB max heap.

I intend to also fix the {{Timer}} to be scheduled to run once every minute. 
This intention is indicated by a comment in the code.

The use of a non-volatile boolean field also looks like it might be prone to 
concurrency/visibility issues and may be better replaced by an 
{{AtomicBoolean}}.

cc [~asanso]

[~sseifert] do you think it would make sense for Sling Mock to set 
{{resource.resolver.vanitypath.bloomfilter.maxBytes = 0}} by default? 

  was:
SLING-4216 introduced a limit to the number of cached vanity paths. If the 
cache size is exceeded, it falls back to a repository search, which is 
relatively costly. So in order to avoid most of the costly calls, a bloom 
filter was introduced to answer the question whether a search is likely to 
yield a result.

The bloom filter is by default nearly 1MB in size (without Java overhead) and 
it is persisted in a file and a {{java.util.Timer}} was introduced "for 
persisting the bloom filter every minute".

The memory leak is that the {{Timer}} is not cancelled when 
{{MapEntries#dispose}} is called, and thus the timer's thread holds on to a 
reference of the {{MapEntries}} instance. Now the severity of this issue is low 
for two reasons:

1. MapEntries is a singleton in a normal Sling deployment.
2. A bug causes the {{TimerTask}} to be executed only once after 60 seconds and 
not repeatedly. I.e. the thread disappeared after ~1 minute.

I discovered the memory leak when running unit tests that use Sling-Mock. 
During testing a new {{ResourceResolverFactory}} instance, together with its 
associated {{MapEntries}} is created for every test method. In a module with 
~700 test methods that lead to an OutOfMemoryError}} with 1GB max heap size.

Fixing the memory leak allowed the same module to run with only 96MB max heap.

I intend to also fix the {{Timer}} to be scheduled to run once every minute. 
This intention is indicated by a comment in the code.

The use of a non-volatile boolean field also looks like it might be prone to 
concurrency/visibility issues and may be better replaced by an 
{{AtomicBoolean}}.

cc [~asanso]


> Minor memory leak in MapEntries class
> -
>
> Key: SLING-9769
> URL: https://issues.apache.org/jira/browse/SLING-9769
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.1.10
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> SLING-4216 introduced a limit to the number of cached vanity paths. If the 
> cache size is exceeded, it falls back to a repository search, which is 
> relatively costly. So in order to avoid most of the costly calls, a bloom 
> filter was introduced to answer the question whether a search is likely to 
> yield a result.
> The bloom filter is by default nearly 1MB in size (without Java overhead) and 
> it is persisted in a file and a {{java.util.Timer}} was introduced "for 
> persisting the bloom filter every minute".
> The memory leak is that the {{Timer}} is not cancelled when 
> {{MapEntries#dispose}} is called, and thus the timer's thread holds on to a 
> reference of the {{MapEntries}} instance. Now the severity of this issue is 
> low for two reasons:
> 1. MapEntries is a singleton in a normal Sling deployment.
> 2. A bug ca

[jira] [Updated] (SLING-9769) Minor memory leak in MapEntries class

2020-09-25 Thread Julian Sedding (Jira)



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

Julian Sedding updated SLING-9769:
--
Description: 
SLING-4216 introduced a limit to the number of cached vanity paths. If the 
cache size is exceeded, it falls back to a repository search, which is 
relatively costly. So in order to avoid most of the costly calls, a bloom 
filter was introduced to answer the question whether a search is likely to 
yield a result.

The bloom filter is by default nearly 1MB in size (without Java overhead) and 
it is persisted in a file and a {{java.util.Timer}} was introduced "for 
persisting the bloom filter every minute".

The memory leak is that the {{Timer}} is not cancelled when 
{{MapEntries#dispose}} is called, and thus the timer's thread holds on to a 
reference of the {{MapEntries}} instance. Now the severity of this issue is low 
for two reasons:

1. MapEntries is a singleton in a normal Sling deployment.
2. A bug causes the {{TimerTask}} to be executed only once after 60 seconds and 
not repeatedly. I.e. the thread disappeared after ~1 minute.

I discovered the memory leak when running unit tests that use Sling-Mock. 
During testing a new {{ResourceResolverFactory}} instance, together with its 
associated {{MapEntries}} is created for every test method. In a module with 
~700 test methods that lead to an OutOfMemoryError}} with 1GB max heap size.

Fixing the memory leak allowed the same module to run with only 96MB max heap.

I intend to also fix the {{Timer}} to be scheduled to run once every minute. 
This intention is indicated by a comment in the code.

The use of a non-volatile boolean field also looks like it might be prone to 
concurrency/visibility issues and may be better replaced by an 
{{AtomicBoolean}}.

cc [~asanso]

  was:
SLING-4216 introduced a limit to the number of cached vanity paths. If the 
cache size is exceeded, it falls back to a repository search, which is 
relatively costly. So in order to avoid most of the costly calls, a bloom 
filter was introduced to answer the question whether a search is likely to 
yield a result.

The bloom filter is by default nearly 1MB in size (without Java overhead) and 
it is persisted in a file and a {{java.util.Timer}} was introduced "for 
persisting the bloom filter every minute".

The memory leak is that the {{Timer}} is not cancelled when 
{{MapEntries#dispose}} is called, and thus the timer's thread holds on to a 
reference of the {{MapEntries}} instance. Now the severity of this issue is low 
for two reasons:

1. MapEntries is a singleton in a normal Sling deployment.
2. A bug causes the {{TimerTask}} to be executed only once after 60 seconds and 
not repeatedly. I.e. the thread disappeared after ~1 minute.

I discovered the memory leak when running unit tests that use Sling-Mock. 
During testing a new {{ResourceResolverFactory}} instance, together with its 
associated {{MapEntries}} is created for every test method. In a module with 
~700 test methods that lead to an OutOfMemoryError}} with 1GB max heap size.

Fixing the memory leak allowed the same module to run with only 96MB max heap.

cc [~asanso]


> Minor memory leak in MapEntries class
> -
>
> Key: SLING-9769
> URL: https://issues.apache.org/jira/browse/SLING-9769
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.1.10
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> SLING-4216 introduced a limit to the number of cached vanity paths. If the 
> cache size is exceeded, it falls back to a repository search, which is 
> relatively costly. So in order to avoid most of the costly calls, a bloom 
> filter was introduced to answer the question whether a search is likely to 
> yield a result.
> The bloom filter is by default nearly 1MB in size (without Java overhead) and 
> it is persisted in a file and a {{java.util.Timer}} was introduced "for 
> persisting the bloom filter every minute".
> The memory leak is that the {{Timer}} is not cancelled when 
> {{MapEntries#dispose}} is called, and thus the timer's thread holds on to a 
> reference of the {{MapEntries}} instance. Now the severity of this issue is 
> low for two reasons:
> 1. MapEntries is a singleton in a normal Sling deployment.
> 2. A bug causes the {{TimerTask}} to be executed only once after 60 seconds 
> and not repeatedly. I.e. the thread disappeared after ~1 minute.
> I discovered the memory leak when running unit tests that use Sling-Mock. 
> During testing a new {{ResourceResolverFactory}} instance, together with its 
> associated {{MapEntries}} is created for every test method. In a module with 
> ~700 test methods that lead to an OutOfMemoryError}} with 1GB m

[GitHub] [sling-org-apache-sling-resourceresolver] sonarcloud[bot] commented on pull request #21: SLING-9769 - Minor memory leak in MapEntries class

2020-09-25 Thread GitBox



sonarcloud[bot] commented on pull request #21:
URL: 
https://github.com/apache/sling-org-apache-sling-resourceresolver/pull/21#issuecomment-698961757


   Kudos, SonarCloud Quality Gate passed!
   
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-resourceresolver&pullRequest=21&resolved=false&types=BUG)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-resourceresolver&pullRequest=21&resolved=false&types=BUG)
 [0 
Bugs](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-resourceresolver&pullRequest=21&resolved=false&types=BUG)
  
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-resourceresolver&pullRequest=21&resolved=false&types=VULNERABILITY)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-resourceresolver&pullRequest=21&resolved=false&types=VULNERABILITY)
 [0 
Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-resourceresolver&pullRequest=21&resolved=false&types=VULNERABILITY)
 (and [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-resourceresolver&pullRequest=21&reso
 lved=false&types=SECURITY_HOTSPOT) [0 Security 
Hotspots](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-resourceresolver&pullRequest=21&resolved=false&types=SECURITY_HOTSPOT)
 to review)  
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-resourceresolver&pullRequest=21&resolved=false&types=CODE_SMELL)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-resourceresolver&pullRequest=21&resolved=false&types=CODE_SMELL)
 [1 Code 
Smell](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-resourceresolver&pullRequest=21&resolved=false&types=CODE_SMELL)
   
   [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-resourceresolver&pullRequest=21&metric=new_coverage&view=list)
 [80.0% 
Coverage](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-resourceresolver&pullRequest=21&metric=new_coverage&view=list)
  
   [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-resourceresolver&pullRequest=21&metric=new_duplicated_lines_density&view=list)
 [0.0% 
Duplication](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-resourceresolver&pullRequest=21&metric=new_duplicated_lines_density&view=list)
   
The version of Java (1.8.0_252) you 
have used to run this analysis is deprecated and we will stop accepting it from 
October 2020. Please update to at least Java 11.
   Read more [here](https://sonarcloud.io/documentation/upcoming/)
   
   
   



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

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

[GitHub] [sling-org-apache-sling-resourceresolver] jsedding opened a new pull request #21: SLING-9769 - Minor memory leak in MapEntries class

2020-09-25 Thread GitBox



jsedding opened a new pull request #21:
URL: https://github.com/apache/sling-org-apache-sling-resourceresolver/pull/21


   



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

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

[jira] [Created] (SLING-9769) Minor memory leak in MapEntries class

2020-09-25 Thread Julian Sedding (Jira)

Julian Sedding created SLING-9769:
-

 Summary: Minor memory leak in MapEntries class
 Key: SLING-9769
 URL: https://issues.apache.org/jira/browse/SLING-9769
 Project: Sling
  Issue Type: Bug
  Components: ResourceResolver
Affects Versions: Resource Resolver 1.1.10
Reporter: Julian Sedding
Assignee: Julian Sedding


SLING-4216 introduced a limit to the number of cached vanity paths. If the 
cache size is exceeded, it falls back to a repository search, which is 
relatively costly. So in order to avoid most of the costly calls, a bloom 
filter was introduced to answer the question whether a search is likely to 
yield a result.

The bloom filter is by default nearly 1MB in size (without Java overhead) and 
it is persisted in a file and a {{java.util.Timer}} was introduced "for 
persisting the bloom filter every minute".

The memory leak is that the {{Timer}} is not cancelled when 
{{MapEntries#dispose}} is called, and thus the timer's thread holds on to a 
reference of the {{MapEntries}} instance. Now the severity of this issue is low 
for two reasons:

1. MapEntries is a singleton in a normal Sling deployment.
2. A bug causes the {{TimerTask}} to be executed only once after 60 seconds and 
not repeatedly. I.e. the thread disappeared after ~1 minute.

I discovered the memory leak when running unit tests that use Sling-Mock. 
During testing a new {{ResourceResolverFactory}} instance, together with its 
associated {{MapEntries}} is created for every test method. In a module with 
~700 test methods that lead to an OutOfMemoryError}} with 1GB max heap size.

Fixing the memory leak allowed the same module to run with only 96MB max heap.

cc [~asanso]



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

[GitHub] [sling-slingfeature-maven-plugin] enapps-enorman commented on a change in pull request #58: SLING-9656 gracefully handle scenarios where the AggregateFeaturesMojo gets invoked more than once

2020-09-25 Thread GitBox



enapps-enorman commented on a change in pull request #58:
URL: 
https://github.com/apache/sling-slingfeature-maven-plugin/pull/58#discussion_r494540600



##
File path: 
src/main/java/org/apache/sling/feature/maven/mojos/AggregateFeaturesMojo.java
##
@@ -65,6 +68,15 @@
 @Override
 public void execute() throws MojoExecutionException {
 checkPreconditions();
+

Review comment:
   Thanks for reviewing and I see your point.  I left a comment on the JIRA 
ticket for your consideration.





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

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

[GitHub] [sling-slingfeature-maven-plugin] cziegeler commented on a change in pull request #58: SLING-9656 gracefully handle scenarios where the AggregateFeaturesMojo gets invoked more than once durin

2020-09-25 Thread GitBox



cziegeler commented on a change in pull request #58:
URL: 
https://github.com/apache/sling-slingfeature-maven-plugin/pull/58#discussion_r494083414



##
File path: 
src/main/java/org/apache/sling/feature/maven/mojos/AggregateFeaturesMojo.java
##
@@ -65,6 +68,15 @@
 @Override
 public void execute() throws MojoExecutionException {
 checkPreconditions();
+

Review comment:
   I think this doesn't work - it's totally legitimate to use the aggregate 
mojo more than once in a project, especially when you use profiles with 
different aggregations





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

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

[GitHub] [sling-org-apache-sling-graphql-core] bdelacretaz commented on pull request #1: Feature/sling 9550 all scalars

2020-09-25 Thread GitBox



bdelacretaz commented on pull request #1:
URL: 
https://github.com/apache/sling-org-apache-sling-graphql-core/pull/1#issuecomment-698322216


   I'm closing this due to no activity and as 
https://issues.apache.org/jira/browse/SLING-9550 closed now. We can reopen or 
create a new one if needed.



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

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

[GitHub] [sling-org-apache-sling-graphql-core] bdelacretaz closed pull request #1: Feature/sling 9550 all scalars

2020-09-25 Thread GitBox



bdelacretaz closed pull request #1:
URL: https://github.com/apache/sling-org-apache-sling-graphql-core/pull/1


   



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

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

[GitHub] [sling-org-apache-sling-graphql-core] bdelacretaz closed pull request #5: SLING-9766 - take selectors into account in cache key

2020-09-25 Thread GitBox



bdelacretaz closed pull request #5:
URL: https://github.com/apache/sling-org-apache-sling-graphql-core/pull/5


   



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

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

[jira] [Created] (SLING-9768) The org.apache.sling.api.scripting.SlingScript#getScriptResource implementations should not leak the scripting resolver

2020-09-25 Thread Radu Cotescu (Jira)

Radu Cotescu created SLING-9768:
---

 Summary: The 
org.apache.sling.api.scripting.SlingScript#getScriptResource implementations 
should not leak the scripting resolver
 Key: SLING-9768
 URL: https://issues.apache.org/jira/browse/SLING-9768
 Project: Sling
  Issue Type: Bug
  Components: Scripting
Affects Versions: Scripting HTL Engine 1.4.2-1.4.0, Scripting Core 2.3.0
Reporter: Radu Cotescu
Assignee: Radu Cotescu
 Fix For: Scripting Core 2.3.4, Scripting HTL Engine 1.4.4-1.4.0


Since the {{SlingScript}} is usually made available via the {{bindings}} to the 
current executing script, the resolver that can be accessed via 
{{org.apache.sling.api.scripting.SlingScript#getScriptResource}} should not 
give elevated access to the caller. This means that either the caller is 
responsible for the mapped resolver (by getting a mapped resolver to the bundle 
the caller comes from via script precompilation), or the resolver should be the 
request resolver.



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

[GitHub] [sling-org-apache-sling-graphql-core] bdelacretaz commented on pull request #5: SLING-9766 - take selectors into account in cache key

2020-09-25 Thread GitBox



bdelacretaz commented on pull request #5:
URL: 
https://github.com/apache/sling-org-apache-sling-graphql-core/pull/5#issuecomment-698326457







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

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

[jira] [Commented] (SLING-9767) Insecure Recommendation in Dynamic Include Documentation

2020-09-25 Thread Jira



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

Tomasz Niedźwiedź commented on SLING-9767:
--

[~rombert] depending on the modules installed and the kind of content that gets 
rendered on the given Sling site (UGC anyone?), an attempt to run a command 
using {{}} could fail entirely or become a viable attack vector. 
The original instructions I copied to the Sling site were meant as a quick 
getting-started guide and each actual Apache setup should be reviewed prior to 
being made public, with a round of penetration tests to cover such scenarios.

That said, I can see how it is quite likely for the example code to be copied 
verbatim and placed in a configuration where it introduces a serious 
vulnerability. Using the {{IncludesNOEXEC}} option by default seems like a good 
idea and I don't think it could otherwise impact the way SDI works. A few words 
of warning could be provided too, so that users are more aware of the potential 
risks and the extra testing they might want to do.

[~chaotic] would you like to contribute an improvement to the docs?

> Insecure Recommendation in Dynamic Include Documentation
> 
>
> Key: SLING-9767
> URL: https://issues.apache.org/jira/browse/SLING-9767
> Project: Sling
>  Issue Type: Improvement
>  Components: Documentation
>Affects Versions: Dynamic Include 3.2.0
>Reporter: Lars Krapf
>Priority: Major
>
> The [documentation for the Sling Dynamic 
> Includes|https://sling.apache.org/documentation/bundles/dynamic-includes.html#enabling-ssi-in-apache-with-the-aem-dispatcher-module]
>  mentions the following:
> bq. Having added the SetOutputFilter directive, open the virtual host's 
> configuration and add the Includes option to the Options directive:
> This is an extremely unsafe recommendation. The "Includes" option will allow 
> anyone who can change content on the backend (e.g. AEM) to run arbitrary 
> commands on the webserver (dispatcher), by injecting the {{}} 
> directive.
> The recommendation should be to use the "IncludesNOEXEC" option instead, 
> which will only allow to include static content (with a "safe" mime-type such 
> as HTML or plain-text). 
> See also: http://httpd.apache.org/docs/current/mod/mod_include.html



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

Re: Virtual Round Table at adaptTo

2020-09-25 Thread Radu Cotescu

Hi,

The emails Robert mentioned got caught by my spam filter. In case you don’t see 
the emails Robert mentioned then also check your Junk folder.

Cheers,
Radu

> On 25 Sep 2020, at 14:17, Robert Munteanu  wrote:
> 
> Hi,
> 
> I've sent an invite to everyone that has registered so far.
> 
> If you registered but did not get an invite please let me know.
> 
> Note that the meeting URL will prompt you to install/launch an app, but
> there is a small 'Join with Browser' link at the bottom.
> 
> Thanks,
> Robert
> 
> On Thu, 2020-09-10 at 15:56 +0200, Robert Munteanu wrote:
>> Hi,
>> 
>> Since adaptTo is going virtual this year I propose that we go virtual
>> for the round table as well. The alternative, of course, is that we
>> don't hold the round table at all which would be a shame :-)
>> 
>> If you're interested, please see
>> 
>> 
>> https://cwiki.apache.org/confluence/display/SLING/Virtual+Round+Table+-+28+September+2020
>> 
>> Thanks,
>> Robert
>> 
>

[jira] [Commented] (SLING-9767) Insecure Recommendation in Dynamic Include Documentation

2020-09-25 Thread Robert Munteanu (Jira)



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

Robert Munteanu commented on SLING-9767:


[~tomasz.k.niedzwi...@gmail.com] - since you added the documentation to the 
Sling web site, what are your thoughts on this?

> Insecure Recommendation in Dynamic Include Documentation
> 
>
> Key: SLING-9767
> URL: https://issues.apache.org/jira/browse/SLING-9767
> Project: Sling
>  Issue Type: Improvement
>  Components: Documentation
>Affects Versions: Dynamic Include 3.2.0
>Reporter: Lars Krapf
>Priority: Major
>
> The [documentation for the Sling Dynamic 
> Includes|https://sling.apache.org/documentation/bundles/dynamic-includes.html#enabling-ssi-in-apache-with-the-aem-dispatcher-module]
>  mentions the following:
> bq. Having added the SetOutputFilter directive, open the virtual host's 
> configuration and add the Includes option to the Options directive:
> This is an extremely unsafe recommendation. The "Includes" option will allow 
> anyone who can change content on the backend (e.g. AEM) to run arbitrary 
> commands on the webserver (dispatcher), by injecting the {{}} 
> directive.
> The recommendation should be to use the "IncludesNOEXEC" option instead, 
> which will only allow to include static content (with a "safe" mime-type such 
> as HTML or plain-text). 
> See also: http://httpd.apache.org/docs/current/mod/mod_include.html



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

[jira] [Updated] (SLING-9742) PubQueue#getEntry throws when provided an illegal arguments

2020-09-25 Thread Timothee Maret (Jira)



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

Timothee Maret updated SLING-9742:
--
Affects Version/s: (was: Content Distribution Core 0.4.2)
   Content Distribution Journal Core 0.1.0

> PubQueue#getEntry throws when provided an illegal arguments
> ---
>
> Key: SLING-9742
> URL: https://issues.apache.org/jira/browse/SLING-9742
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Journal Core 0.1.0
>Reporter: Dominik Süß
>Assignee: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Journal Core 0.1.18
>
>
> ExtendedDistributionServiceResourceProvider currently fails to render json in 
> case unexpected structures are mixed in (e.g. to provide resources to render 
> a corresponding UI).
> To replicate this issue access the queue via http:
> /libs/sling/distribution/services/agents/publish/queues/.json
> For the queueId use the queue id from the content-distribution UI (url below 
> only valid for AEM):
> /libs/granite/distribution/content/distribution-agent.html?agentName=publish
> This causes exceptions like this:
> {code:java}
> java.lang.IllegalArgumentException: Unsupported entryId format jcr:content
>   at 
> org.apache.sling.distribution.journal.impl.queue.impl.EntryUtil.entryOffset(EntryUtil.java:32)
>   at 
> org.apache.sling.distribution.journal.impl.queue.impl.PubQueue.getEntry(PubQueue.java:126)
>   at 
> org.apache.sling.distribution.resources.impl.ExtendedDistributionServiceResourceProvider.getQueueProperties(ExtendedDistributionServiceResourceProvider.java:180)
>   at 
> org.apache.sling.distribution.resources.impl.ExtendedDistributionServiceResourceProvider.getChildResourceProperties(ExtendedDistributionServiceResourceProvider.java:81)
>   at 
> org.apache.sling.distribution.resources.impl.DistributionServiceResourceProvider.getInternalResourceProperties(DistributionServiceResourceProvider.java:64)
>   at 
> org.apache.sling.distribution.resources.impl.common.AbstractReadableResourceProvider.getResourceProperties(AbstractReadableResourceProvider.java:175)
>   at 
> org.apache.sling.distribution.resources.impl.common.AbstractReadableResourceProvider.getResource(AbstractReadableResourceProvider.java:79)
>   at 
> org.apache.sling.distribution.resources.impl.DistributionServiceResourceProviderFactory.getResource(DistributionServiceResourceProviderFactory.java:99)
> {code}



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

[jira] [Resolved] (SLING-9742) PubQueue#getEntry throws when provided an illegal arguments

2020-09-25 Thread Timothee Maret (Jira)



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

Timothee Maret resolved SLING-9742.
---
Fix Version/s: Content Distribution Journal Core 0.1.18
   Resolution: Fixed

> PubQueue#getEntry throws when provided an illegal arguments
> ---
>
> Key: SLING-9742
> URL: https://issues.apache.org/jira/browse/SLING-9742
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.4.2
>Reporter: Dominik Süß
>Assignee: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Journal Core 0.1.18
>
>
> ExtendedDistributionServiceResourceProvider currently fails to render json in 
> case unexpected structures are mixed in (e.g. to provide resources to render 
> a corresponding UI).
> To replicate this issue access the queue via http:
> /libs/sling/distribution/services/agents/publish/queues/.json
> For the queueId use the queue id from the content-distribution UI (url below 
> only valid for AEM):
> /libs/granite/distribution/content/distribution-agent.html?agentName=publish
> This causes exceptions like this:
> {code:java}
> java.lang.IllegalArgumentException: Unsupported entryId format jcr:content
>   at 
> org.apache.sling.distribution.journal.impl.queue.impl.EntryUtil.entryOffset(EntryUtil.java:32)
>   at 
> org.apache.sling.distribution.journal.impl.queue.impl.PubQueue.getEntry(PubQueue.java:126)
>   at 
> org.apache.sling.distribution.resources.impl.ExtendedDistributionServiceResourceProvider.getQueueProperties(ExtendedDistributionServiceResourceProvider.java:180)
>   at 
> org.apache.sling.distribution.resources.impl.ExtendedDistributionServiceResourceProvider.getChildResourceProperties(ExtendedDistributionServiceResourceProvider.java:81)
>   at 
> org.apache.sling.distribution.resources.impl.DistributionServiceResourceProvider.getInternalResourceProperties(DistributionServiceResourceProvider.java:64)
>   at 
> org.apache.sling.distribution.resources.impl.common.AbstractReadableResourceProvider.getResourceProperties(AbstractReadableResourceProvider.java:175)
>   at 
> org.apache.sling.distribution.resources.impl.common.AbstractReadableResourceProvider.getResource(AbstractReadableResourceProvider.java:79)
>   at 
> org.apache.sling.distribution.resources.impl.DistributionServiceResourceProviderFactory.getResource(DistributionServiceResourceProviderFactory.java:99)
> {code}



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

[jira] [Commented] (SLING-9742) PubQueue#getEntry throws when provided an illegal arguments

2020-09-25 Thread Timothee Maret (Jira)



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

Timothee Maret commented on SLING-9742:
---

Fixed in 
[02846937fa0e07d183f50484bc68e028337c3fe5|https://github.com/apache/sling-org-apache-sling-distribution-journal/commit/02846937fa0e07d183f50484bc68e028337c3fe5].

> PubQueue#getEntry throws when provided an illegal arguments
> ---
>
> Key: SLING-9742
> URL: https://issues.apache.org/jira/browse/SLING-9742
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.4.2
>Reporter: Dominik Süß
>Assignee: Timothee Maret
>Priority: Major
>
> ExtendedDistributionServiceResourceProvider currently fails to render json in 
> case unexpected structures are mixed in (e.g. to provide resources to render 
> a corresponding UI).
> To replicate this issue access the queue via http:
> /libs/sling/distribution/services/agents/publish/queues/.json
> For the queueId use the queue id from the content-distribution UI (url below 
> only valid for AEM):
> /libs/granite/distribution/content/distribution-agent.html?agentName=publish
> This causes exceptions like this:
> {code:java}
> java.lang.IllegalArgumentException: Unsupported entryId format jcr:content
>   at 
> org.apache.sling.distribution.journal.impl.queue.impl.EntryUtil.entryOffset(EntryUtil.java:32)
>   at 
> org.apache.sling.distribution.journal.impl.queue.impl.PubQueue.getEntry(PubQueue.java:126)
>   at 
> org.apache.sling.distribution.resources.impl.ExtendedDistributionServiceResourceProvider.getQueueProperties(ExtendedDistributionServiceResourceProvider.java:180)
>   at 
> org.apache.sling.distribution.resources.impl.ExtendedDistributionServiceResourceProvider.getChildResourceProperties(ExtendedDistributionServiceResourceProvider.java:81)
>   at 
> org.apache.sling.distribution.resources.impl.DistributionServiceResourceProvider.getInternalResourceProperties(DistributionServiceResourceProvider.java:64)
>   at 
> org.apache.sling.distribution.resources.impl.common.AbstractReadableResourceProvider.getResourceProperties(AbstractReadableResourceProvider.java:175)
>   at 
> org.apache.sling.distribution.resources.impl.common.AbstractReadableResourceProvider.getResource(AbstractReadableResourceProvider.java:79)
>   at 
> org.apache.sling.distribution.resources.impl.DistributionServiceResourceProviderFactory.getResource(DistributionServiceResourceProviderFactory.java:99)
> {code}



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

[jira] [Updated] (SLING-9742) PubQueue#getEntry throws when providing an illegal arguments

2020-09-25 Thread Timothee Maret (Jira)



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

Timothee Maret updated SLING-9742:
--
Summary: PubQueue#getEntry throws when providing an illegal arguments  
(was: CLONE - DistributionPublisher does not validate queue names)

> PubQueue#getEntry throws when providing an illegal arguments
> 
>
> Key: SLING-9742
> URL: https://issues.apache.org/jira/browse/SLING-9742
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.4.2
>Reporter: Dominik Süß
>Assignee: Timothee Maret
>Priority: Major
>
> ExtendedDistributionServiceResourceProvider currently fails to render json in 
> case unexpected structures are mixed in (e.g. to provide resources to render 
> a corresponding UI).
> To replicate this issue access the queue via http:
> /libs/sling/distribution/services/agents/publish/queues/.json
> For the queueId use the queue id from the content-distribution UI (url below 
> only valid for AEM):
> /libs/granite/distribution/content/distribution-agent.html?agentName=publish
> This causes exceptions like this:
> {code:java}
> java.lang.IllegalArgumentException: Unsupported entryId format jcr:content
>   at 
> org.apache.sling.distribution.journal.impl.queue.impl.EntryUtil.entryOffset(EntryUtil.java:32)
>   at 
> org.apache.sling.distribution.journal.impl.queue.impl.PubQueue.getEntry(PubQueue.java:126)
>   at 
> org.apache.sling.distribution.resources.impl.ExtendedDistributionServiceResourceProvider.getQueueProperties(ExtendedDistributionServiceResourceProvider.java:180)
>   at 
> org.apache.sling.distribution.resources.impl.ExtendedDistributionServiceResourceProvider.getChildResourceProperties(ExtendedDistributionServiceResourceProvider.java:81)
>   at 
> org.apache.sling.distribution.resources.impl.DistributionServiceResourceProvider.getInternalResourceProperties(DistributionServiceResourceProvider.java:64)
>   at 
> org.apache.sling.distribution.resources.impl.common.AbstractReadableResourceProvider.getResourceProperties(AbstractReadableResourceProvider.java:175)
>   at 
> org.apache.sling.distribution.resources.impl.common.AbstractReadableResourceProvider.getResource(AbstractReadableResourceProvider.java:79)
>   at 
> org.apache.sling.distribution.resources.impl.DistributionServiceResourceProviderFactory.getResource(DistributionServiceResourceProviderFactory.java:99)
> {code}



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

[jira] [Updated] (SLING-9742) PubQueue#getEntry throws when provided an illegal arguments

2020-09-25 Thread Timothee Maret (Jira)



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

Timothee Maret updated SLING-9742:
--
Summary: PubQueue#getEntry throws when provided an illegal arguments  (was: 
PubQueue#getEntry throws when providing an illegal arguments)

> PubQueue#getEntry throws when provided an illegal arguments
> ---
>
> Key: SLING-9742
> URL: https://issues.apache.org/jira/browse/SLING-9742
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.4.2
>Reporter: Dominik Süß
>Assignee: Timothee Maret
>Priority: Major
>
> ExtendedDistributionServiceResourceProvider currently fails to render json in 
> case unexpected structures are mixed in (e.g. to provide resources to render 
> a corresponding UI).
> To replicate this issue access the queue via http:
> /libs/sling/distribution/services/agents/publish/queues/.json
> For the queueId use the queue id from the content-distribution UI (url below 
> only valid for AEM):
> /libs/granite/distribution/content/distribution-agent.html?agentName=publish
> This causes exceptions like this:
> {code:java}
> java.lang.IllegalArgumentException: Unsupported entryId format jcr:content
>   at 
> org.apache.sling.distribution.journal.impl.queue.impl.EntryUtil.entryOffset(EntryUtil.java:32)
>   at 
> org.apache.sling.distribution.journal.impl.queue.impl.PubQueue.getEntry(PubQueue.java:126)
>   at 
> org.apache.sling.distribution.resources.impl.ExtendedDistributionServiceResourceProvider.getQueueProperties(ExtendedDistributionServiceResourceProvider.java:180)
>   at 
> org.apache.sling.distribution.resources.impl.ExtendedDistributionServiceResourceProvider.getChildResourceProperties(ExtendedDistributionServiceResourceProvider.java:81)
>   at 
> org.apache.sling.distribution.resources.impl.DistributionServiceResourceProvider.getInternalResourceProperties(DistributionServiceResourceProvider.java:64)
>   at 
> org.apache.sling.distribution.resources.impl.common.AbstractReadableResourceProvider.getResourceProperties(AbstractReadableResourceProvider.java:175)
>   at 
> org.apache.sling.distribution.resources.impl.common.AbstractReadableResourceProvider.getResource(AbstractReadableResourceProvider.java:79)
>   at 
> org.apache.sling.distribution.resources.impl.DistributionServiceResourceProviderFactory.getResource(DistributionServiceResourceProviderFactory.java:99)
> {code}



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

Re: Virtual Round Table at adaptTo

2020-09-25 Thread Robert Munteanu

Hi,

I've sent an invite to everyone that has registered so far.

If you registered but did not get an invite please let me know.

Note that the meeting URL will prompt you to install/launch an app, but
there is a small 'Join with Browser' link at the bottom.

Thanks,
Robert

On Thu, 2020-09-10 at 15:56 +0200, Robert Munteanu wrote:
> Hi,
> 
> Since adaptTo is going virtual this year I propose that we go virtual
> for the round table as well. The alternative, of course, is that we
> don't hold the round table at all which would be a shame :-)
> 
> If you're interested, please see
> 
>   
> https://cwiki.apache.org/confluence/display/SLING/Virtual+Round+Table+-+28+September+2020
> 
> Thanks,
> Robert
>

[jira] [Commented] (SLING-9742) CLONE - DistributionPublisher does not validate queue names

2020-09-25 Thread Timothee Maret (Jira)



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

Timothee Maret commented on SLING-9742:
---

Dug deeper, the DistributionServiceResourceProviderFactory is actually relying 
on documented expectation which is violated by the SCD journal 
PubQueue#getEntry implementation. According to the 
[contract|https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/queue/spi/DistributionQueue.java#L75-L80],
 this method should return a null entry and currently throws.

> CLONE - DistributionPublisher does not validate queue names
> ---
>
> Key: SLING-9742
> URL: https://issues.apache.org/jira/browse/SLING-9742
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.4.2
>Reporter: Dominik Süß
>Assignee: Timothee Maret
>Priority: Major
>
> ExtendedDistributionServiceResourceProvider currently fails to render json in 
> case unexpected structures are mixed in (e.g. to provide resources to render 
> a corresponding UI).
> To replicate this issue access the queue via http:
> /libs/sling/distribution/services/agents/publish/queues/.json
> For the queueId use the queue id from the content-distribution UI (url below 
> only valid for AEM):
> /libs/granite/distribution/content/distribution-agent.html?agentName=publish
> This causes exceptions like this:
> {code:java}
> java.lang.IllegalArgumentException: Unsupported entryId format jcr:content
>   at 
> org.apache.sling.distribution.journal.impl.queue.impl.EntryUtil.entryOffset(EntryUtil.java:32)
>   at 
> org.apache.sling.distribution.journal.impl.queue.impl.PubQueue.getEntry(PubQueue.java:126)
>   at 
> org.apache.sling.distribution.resources.impl.ExtendedDistributionServiceResourceProvider.getQueueProperties(ExtendedDistributionServiceResourceProvider.java:180)
>   at 
> org.apache.sling.distribution.resources.impl.ExtendedDistributionServiceResourceProvider.getChildResourceProperties(ExtendedDistributionServiceResourceProvider.java:81)
>   at 
> org.apache.sling.distribution.resources.impl.DistributionServiceResourceProvider.getInternalResourceProperties(DistributionServiceResourceProvider.java:64)
>   at 
> org.apache.sling.distribution.resources.impl.common.AbstractReadableResourceProvider.getResourceProperties(AbstractReadableResourceProvider.java:175)
>   at 
> org.apache.sling.distribution.resources.impl.common.AbstractReadableResourceProvider.getResource(AbstractReadableResourceProvider.java:79)
>   at 
> org.apache.sling.distribution.resources.impl.DistributionServiceResourceProviderFactory.getResource(DistributionServiceResourceProviderFactory.java:99)
> {code}



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

[jira] [Commented] (SLING-9742) CLONE - DistributionPublisher does not validate queue names

2020-09-25 Thread Timothee Maret (Jira)



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

Timothee Maret commented on SLING-9742:
---

Thanks [~cschneider] and [~dsuess]. I could reproduce.

The Sling security 
[ContentDispositionFilter|https://github.com/apache/sling-org-apache-sling-security/blob/master/src/main/java/org/apache/sling/security/impl/ContentDispositionFilter.java#L278]
 does attempt to get a jcr:content child as part of setting the content 
disposition header.

According to the 
[doc|https://github.com/apache/sling-org-apache-sling-api/blob/master/src/main/java/org/apache/sling/api/resource/ResourceProvider.java#L121-L140],
 the ResourceProvider#getResource method must return null in case the required 
resource could not be found. The DistributionServiceResourceProviderFactory 
does deviate from this contract as it throws the exception that has been 
reported. It's a bug in the DistributionServiceResourceProviderFactory code.

 

> CLONE - DistributionPublisher does not validate queue names
> ---
>
> Key: SLING-9742
> URL: https://issues.apache.org/jira/browse/SLING-9742
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.4.2
>Reporter: Dominik Süß
>Assignee: Timothee Maret
>Priority: Major
>
> ExtendedDistributionServiceResourceProvider currently fails to render json in 
> case unexpected structures are mixed in (e.g. to provide resources to render 
> a corresponding UI).
> To replicate this issue access the queue via http:
> /libs/sling/distribution/services/agents/publish/queues/.json
> For the queueId use the queue id from the content-distribution UI (url below 
> only valid for AEM):
> /libs/granite/distribution/content/distribution-agent.html?agentName=publish
> This causes exceptions like this:
> {code:java}
> java.lang.IllegalArgumentException: Unsupported entryId format jcr:content
>   at 
> org.apache.sling.distribution.journal.impl.queue.impl.EntryUtil.entryOffset(EntryUtil.java:32)
>   at 
> org.apache.sling.distribution.journal.impl.queue.impl.PubQueue.getEntry(PubQueue.java:126)
>   at 
> org.apache.sling.distribution.resources.impl.ExtendedDistributionServiceResourceProvider.getQueueProperties(ExtendedDistributionServiceResourceProvider.java:180)
>   at 
> org.apache.sling.distribution.resources.impl.ExtendedDistributionServiceResourceProvider.getChildResourceProperties(ExtendedDistributionServiceResourceProvider.java:81)
>   at 
> org.apache.sling.distribution.resources.impl.DistributionServiceResourceProvider.getInternalResourceProperties(DistributionServiceResourceProvider.java:64)
>   at 
> org.apache.sling.distribution.resources.impl.common.AbstractReadableResourceProvider.getResourceProperties(AbstractReadableResourceProvider.java:175)
>   at 
> org.apache.sling.distribution.resources.impl.common.AbstractReadableResourceProvider.getResource(AbstractReadableResourceProvider.java:79)
>   at 
> org.apache.sling.distribution.resources.impl.DistributionServiceResourceProviderFactory.getResource(DistributionServiceResourceProviderFactory.java:99)
> {code}



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

[jira] [Created] (SLING-9767) Insecure Recommendation in Dynamic Include Documentation

2020-09-25 Thread Lars Krapf (Jira)

Lars Krapf created SLING-9767:
-

 Summary: Insecure Recommendation in Dynamic Include Documentation
 Key: SLING-9767
 URL: https://issues.apache.org/jira/browse/SLING-9767
 Project: Sling
  Issue Type: Improvement
  Components: Documentation
Affects Versions: Dynamic Include 3.2.0
Reporter: Lars Krapf


The [documentation for the Sling Dynamic 
Includes|https://sling.apache.org/documentation/bundles/dynamic-includes.html#enabling-ssi-in-apache-with-the-aem-dispatcher-module]
 mentions the following:

bq. Having added the SetOutputFilter directive, open the virtual host's 
configuration and add the Includes option to the Options directive:

This is an extremely unsafe recommendation. The "Includes" option will allow 
anyone who can change content on the backend (e.g. AEM) to run arbitrary 
commands on the webserver (dispatcher), by injecting the {{}} 
directive.
The recommendation should be to use the "IncludesNOEXEC" option instead, which 
will only allow to include static content (with a "safe" mime-type such as HTML 
or plain-text). 

See also: http://httpd.apache.org/docs/current/mod/mod_include.html



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

Re: [VOTE] Release Apache Sling API 2.23.0

2020-09-25 Thread Radu Cotescu

+1

> On 23 Sep 2020, at 20:58, Georg Henzler  wrote:
> 
> Please vote to approve this release:
> 
>   [ ] +1 Approve the release
>   [ ] -1 Don't release, because ...

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

42 matches

Mail list logo