[jira] [Commented] (SLING-5731) Export the org.mozilla.javascript.tools package in org.apache.sling.scripting.javascript bundle

[Rob Ryan (JIRA)]

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

Rob Ryan commented on SLING-5731:
-

I'm sorry I didn't keep a record, of what happens with a second export of Rhino.

[~olli]

> Export the org.mozilla.javascript.tools package in 
> org.apache.sling.scripting.javascript bundle
> ---
>
> Key: SLING-5731
> URL: https://issues.apache.org/jira/browse/SLING-5731
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Reporter: Tan Huynh
>Assignee: Oliver Lietz
> Attachments: sling-javascript.diff
>
>
> We would like to use the [handlebars template engine 
> |https://github.com/jknack/handlebars.java] in our Sling application.  This 
> bundle has a dependency on the [Rhino Javascript engine 
> |https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Rhino].  
> The two packages that the Handlebars bundle imports from the Rhino bundle are 
> * org.mozilla.javascript 
> * org.mozilla.javascript.tools. 
>  
> The Sling javascript bundle already exports the first package, it would be 
> great if it also exports the second package so that we won't have to deploy 
> the Rhino javascript bundle to be able to use handlebars.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (SLING-6561) Proposed test case for SLING-6271

[Rob Ryan (JIRA)]

Rob Ryan created SLING-6561:
---

 Summary: Proposed test case for SLING-6271
 Key: SLING-6561
 URL: https://issues.apache.org/jira/browse/SLING-6561
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Reporter: Rob Ryan
Priority: Minor
 Attachments: sling6271test.patch

Attached is a proposed unit test for the issue reported in SLING-6271.

In the case of setContentType being called before and after 
requestDispatcher.forward() each with the same content type SLING-6271 reported 
that the response ended up with no content type header.

The key aspect of forward() was that it calls reset() which clears all headers 
on the response.

The attached patch adds test cases for two scenarios around this: in case a 
content disposition header is also needed, or in case a content disposition 
header is not needed.




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (SLING-6296) DefaultThreadPool causes warning when minPoolSize == 0

[Rob Ryan (JIRA)]

Rob Ryan created SLING-6296:
---

 Summary: DefaultThreadPool causes warning when minPoolSize == 0
 Key: SLING-6296
 URL: https://issues.apache.org/jira/browse/SLING-6296
 Project: Sling
  Issue Type: Bug
  Components: Commons
Affects Versions: Commons Threads 3.2.6
Reporter: Rob Ryan


DefaultThreadPool inappropriately emits a warning when a pool has a min pool 
size of 0.

A min pool size of 0 is supported by the downstream ThreadExpiringThreadPool, 
and is logically useful when 'empty' is a reasonable size of a pool, e.g. when 
no work is apriori expected for the pool.
The code in question is:
 // Min pool size
if (this.configuration.getMinPoolSize() < 1) {
this.configuration.setMinPoolSize(1);
this.logger.warn("min-pool-size < 1 for pool \"" + this.name + "\". 
Set to 1");
}
The downstream code in ThreadExpiringThreadPool only enforces this value is >= 
0.



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

[jira] [Commented] (SLING-6271) ContentDispositionFilter can suppress content type upon request forwarding

[Rob Ryan (JIRA)]

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

Rob Ryan commented on SLING-6271:
-

[~asanso] Can you review these and let me know which approach you favor, and or 
commit whichever one that is :-) Thanks.

> ContentDispositionFilter can suppress content type upon request forwarding
> --
>
> Key: SLING-6271
> URL: https://issues.apache.org/jira/browse/SLING-6271
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Security 1.1.0
>Reporter: Rob Ryan
> Attachments: conservative.patch.txt, simple.patch.txt
>
>
> In SLING-4604 Alessandro Bonfatti noted a use case whereby a response would 
> contain no Content-Type header despite a similar non-forwarded request would 
> have a Content-Type. He further traced it to the ContentDispositionFilter and 
> the change where I introduced a shortcut in cases the same content type was 
> being set repeatedly.
> The scenario is:
> setContentType is called
> RequestDispatcher.forward is used to forward a request to a new servlet for 
> further handling. 
> setContentType is called.
> As of SLING-4604, the second setContentType call will be ignored if it sets 
> the same content type. But even if it *is* the same, setContentType needs to 
> be called again because request forwarding clears all headers with 
> response.reset().
> I will attach two patches, one (simple) very simple, and the best performing. 
> The other (conservative) is more complex, but should still perform adequately 
> and is conservative in the following senses:
> It will always call super.setContentType when its setContentType is invoked.
> On each setContentType it will re-apply the Content-Disposition header if 
> there is not one present and the 'attachment' value is called for by the 
> configuration.



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

[jira] [Updated] (SLING-6271) ContentDispositionFilter can suppress content type upon request forwarding

[Rob Ryan (JIRA)]

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

Rob Ryan updated SLING-6271:

Attachment: simple.patch.txt

> ContentDispositionFilter can suppress content type upon request forwarding
> --
>
> Key: SLING-6271
> URL: https://issues.apache.org/jira/browse/SLING-6271
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Security 1.1.0
>Reporter: Rob Ryan
> Attachments: conservative.patch.txt, simple.patch.txt
>
>
> In SLING-4604 Alessandro Bonfatti noted a use case whereby a response would 
> contain no Content-Type header despite a similar non-forwarded request would 
> have a Content-Type. He further traced it to the ContentDispositionFilter and 
> the change where I introduced a shortcut in cases the same content type was 
> being set repeatedly.
> The scenario is:
> setContentType is called
> RequestDispatcher.forward is used to forward a request to a new servlet for 
> further handling. 
> setContentType is called.
> As of SLING-4604, the second setContentType call will be ignored if it sets 
> the same content type. But even if it *is* the same, setContentType needs to 
> be called again because request forwarding clears all headers with 
> response.reset().
> I will attach two patches, one (simple) very simple, and the best performing. 
> The other (conservative) is more complex, but should still perform adequately 
> and is conservative in the following senses:
> It will always call super.setContentType when its setContentType is invoked.
> On each setContentType it will re-apply the Content-Disposition header if 
> there is not one present and the 'attachment' value is called for by the 
> configuration.



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

[jira] [Updated] (SLING-6271) ContentDispositionFilter can suppress content type upon request forwarding

[Rob Ryan (JIRA)]

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

Rob Ryan updated SLING-6271:

Attachment: conservative.patch.txt

> ContentDispositionFilter can suppress content type upon request forwarding
> --
>
> Key: SLING-6271
> URL: https://issues.apache.org/jira/browse/SLING-6271
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Security 1.1.0
>Reporter: Rob Ryan
> Attachments: conservative.patch.txt, simple.patch.txt
>
>
> In SLING-4604 Alessandro Bonfatti noted a use case whereby a response would 
> contain no Content-Type header despite a similar non-forwarded request would 
> have a Content-Type. He further traced it to the ContentDispositionFilter and 
> the change where I introduced a shortcut in cases the same content type was 
> being set repeatedly.
> The scenario is:
> setContentType is called
> RequestDispatcher.forward is used to forward a request to a new servlet for 
> further handling. 
> setContentType is called.
> As of SLING-4604, the second setContentType call will be ignored if it sets 
> the same content type. But even if it *is* the same, setContentType needs to 
> be called again because request forwarding clears all headers with 
> response.reset().
> I will attach two patches, one (simple) very simple, and the best performing. 
> The other (conservative) is more complex, but should still perform adequately 
> and is conservative in the following senses:
> It will always call super.setContentType when its setContentType is invoked.
> On each setContentType it will re-apply the Content-Disposition header if 
> there is not one present and the 'attachment' value is called for by the 
> configuration.



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

[jira] [Issue Comment Deleted] (SLING-6271) ContentDispositionFilter can suppress content type upon request forwarding

[Rob Ryan (JIRA)]

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

Rob Ryan updated SLING-6271:

Comment: was deleted

(was: conservative case.)

> ContentDispositionFilter can suppress content type upon request forwarding
> --
>
> Key: SLING-6271
> URL: https://issues.apache.org/jira/browse/SLING-6271
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Security 1.1.0
>Reporter: Rob Ryan
>
> In SLING-4604 Alessandro Bonfatti noted a use case whereby a response would 
> contain no Content-Type header despite a similar non-forwarded request would 
> have a Content-Type. He further traced it to the ContentDispositionFilter and 
> the change where I introduced a shortcut in cases the same content type was 
> being set repeatedly.
> The scenario is:
> setContentType is called
> RequestDispatcher.forward is used to forward a request to a new servlet for 
> further handling. 
> setContentType is called.
> As of SLING-4604, the second setContentType call will be ignored if it sets 
> the same content type. But even if it *is* the same, setContentType needs to 
> be called again because request forwarding clears all headers with 
> response.reset().
> I will attach two patches, one (simple) very simple, and the best performing. 
> The other (conservative) is more complex, but should still perform adequately 
> and is conservative in the following senses:
> It will always call super.setContentType when its setContentType is invoked.
> On each setContentType it will re-apply the Content-Disposition header if 
> there is not one present and the 'attachment' value is called for by the 
> configuration.



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

[jira] [Updated] (SLING-6271) ContentDispositionFilter can suppress content type upon request forwarding

[Rob Ryan (JIRA)]

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

Rob Ryan updated SLING-6271:

Attachment: (was: p1.txt)

> ContentDispositionFilter can suppress content type upon request forwarding
> --
>
> Key: SLING-6271
> URL: https://issues.apache.org/jira/browse/SLING-6271
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Security 1.1.0
>Reporter: Rob Ryan
>
> In SLING-4604 Alessandro Bonfatti noted a use case whereby a response would 
> contain no Content-Type header despite a similar non-forwarded request would 
> have a Content-Type. He further traced it to the ContentDispositionFilter and 
> the change where I introduced a shortcut in cases the same content type was 
> being set repeatedly.
> The scenario is:
> setContentType is called
> RequestDispatcher.forward is used to forward a request to a new servlet for 
> further handling. 
> setContentType is called.
> As of SLING-4604, the second setContentType call will be ignored if it sets 
> the same content type. But even if it *is* the same, setContentType needs to 
> be called again because request forwarding clears all headers with 
> response.reset().
> I will attach two patches, one (simple) very simple, and the best performing. 
> The other (conservative) is more complex, but should still perform adequately 
> and is conservative in the following senses:
> It will always call super.setContentType when its setContentType is invoked.
> On each setContentType it will re-apply the Content-Disposition header if 
> there is not one present and the 'attachment' value is called for by the 
> configuration.



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

[jira] [Updated] (SLING-6271) ContentDispositionFilter can suppress content type upon request forwarding

[Rob Ryan (JIRA)]

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

Rob Ryan updated SLING-6271:

Attachment: p1.txt

conservative case.

> ContentDispositionFilter can suppress content type upon request forwarding
> --
>
> Key: SLING-6271
> URL: https://issues.apache.org/jira/browse/SLING-6271
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Security 1.1.0
>Reporter: Rob Ryan
>
> In SLING-4604 Alessandro Bonfatti noted a use case whereby a response would 
> contain no Content-Type header despite a similar non-forwarded request would 
> have a Content-Type. He further traced it to the ContentDispositionFilter and 
> the change where I introduced a shortcut in cases the same content type was 
> being set repeatedly.
> The scenario is:
> setContentType is called
> RequestDispatcher.forward is used to forward a request to a new servlet for 
> further handling. 
> setContentType is called.
> As of SLING-4604, the second setContentType call will be ignored if it sets 
> the same content type. But even if it *is* the same, setContentType needs to 
> be called again because request forwarding clears all headers with 
> response.reset().
> I will attach two patches, one (simple) very simple, and the best performing. 
> The other (conservative) is more complex, but should still perform adequately 
> and is conservative in the following senses:
> It will always call super.setContentType when its setContentType is invoked.
> On each setContentType it will re-apply the Content-Disposition header if 
> there is not one present and the 'attachment' value is called for by the 
> configuration.



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

[jira] [Created] (SLING-6271) ContentDispositionFilter can suppress content type upon request forwarding

[Rob Ryan (JIRA)]

Rob Ryan created SLING-6271:
---

 Summary: ContentDispositionFilter can suppress content type upon 
request forwarding
 Key: SLING-6271
 URL: https://issues.apache.org/jira/browse/SLING-6271
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: Security 1.1.0
Reporter: Rob Ryan


In SLING-4604 Alessandro Bonfatti noted a use case whereby a response would 
contain no Content-Type header despite a similar non-forwarded request would 
have a Content-Type. He further traced it to the ContentDispositionFilter and 
the change where I introduced a shortcut in cases the same content type was 
being set repeatedly.

The scenario is:
setContentType is called
RequestDispatcher.forward is used to forward a request to a new servlet for 
further handling. 
setContentType is called.

As of SLING-4604, the second setContentType call will be ignored if it sets the 
same content type. But even if it *is* the same, setContentType needs to be 
called again because request forwarding clears all headers with 
response.reset().

I will attach two patches, one (simple) very simple, and the best performing. 
The other (conservative) is more complex, but should still perform adequately 
and is conservative in the following senses:
It will always call super.setContentType when its setContentType is invoked.
On each setContentType it will re-apply the Content-Disposition header if there 
is not one present and the 'attachment' value is called for by the 
configuration.




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

[jira] [Commented] (SLING-6257) Sling IDE: Debugging: Thread interrupted for every uncaught exception

[Rob Ryan (JIRA)]

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

Rob Ryan commented on SLING-6257:
-

It is unfortunate though that the thread pooling (in at least some part) of 
Sling uses exceptions for normal, even frequent cases.

> Sling IDE: Debugging: Thread interrupted for every uncaught exception
> -
>
> Key: SLING-6257
> URL: https://issues.apache.org/jira/browse/SLING-6257
> Project: Sling
>  Issue Type: Bug
>  Components: IDE
>Affects Versions: Sling Eclipse IDE 1.1.0
>Reporter: Konrad Windszus
>
> When I debug a local Sling server with the Sling IDE every uncaught exception 
> leads to a suspension of the affected thread (in Eclipse Neon). That is the 
> case even though no breakpoints are set in Eclipse (neither Exception 
> breakpoints, nor class nor method breakpoints).



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

[jira] [Commented] (SLING-4604) Multiple Content-Disposition headers added

[Rob Ryan (JIRA)]

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

Rob Ryan commented on SLING-4604:
-

Without more detail I can't really recommend adding the super.setContentType as 
I don't see any way that could actually help. Please feel free to contact me 
through Adobe channels so we can look at and discuss the details of the 
particular case.

Thanks.


> Multiple Content-Disposition headers added
> --
>
> Key: SLING-4604
> URL: https://issues.apache.org/jira/browse/SLING-4604
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Security 1.0.10
>Reporter: Rob Ryan
>Assignee: Antonio Sanso
> Fix For: Security 1.0.12
>
> Attachments: 4604patch.txt
>
>
> Multiple content-disposition headers can be added under some conditions.
> This seems to happen because setContentType is actually called more than once 
> for the same response when multiple sling scripts are involved in rendering, 
> e.g. via 
> org.apache.sling.scripting.core.impl.DefaultSlingScript.service(javax.servlet.ServletRequest,
>  javax.servlet.ServletResponse) line: 448



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

[jira] [Commented] (SLING-4604) Multiple Content-Disposition headers added

[Rob Ryan (JIRA)]

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

Rob Ryan commented on SLING-4604:
-

*If* content-type is being reset to the same value it has already been set to 
you are correct the downstream setContentType will not be called. Do you have a 
use case where that is problematic? Off hand I don't see how suppressing a set 
to the same value should have any logical impact. 

> Multiple Content-Disposition headers added
> --
>
> Key: SLING-4604
> URL: https://issues.apache.org/jira/browse/SLING-4604
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Security 1.0.10
>Reporter: Rob Ryan
>Assignee: Antonio Sanso
> Fix For: Security 1.0.12
>
> Attachments: 4604patch.txt
>
>
> Multiple content-disposition headers can be added under some conditions.
> This seems to happen because setContentType is actually called more than once 
> for the same response when multiple sling scripts are involved in rendering, 
> e.g. via 
> org.apache.sling.scripting.core.impl.DefaultSlingScript.service(javax.servlet.ServletRequest,
>  javax.servlet.ServletResponse) line: 448



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

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

[Rob Ryan (JIRA)]

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

Rob Ryan commented on SLING-6219:
-

The value in the password field is not *just* SHA-256 BTW, but a configurable 
number of passes through an algorithm which includes SHA-256. This algorithm is 
technically an implementation detail. This detail is already leaked somewhat in 
vault packages of users which includes the rep:password field. Personally I'd 
support moving that detail completely in the open as a specified behavior of 
Oak, but I'm not an Oak committer.

Since having these password hashes in repo init configurations is potentially 
less secure, it might be appropriate to allow only stronger configurations of 
the algorithm to be used, e.g. enforce a minimum number of hashes beyond the 
default. This would slow down attacks *and* real authentication using the 
credentials,  but it might be worth it.

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



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

[jira] [Commented] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors

[Rob Ryan (JIRA)]

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

Rob Ryan commented on SLING-6187:
-

Thanks, sorry my confusion.

> Provide a way for a POST request to assert a set of required 
> SlingPostProcessors
> 
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
>
> I would like to add support for a new "special" request parameter understood 
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter 
> may contain a comma-delimited list of names (see below) which *must* be 
> available *at the time the request is processed* in order for the request to 
> be handled. Whether or not those processors _do_ anything or whether the 
> request succeeds or not is a separate question; this is just a preflight 
> check if you will.
> If any of the required SlingPostProcessors are not available, the request 
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service 
> registration property {{postProcessor.name}} and default to the simple name 
> of the SlingPostProcessor's implementation class if that property is not 
> defined.



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

[jira] [Commented] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors

[Rob Ryan (JIRA)]

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

Rob Ryan commented on SLING-6187:
-

A single monolithic list is probably not the best thing here, maybe follow the 
service user style with 'amended' configurations to allow separate modules to 
specify required post processors.


> Provide a way for a POST request to assert a set of required 
> SlingPostProcessors
> 
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
>
> I would like to add support for a new "special" parameter understood by the 
> Sling Post Servlet named {{:requiredPostProcessors}}. This parameter may 
> contain a comma-delimited list of names (see below) which *must* be available 
> *at the time the request is processed* in order for the request to be 
> handled. Whether or not those processors _do_ anything or whether the request 
> succeeds or not is a separate question; this is just a preflight check if you 
> will.
> If any of the required SlingPostProcessors are not available, the request 
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service 
> registration property {{postProcessor.name}} and default to the simple name 
> of the SlingPostProcessor's implementation class if that property is not 
> defined.



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

Re: [context-aware config] performance impact of inhertiance

[Rob Ryan]

My experience is that looking up the ancestors of a node for property 
inheritance does indeed have a significant performance impact.

My experience was in the realm of:
https://docs.adobe.com/docs/en/cq/5-6-1/developing/cloud-service-configurations.html
https://docs.adobe.com/docs/en/cq/5-6-1/javadoc/com/day/cq/commons/inherit/InheritanceValueMap.html

I don’t have much more detail in any shareable form.

-Rob

On 10/10/16, 8:58 AM, "Stefan Seifert"  wrote:

one thought i had when implementing SLING-6059 and SLING-6058 (resource and 
property inheritance):

- currently both inheritance variants are switched off by default
- they can be switched on by setting a special inherit property in the 
configuration resource
- this property can either be set on the "inner-most" configuration 
resource matching the configuration path, or on anyone of the "outer" 
configuration levels up to the fallback path in /conf/global, /apps/conf, 
/libs/conf.
- thus it is possible to enable resource and/or property inheritance by 
default for specific configuration names and keep it disabled for others. and 
it is possible to "break inheritance" on any level if enabled globally.

all this flexible is not too complex to implement, but it comes at a cost: 
for each configuration resource the whole configuration inheritance hierarchy 
has to be searched for this special property if it is set to true. if yes, the 
inheritance takes place. checking for the property is a cheap operations, but 
still it leads to several additional resource accesses.

if we would remove the feature to allow this property to be set on any 
hierarchy level, and only check for it on the last/inner-most configuration 
level this it would be more performant to implement. but it would reduce the 
features (no inheritance for all lower levels, no breaking of inheritance), 
which would make it less flexible.

the problem is that even if the inheritance is never switched on anywhere, 
still all the whole inheritance tree has to be checked. do we think this is a 
performance problem?

stefan

[RHINO] SLING-5731: org.mozilla.javascript.tools (Rhino) package export

[Rob Ryan]

I'm hoping to attract  consideration of this JIRA issue 
(https://issues.apache.org/jira/browse/SLING-5731) in the near term.

In attempting to use serverside Handlebars templating 
(https://github.com/jknack/handlebars.java) we encountered the situation that 
Sling exports :

 org.mozilla.javascript;version=1.1.0,

But not:
org.mozilla.javascript.tools;version=1.1.0,

in:
bundles/scripting/javascript/pom.xml.

Jknack Handlebars.java requires the tools package.

Naturally other components in the system don't work properly if we try to 
provide another export of Rhino. In particular some Sightly components break if 
they don't get the Rhino engine that is properly configured for them.

Is it feasible to update the export list to include the tools package? A patch 
is attached to the bug.

Thanks for your attention in any case,
-Rob Ryan
Adobe Systems

Re: Resource.getParent() on NonExistingResource

[Rob Ryan]

Regardless of what other problem may exist; involving resolve() in
getParent() isn't a solution.

Resolve() operates on _URI_ paths. Not on resource paths. So proposing to
involve resolve() in an implementation of getParent() doesn't make sense.

Resolve() makes special considerations of some constructs:
_foo_bar to mean foo:bar. But a resource path could legitimately have
_foo_bar as a component.

/* : star resource handling


getParent() would likely be broken if it involved resolve() in such cases.


-Rob

On 6/10/16, 12:12 AM, "Konrad Windszus"  wrote:

>There is one related problem with mapping:
>
>Consider the case you have a resource resolver mapping from "/content/"
>to "/". In the underlying repository you have a resource in
>"/content/existingParent".
>
>Now it might happen that a NonExistingResource is resolved for path
>"/existingParent/nonExistingResource". Since this is pointing towards a
>non-existing resource the mapping is not active (i.e. the path will not
>contain "/content"). So you end up with a NonExistingResource with path
>"/existingParent/nonExistingResource".
>Now you call getParent() on this resource.
>
>You would expect to end up with an existing resource in
>"/content/existingParent" (because that path does exist in the
>repository). Unfortunately due to the logic in
>AbstractResource.getParent() this just calls ResourceResolver.getParent()
>which will not use ResourceResolver.resolve(...) but rather
>ResourceResolver.getResource(...) internally. So the mapping is not
>considered here. Therefore no resource is found at "/existingParent",
>although it does exist at "/content/existingParent".
>
>This is unexpected and wrong in my opinion. So the NonExistingResource
>should not rely on AbstractResource.getParent() at all, but rather use
>its own implementation relying on ResourceResolver.resolve(...). WDYT?
>
>Thanks,
>Konrad
>
>
>> On 02 Jun 2016, at 14:48, Konrad Windszus  wrote:
>> 
>> Thanks for the input.
>> I created https://issues.apache.org/jira/browse/SLING-5757 for tracking
>>that and I am going to propose a patch in there.
>> 
>> What about SyntheticResources which are not NonExistingResources? If we
>>would follow the same approach as for NonExistingResources the question
>>is, with which resource type the non-existing parent resource should be
>>created? Or should a SyntheticResource (which is not a
>>NonExistingResource) return a NonExistingResource for getParent()
>>instead in that case?
>> 
>> Konrad
>> 
>> 
>>> On 02 Jun 2016, at 13:47, Daniel Klco  wrote:
>>> 
>>> I would imagine that the only thing this would change is to make a
>>>small
>>> number of null checks irrelevant.
>>> 
>>> +1 for making the behavior more consistent, however, the JavaDocs and
>>> release notes should be explicit about this change.
>>> 
>>> On Thu, Jun 2, 2016 at 4:45 AM, Georg Henzler 
>>>wrote:
>>> 
 Hi Konrad,
 
 +1 for making the behaviour of NonExistingResource more consistent - I
 personally can't think of any places this would break existing code.
 
 Regards
 Georg
 
 
 
 On 2016-06-01 15:09, Konrad Windszus wrote:
 
> Hi Robert,
> thanks for your input.
> 
> 
>> I am not sure whether this would confuse existing clients though...
>> 
> 
> I am also a bit worried about that but the only example I could think
> of is a code trying to create the parent nodes or collecting the
> non-existing ones by checking getParent() for null.
> 
> This would be pretty bad style IMHO therefore I would deliberately be
> willing to break that code. I wonder what do others think about
> changing the semantics of getParent() for NonExistingResource and
> probably also SyntheticResource.
> Konrad
> 
 
 
>> 
>

[jira] [Commented] (SLING-5355) Create service users and ACLs from the provisioning model

[Rob Ryan (JIRA)]

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

Rob Ryan commented on SLING-5355:
-

Anyone who can change a config can make any or all users 'admin' anyway... Oak 
has an OSGI configuration listing which users are admin.



> Create service users and ACLs from the provisioning model
> -
>
> Key: SLING-5355
> URL: https://issues.apache.org/jira/browse/SLING-5355
> Project: Sling
>  Issue Type: New Feature
>  Components: Service User Mapper
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>
> As discussed in the "Removing loginAdministrative, how to test that, and 
> service username conventions" thread on our dev list [1] we need to be able 
> to create service users and set the corresponding ACLs from our provisioning 
> model.
> This should be implemented using distinct utility classes, one for the users 
> and one for the ACLs, that take simple mini-languages as input. This will 
> allow for reusing these utilities in test code for example.
> I have made a suggestion for those mini languages in that thread, will copy 
> them here once we agree.
> [1] http://markmail.org/message/kcvuhwfdald2dyuz
> *Edit: additional contraints*
> * Waiting for content paths: not all ACLs can be applied immediately when the 
> SlingRepository service starts: for this we'd need to create paths that don't 
> exist yet, and the nodetypes of those paths might not have been defined yet, 
> as any bundle can supply additional node types. This means waiting for the 
> path creation to succeed before proceeding, so we might as well wait for the 
> paths to be created by content installations



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

[jira] [Commented] (SLING-4883) Extend content disposition filter protection to jcr:data

[Rob Ryan (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14633760#comment-14633760
 ] 

Rob Ryan commented on SLING-4883:
-

Looks good to me, thanks!

 Extend content disposition filter protection to jcr:data
 

 Key: SLING-4883
 URL: https://issues.apache.org/jira/browse/SLING-4883
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Antonio Sanso
Assignee: Antonio Sanso
 Attachments: SLING-4883-patch.txt


 The current version of content disposition filter targets response content 
 type.
 It would be nice to have a feature to also target forcing download of 
 {{jcr:data}} under configured paths



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

[jira] [Commented] (SLING-3829) Add support for Content-Disposition attachment

[Rob Ryan (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14490309#comment-14490309
 ] 

Rob Ryan commented on SLING-3829:
-

[~asanso]  in thinking about this filter I don't think it's rejection of '*' to 
whitelist all mimetypes is appropriate. Given a subtree say /i/am/trusted with 
appropriate access controls one might wish to serve anything from it, *but* the 
same might not be said of /i/am/not/trusted...


 Add support for Content-Disposition attachment 
 ---

 Key: SLING-3829
 URL: https://issues.apache.org/jira/browse/SLING-3829
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Antonio Sanso
Assignee: Antonio Sanso
Priority: Minor
 Fix For: Security 1.0.10

 Attachments: ContentDispositionFilter.java, SLING-3829-patch.txt


 In some situation will be useful (and safer) to force Content-Disposition 
 attachment for some Content-Type (configurable ) under some specific (and 
 sensitive) path (configurable)



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

[jira] [Comment Edited] (SLING-3829) Add support for Content-Disposition attachment

[Rob Ryan (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14490309#comment-14490309
 ] 

Rob Ryan edited comment on SLING-3829 at 4/10/15 8:32 PM:
--

[~asanso]  in thinking about this filter I don't think it's rejection of *** to 
whitelist all mimetypes is appropriate. Given a subtree say /i/am/trusted with 
appropriate access controls one might wish to serve anything from it, *but* the 
same might not be said of /i/am/not/trusted...



was (Author: rr...@adobe.com):
[~asanso]  in thinking about this filter I don't think it's rejection of *'*'* 
to whitelist all mimetypes is appropriate. Given a subtree say /i/am/trusted 
with appropriate access controls one might wish to serve anything from it, 
*but* the same might not be said of /i/am/not/trusted...


 Add support for Content-Disposition attachment 
 ---

 Key: SLING-3829
 URL: https://issues.apache.org/jira/browse/SLING-3829
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Antonio Sanso
Assignee: Antonio Sanso
Priority: Minor
 Fix For: Security 1.0.10

 Attachments: ContentDispositionFilter.java, SLING-3829-patch.txt


 In some situation will be useful (and safer) to force Content-Disposition 
 attachment for some Content-Type (configurable ) under some specific (and 
 sensitive) path (configurable)



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

[jira] [Comment Edited] (SLING-3829) Add support for Content-Disposition attachment

[Rob Ryan (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14490309#comment-14490309
 ] 

Rob Ryan edited comment on SLING-3829 at 4/10/15 8:33 PM:
--

[~asanso]  in thinking about this filter I don't think it's rejection of 
asterisk to whitelist all mimetypes is appropriate. Given a subtree say 
/i/am/trusted with appropriate access controls one might wish to serve anything 
from it, *but* the same might not be said of /i/am/not/trusted...



was (Author: rr...@adobe.com):
[~asanso]  in thinking about this filter I don't think it's rejection of ** to 
whitelist all mimetypes is appropriate. Given a subtree say /i/am/trusted with 
appropriate access controls one might wish to serve anything from it, *but* the 
same might not be said of /i/am/not/trusted...


 Add support for Content-Disposition attachment 
 ---

 Key: SLING-3829
 URL: https://issues.apache.org/jira/browse/SLING-3829
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Antonio Sanso
Assignee: Antonio Sanso
Priority: Minor
 Fix For: Security 1.0.10

 Attachments: ContentDispositionFilter.java, SLING-3829-patch.txt


 In some situation will be useful (and safer) to force Content-Disposition 
 attachment for some Content-Type (configurable ) under some specific (and 
 sensitive) path (configurable)



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

[jira] [Comment Edited] (SLING-3829) Add support for Content-Disposition attachment

[Rob Ryan (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14490309#comment-14490309
 ] 

Rob Ryan edited comment on SLING-3829 at 4/10/15 8:32 PM:
--

[~asanso]  in thinking about this filter I don't think it's rejection of 'star' 
to whitelist all mimetypes is appropriate. Given a subtree say /i/am/trusted 
with appropriate access controls one might wish to serve anything from it, 
*but* the same might not be said of /i/am/not/trusted...



was (Author: rr...@adobe.com):
[~asanso]  in thinking about this filter I don't think it's rejection of '*' to 
whitelist all mimetypes is appropriate. Given a subtree say /i/am/trusted with 
appropriate access controls one might wish to serve anything from it, *but* the 
same might not be said of /i/am/not/trusted...


 Add support for Content-Disposition attachment 
 ---

 Key: SLING-3829
 URL: https://issues.apache.org/jira/browse/SLING-3829
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Antonio Sanso
Assignee: Antonio Sanso
Priority: Minor
 Fix For: Security 1.0.10

 Attachments: ContentDispositionFilter.java, SLING-3829-patch.txt


 In some situation will be useful (and safer) to force Content-Disposition 
 attachment for some Content-Type (configurable ) under some specific (and 
 sensitive) path (configurable)



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

[jira] [Comment Edited] (SLING-3829) Add support for Content-Disposition attachment

[Rob Ryan (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14490309#comment-14490309
 ] 

Rob Ryan edited comment on SLING-3829 at 4/10/15 8:32 PM:
--

[~asanso]  in thinking about this filter I don't think it's rejection of *'*'* 
to whitelist all mimetypes is appropriate. Given a subtree say /i/am/trusted 
with appropriate access controls one might wish to serve anything from it, 
*but* the same might not be said of /i/am/not/trusted...



was (Author: rr...@adobe.com):
[~asanso]  in thinking about this filter I don't think it's rejection of 'star' 
to whitelist all mimetypes is appropriate. Given a subtree say /i/am/trusted 
with appropriate access controls one might wish to serve anything from it, 
*but* the same might not be said of /i/am/not/trusted...


 Add support for Content-Disposition attachment 
 ---

 Key: SLING-3829
 URL: https://issues.apache.org/jira/browse/SLING-3829
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Antonio Sanso
Assignee: Antonio Sanso
Priority: Minor
 Fix For: Security 1.0.10

 Attachments: ContentDispositionFilter.java, SLING-3829-patch.txt


 In some situation will be useful (and safer) to force Content-Disposition 
 attachment for some Content-Type (configurable ) under some specific (and 
 sensitive) path (configurable)



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

[jira] [Comment Edited] (SLING-3829) Add support for Content-Disposition attachment

[Rob Ryan (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14490309#comment-14490309
 ] 

Rob Ryan edited comment on SLING-3829 at 4/10/15 8:32 PM:
--

[~asanso]  in thinking about this filter I don't think it's rejection of ** to 
whitelist all mimetypes is appropriate. Given a subtree say /i/am/trusted with 
appropriate access controls one might wish to serve anything from it, *but* the 
same might not be said of /i/am/not/trusted...



was (Author: rr...@adobe.com):
[~asanso]  in thinking about this filter I don't think it's rejection of *** to 
whitelist all mimetypes is appropriate. Given a subtree say /i/am/trusted with 
appropriate access controls one might wish to serve anything from it, *but* the 
same might not be said of /i/am/not/trusted...


 Add support for Content-Disposition attachment 
 ---

 Key: SLING-3829
 URL: https://issues.apache.org/jira/browse/SLING-3829
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Antonio Sanso
Assignee: Antonio Sanso
Priority: Minor
 Fix For: Security 1.0.10

 Attachments: ContentDispositionFilter.java, SLING-3829-patch.txt


 In some situation will be useful (and safer) to force Content-Disposition 
 attachment for some Content-Type (configurable ) under some specific (and 
 sensitive) path (configurable)



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

[jira] [Updated] (SLING-4604) Multiple Content-Disposition headers added

[Rob Ryan (JIRA)]

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

Rob Ryan updated SLING-4604:

Attachment: 4604patch.txt

the attached patch fixes the extra disposition headers and avoids running the 
bulk of the work if the content type is not changing from a previously seen 
value.

 Multiple Content-Disposition headers added
 --

 Key: SLING-4604
 URL: https://issues.apache.org/jira/browse/SLING-4604
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: Security 1.0.10
Reporter: Rob Ryan
 Attachments: 4604patch.txt


 Multiple content-disposition headers can be added under some conditions.
 This seems to happen because setContentType is actually called more than once 
 for the same response when multiple sling scripts are involved in rendering, 
 e.g. via 
 org.apache.sling.scripting.core.impl.DefaultSlingScript.service(javax.servlet.ServletRequest,
  javax.servlet.ServletResponse) line: 448



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

[jira] [Created] (SLING-4604) Multiple Content-Disposition headers added

[Rob Ryan (JIRA)]

Rob Ryan created SLING-4604:
---

 Summary: Multiple Content-Disposition headers added
 Key: SLING-4604
 URL: https://issues.apache.org/jira/browse/SLING-4604
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: Security 1.0.10
Reporter: Rob Ryan


Multiple content-disposition headers can be added under some conditions.

This seems to happen because setContentType is actually called more than once 
for the same response when multiple sling scripts are involved in rendering, 
e.g. via 
org.apache.sling.scripting.core.impl.DefaultSlingScript.service(javax.servlet.ServletRequest,
 javax.servlet.ServletResponse) line: 448  





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

RE: XSS protection path mangling issue: Bug or not?

[Rob Ryan]

Yes this is a bug IMO, please file an issue. The query string contents have no 
business influencing the spelling of the url path elements.

-Rob Ryan
Working for, but not speaking for Adobe.

-Original Message-
From: Georg Köster [mailto:m...@georgkoester.de] 
Sent: Thursday, March 19, 2015 7:51 AM
To: dev@sling.apache.org
Subject: XSS protection path mangling issue: Bug or not?

Hi all,

I stumbled over this behavior: Last part in path gets prepended with an 
underscore if there is a colon in the query string. Test appended, to be 
applied on  https://github.com/apache/sling/tree/196dea678c6010

Test output:

Failed tests:
  XSSAPIImplTest.testGetValidHref:267 Requested 
'/content/items/searchpages.html?0_tag:id=geo' 
expected:/content/items/[searchpages.html?0_tag%3a]id=geo but 
was:/content/items/[_searchpages.html?0_tag_]id=geo

Is this a bug? Should I create an issue ?

Cheers,

Georg

RE: [Sightly] provide access to the Script Resource Resolver in RenderContext

[Rob Ryan]

I share Felix's concern. If the ServletResolver's resolver is passed around, 
please ensure it is a service user with minimal permissions required for 
ServletResolver's needs. 

We do *not* want to allow a resolver passed around from the ServletResolver to 
be abused for accessing general content. If Slightly RuntimeExtensions need 
more access than the ServletResolver they should manage a resolver themselves.

Also, this sounds like premature optimization.

If ResourceResolver creation is slow the ROI on making it faster is likely 
significant as multi-thread usage of a session in Oak degrades performance 
rapidly.
-Rob


-Original Message-
From: Felix Meschberger [mailto:fmesc...@adobe.com] 
Sent: Friday, January 23, 2015 5:58 AM
To: dev@sling.apache.org
Subject: Re: [Sightly] provide access to the Script Resource Resolver in 
RenderContext

Hi

I am a bit hesitant with shipping ResourceResolver instances around. But since 
this is for an extension of the scripting language, this might make sense. We 
just have to properly document that this is not the request processing 
ResourceResolver but the ServletResolver’s ResourceResolver which is only 
intended to be used for script resolution tasks.

Regards
Felix

 Am 22.01.2015 um 14:21 schrieb Radu Cotescu r...@apache.org:
 
 Hi,
 
 There are cases when Sightly RuntimeExtensions might need to access 
 the repository. Since creating multiple ResourceResolvers is not a 
 cheap operation, especially with Jackrabbit, wouldn't it be better to 
 enhance the RenderContext to make it provide the ResourceResolver 
 available in the ScriptContext?
 
 This ResourceResolver is already used by the Sightly engine for script 
 rendering, so IMO it could also be passed down to RuntimeExtensions:
 
 final ResourceResolver scriptResourceResolver = (ResourceResolver) 
 scriptContext.getAttribute(SlingScriptConstants.ATTR_SCRIPT_RESOURCE_R
 ESOLVER, SlingScriptConstants.SLING_SCOPE); // line 78 of 
 org.apache.sling.scripting.sightly.impl.engine.SightlyScriptEngine
 
 WDYT?
 
 Cheers,
 Radu

[jira] [Commented] (SLING-3844) Resolver.map() spends too much time looking up sling:alias

[Rob Ryan (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14215114#comment-14215114
 ] 

Rob Ryan commented on SLING-3844:
-

Desired effect is achieved, no appreciable time is added to 'own' time or any 
other called methods, but the time for getProperty has been eliminated.


 Resolver.map() spends too much time looking up sling:alias
 --

 Key: SLING-3844
 URL: https://issues.apache.org/jira/browse/SLING-3844
 Project: Sling
  Issue Type: Improvement
  Components: ResourceResolver
Affects Versions: Resource Resolver 1.1.0
Reporter: Rob Ryan
Assignee: Antonio Sanso
  Labels: Performance
 Attachments: sling.resourceresolver.diff


 In a performance test expected to reflect reasonably real-world conditions 
 (50 concurrent users of a mixed load 'forum' type application) I found 
 Resolver.map taking more that 30% of the time used. This was tracked 
 primarily to checking each path element of the mapped path for sling:alias 
 properties to substitute into the result.
 In consultation with [~cziegeler] and [~asanso] I proceeded to implement the 
 inverse of Antonio's work on sling:alias for Resolver.resolve. The resulting 
 patch is attached. In our case the Resolver.map cost fell from 30% of time 
 used to 5%.
 If the resource.resolver.optimize.alias.resolution setting of the Apache 
 Sling Resource Resolver Factory is set to false then the patch fallback to 
 the original method of finding aliases. When the optimization is enabled the 
 aliases are looked up in hash maps maintained by observation and queries for 
 sling:alias along the same lines as Antonio's work.



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

[jira] [Updated] (SLING-3844) Resolver.map() spends too much time looking up sling:alias

[Rob Ryan (JIRA)]

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

Rob Ryan updated SLING-3844:

Attachment: post3844.csv

performance test after r1640141 applied

 Resolver.map() spends too much time looking up sling:alias
 --

 Key: SLING-3844
 URL: https://issues.apache.org/jira/browse/SLING-3844
 Project: Sling
  Issue Type: Improvement
  Components: ResourceResolver
Affects Versions: Resource Resolver 1.1.0
Reporter: Rob Ryan
Assignee: Antonio Sanso
  Labels: Performance
 Attachments: post3844.csv, pre3844.csv, sling.resourceresolver.diff


 In a performance test expected to reflect reasonably real-world conditions 
 (50 concurrent users of a mixed load 'forum' type application) I found 
 Resolver.map taking more that 30% of the time used. This was tracked 
 primarily to checking each path element of the mapped path for sling:alias 
 properties to substitute into the result.
 In consultation with [~cziegeler] and [~asanso] I proceeded to implement the 
 inverse of Antonio's work on sling:alias for Resolver.resolve. The resulting 
 patch is attached. In our case the Resolver.map cost fell from 30% of time 
 used to 5%.
 If the resource.resolver.optimize.alias.resolution setting of the Apache 
 Sling Resource Resolver Factory is set to false then the patch fallback to 
 the original method of finding aliases. When the optimization is enabled the 
 aliases are looked up in hash maps maintained by observation and queries for 
 sling:alias along the same lines as Antonio's work.



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

[jira] [Updated] (SLING-3844) Resolver.map() spends too much time looking up sling:alias

[Rob Ryan (JIRA)]

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

Rob Ryan updated SLING-3844:

Attachment: pre3844.csv

performance test before r1640141 was applied.


 Resolver.map() spends too much time looking up sling:alias
 --

 Key: SLING-3844
 URL: https://issues.apache.org/jira/browse/SLING-3844
 Project: Sling
  Issue Type: Improvement
  Components: ResourceResolver
Affects Versions: Resource Resolver 1.1.0
Reporter: Rob Ryan
Assignee: Antonio Sanso
  Labels: Performance
 Attachments: post3844.csv, pre3844.csv, sling.resourceresolver.diff


 In a performance test expected to reflect reasonably real-world conditions 
 (50 concurrent users of a mixed load 'forum' type application) I found 
 Resolver.map taking more that 30% of the time used. This was tracked 
 primarily to checking each path element of the mapped path for sling:alias 
 properties to substitute into the result.
 In consultation with [~cziegeler] and [~asanso] I proceeded to implement the 
 inverse of Antonio's work on sling:alias for Resolver.resolve. The resulting 
 patch is attached. In our case the Resolver.map cost fell from 30% of time 
 used to 5%.
 If the resource.resolver.optimize.alias.resolution setting of the Apache 
 Sling Resource Resolver Factory is set to false then the patch fallback to 
 the original method of finding aliases. When the optimization is enabled the 
 aliases are looked up in hash maps maintained by observation and queries for 
 sling:alias along the same lines as Antonio's work.



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

[jira] [Created] (SLING-4101) SlingAnnotationsTestRunner doesn't work with SlingRemoteExecutionRule

[Rob Ryan (JIRA)]

Rob Ryan created SLING-4101:
---

 Summary: SlingAnnotationsTestRunner doesn't work with 
SlingRemoteExecutionRule
 Key: SLING-4101
 URL: https://issues.apache.org/jira/browse/SLING-4101
 Project: Sling
  Issue Type: Bug
  Components: Testing
Affects Versions: JUnit Remote Tests Runners 1.0.8
Reporter: Rob Ryan


When SlingAnnotationsTestRunner is used together with SlingRemoteExecutionRule 
the test errors out with an NPE at:

org.apache.sling.junit.annotations.SlingAnnotationsTestRunner.createTest() 
line: 43 

It is expecting to run in an  OSGI environment  but e.g. when launching from 
Eclipse the test is not  connected to an OSGI environment.




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

[jira] [Updated] (SLING-2219) SlingAnnotationsTestRunner must use dynamic reference to AnnotationsProcessor

[Rob Ryan (JIRA)]

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

Rob Ryan updated SLING-2219:

Attachment: (was: SlingAnnotationsTestRunner.patch.txt)

 SlingAnnotationsTestRunner must use dynamic reference to AnnotationsProcessor
 -

 Key: SLING-2219
 URL: https://issues.apache.org/jira/browse/SLING-2219
 Project: Sling
  Issue Type: Bug
  Components: Testing
Affects Versions: JUnit Core 1.0.6
Reporter: Bertrand Delacretaz
Assignee: Bertrand Delacretaz
Priority: Minor
 Fix For: JUnit Core 1.0.8


 The SlingAnnotationsTestRunner's reference to the AnnotationsProcessor can 
 get out of sync if that component goes away, it should be more dynamic. 
 Performance is not really an issue, that's just for integration tests. 



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

[jira] [Issue Comment Deleted] (SLING-2219) SlingAnnotationsTestRunner must use dynamic reference to AnnotationsProcessor

[Rob Ryan (JIRA)]

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

Rob Ryan updated SLING-2219:

Comment: was deleted

(was: Proposed patch which allows SlingAnnotationsTestRunner to continue test 
execution outside of an OSGI environment. Allowing it to coexist with 
SlingRemoteExecutionRule.)

 SlingAnnotationsTestRunner must use dynamic reference to AnnotationsProcessor
 -

 Key: SLING-2219
 URL: https://issues.apache.org/jira/browse/SLING-2219
 Project: Sling
  Issue Type: Bug
  Components: Testing
Affects Versions: JUnit Core 1.0.6
Reporter: Bertrand Delacretaz
Assignee: Bertrand Delacretaz
Priority: Minor
 Fix For: JUnit Core 1.0.8


 The SlingAnnotationsTestRunner's reference to the AnnotationsProcessor can 
 get out of sync if that component goes away, it should be more dynamic. 
 Performance is not really an issue, that's just for integration tests. 



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

[jira] [Updated] (SLING-2219) SlingAnnotationsTestRunner must use dynamic reference to AnnotationsProcessor

[Rob Ryan (JIRA)]

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

Rob Ryan updated SLING-2219:

Attachment: SlingAnnotationsTestRunner.patch.txt

Proposed patch which allows SlingAnnotationsTestRunner to continue test 
execution outside of an OSGI environment. Allowing it to coexist with 
SlingRemoteExecutionRule.

 SlingAnnotationsTestRunner must use dynamic reference to AnnotationsProcessor
 -

 Key: SLING-2219
 URL: https://issues.apache.org/jira/browse/SLING-2219
 Project: Sling
  Issue Type: Bug
  Components: Testing
Affects Versions: JUnit Core 1.0.6
Reporter: Bertrand Delacretaz
Assignee: Bertrand Delacretaz
Priority: Minor
 Fix For: JUnit Core 1.0.8


 The SlingAnnotationsTestRunner's reference to the AnnotationsProcessor can 
 get out of sync if that component goes away, it should be more dynamic. 
 Performance is not really an issue, that's just for integration tests. 



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

[jira] [Updated] (SLING-4101) SlingAnnotationsTestRunner doesn't work with SlingRemoteExecutionRule

[Rob Ryan (JIRA)]

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

Rob Ryan updated SLING-4101:

Attachment: SlingAnnotationsTestRunner.patch.txt

Proposed patch which allows SlingAnnotationsTestRunner to continue test 
execution outside an OSGI environment, thus allowing it to coexist with 
SlingRemoteExecutionRule when launched from eclipse for example.

 SlingAnnotationsTestRunner doesn't work with SlingRemoteExecutionRule
 -

 Key: SLING-4101
 URL: https://issues.apache.org/jira/browse/SLING-4101
 Project: Sling
  Issue Type: Bug
  Components: Testing
Affects Versions: JUnit Remote Tests Runners 1.0.8
Reporter: Rob Ryan
 Attachments: SlingAnnotationsTestRunner.patch.txt


 When SlingAnnotationsTestRunner is used together with 
 SlingRemoteExecutionRule the test errors out with an NPE at:
 org.apache.sling.junit.annotations.SlingAnnotationsTestRunner.createTest() 
 line: 43   
 It is expecting to run in an  OSGI environment  but e.g. when launching from 
 Eclipse the test is not  connected to an OSGI environment.



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

[jira] [Commented] (SLING-3844) Resolver.map() spends too much time looking up sling:alias

[Rob Ryan (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14177271#comment-14177271
 ] 

Rob Ryan commented on SLING-3844:
-

[~asanso] I agree that in the typical case this will likely prove adequate.

But why set ourselves up for the potential pitfall of the multi-alias case 
(even it it is vanishingly rare)? As opposed to mirroring the existing 
datastructure in the inverse?

Anyway, I don't object to this so much as to veto it :-) even if I had a veto 
vote.

 Resolver.map() spends too much time looking up sling:alias
 --

 Key: SLING-3844
 URL: https://issues.apache.org/jira/browse/SLING-3844
 Project: Sling
  Issue Type: Improvement
  Components: ResourceResolver
Affects Versions: Resource Resolver 1.1.0
Reporter: Rob Ryan
Assignee: Antonio Sanso
  Labels: Performance
 Attachments: sling.resourceresolver.diff


 In a performance test expected to reflect reasonably real-world conditions 
 (50 concurrent users of a mixed load 'forum' type application) I found 
 Resolver.map taking more that 30% of the time used. This was tracked 
 primarily to checking each path element of the mapped path for sling:alias 
 properties to substitute into the result.
 In consultation with [~cziegeler] and [~asanso] I proceeded to implement the 
 inverse of Antonio's work on sling:alias for Resolver.resolve. The resulting 
 patch is attached. In our case the Resolver.map cost fell from 30% of time 
 used to 5%.
 If the resource.resolver.optimize.alias.resolution setting of the Apache 
 Sling Resource Resolver Factory is set to false then the patch fallback to 
 the original method of finding aliases. When the optimization is enabled the 
 aliases are looked up in hash maps maintained by observation and queries for 
 sling:alias along the same lines as Antonio's work.



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

[jira] [Commented] (SLING-3848) JcrNodeResource takes too long and initializes too much too soon

[Rob Ryan (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14109365#comment-14109365
 ] 

Rob Ryan commented on SLING-3848:
-

Thanks for all the work Carsten  Julian! Yes the changes look good.

 JcrNodeResource takes too long and initializes too much too soon
 

 Key: SLING-3848
 URL: https://issues.apache.org/jira/browse/SLING-3848
 Project: Sling
  Issue Type: Improvement
  Components: JCR
Reporter: Rob Ryan
Assignee: Carsten Ziegeler
 Fix For: JCR Resource 2.3.8, API 2.7.2

 Attachments: SLING-3848-jsedding.patch, sling.api.diff, 
 sling.jcr.resource.diff


 In a performance test expected to reflect reasonably real-world conditions 
 (50 concurrent users of a mixed load 'forum' type application) I found 
 org.apache.sling.jcr.resource.internal.helper.jcr.JcrNodeResource.JcrNodeResource(ResourceResolver,
  Node, ClassLoader) taking  more than 20% of time used. The majority of this 
 time was spent in setting the resource metadata and to a lesser extent the 
 resource type.
 Because the metadata especially is not often accessed and even the resource 
 type is not always accessed, delaying these initializations led to a 
 noticeable performance improvement.
 The attached patch delays resourcetype lookup and metadata lookups until 
 needed.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (SLING-3844) Resolver.map() spends too much time looking up sling:alias

[Rob Ryan (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102237#comment-14102237
 ] 

Rob Ryan commented on SLING-3844:
-

[~asanso] I don't follow the reverse mapping is critical to the performance 
improvement, no? Without a map reading from child names to child aliases the 
resolver.map() loop which replaces names in the path with their alias will 
revert to its old bad performance. Do you see another way?


 Resolver.map() spends too much time looking up sling:alias
 --

 Key: SLING-3844
 URL: https://issues.apache.org/jira/browse/SLING-3844
 Project: Sling
  Issue Type: Improvement
  Components: ResourceResolver
Affects Versions: Resource Resolver 1.1.0
Reporter: Rob Ryan
Assignee: Antonio Sanso
  Labels: Performance
 Attachments: sling.resourceresolver.diff


 In a performance test expected to reflect reasonably real-world conditions 
 (50 concurrent users of a mixed load 'forum' type application) I found 
 Resolver.map taking more that 30% of the time used. This was tracked 
 primarily to checking each path element of the mapped path for sling:alias 
 properties to substitute into the result.
 In consultation with [~cziegeler] and [~asanso] I proceeded to implement the 
 inverse of Antonio's work on sling:alias for Resolver.resolve. The resulting 
 patch is attached. In our case the Resolver.map cost fell from 30% of time 
 used to 5%.
 If the resource.resolver.optimize.alias.resolution setting of the Apache 
 Sling Resource Resolver Factory is set to false then the patch fallback to 
 the original method of finding aliases. When the optimization is enabled the 
 aliases are looked up in hash maps maintained by observation and queries for 
 sling:alias along the same lines as Antonio's work.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (SLING-3844) Resolver.map() spends too much time looking up sling:alias

[Rob Ryan (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102255#comment-14102255
 ] 

Rob Ryan commented on SLING-3844:
-

Please take the patch with the reverse mapping in place.

 Resolver.map() spends too much time looking up sling:alias
 --

 Key: SLING-3844
 URL: https://issues.apache.org/jira/browse/SLING-3844
 Project: Sling
  Issue Type: Improvement
  Components: ResourceResolver
Affects Versions: Resource Resolver 1.1.0
Reporter: Rob Ryan
Assignee: Antonio Sanso
  Labels: Performance
 Attachments: sling.resourceresolver.diff


 In a performance test expected to reflect reasonably real-world conditions 
 (50 concurrent users of a mixed load 'forum' type application) I found 
 Resolver.map taking more that 30% of the time used. This was tracked 
 primarily to checking each path element of the mapped path for sling:alias 
 properties to substitute into the result.
 In consultation with [~cziegeler] and [~asanso] I proceeded to implement the 
 inverse of Antonio's work on sling:alias for Resolver.resolve. The resulting 
 patch is attached. In our case the Resolver.map cost fell from 30% of time 
 used to 5%.
 If the resource.resolver.optimize.alias.resolution setting of the Apache 
 Sling Resource Resolver Factory is set to false then the patch fallback to 
 the original method of finding aliases. When the optimization is enabled the 
 aliases are looked up in hash maps maintained by observation and queries for 
 sling:alias along the same lines as Antonio's work.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (SLING-3844) Resolver.map() spends too much time looking up sling:alias

[Rob Ryan (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102254#comment-14102254
 ] 

Rob Ryan commented on SLING-3844:
-

See my updated comment above. There is no way without the reverse mapping I can 
see. The key is that we need cheap name to alias mapping for the map() method 
to maintain its existing contract but improve performance.


 Resolver.map() spends too much time looking up sling:alias
 --

 Key: SLING-3844
 URL: https://issues.apache.org/jira/browse/SLING-3844
 Project: Sling
  Issue Type: Improvement
  Components: ResourceResolver
Affects Versions: Resource Resolver 1.1.0
Reporter: Rob Ryan
Assignee: Antonio Sanso
  Labels: Performance
 Attachments: sling.resourceresolver.diff


 In a performance test expected to reflect reasonably real-world conditions 
 (50 concurrent users of a mixed load 'forum' type application) I found 
 Resolver.map taking more that 30% of the time used. This was tracked 
 primarily to checking each path element of the mapped path for sling:alias 
 properties to substitute into the result.
 In consultation with [~cziegeler] and [~asanso] I proceeded to implement the 
 inverse of Antonio's work on sling:alias for Resolver.resolve. The resulting 
 patch is attached. In our case the Resolver.map cost fell from 30% of time 
 used to 5%.
 If the resource.resolver.optimize.alias.resolution setting of the Apache 
 Sling Resource Resolver Factory is set to false then the patch fallback to 
 the original method of finding aliases. When the optimization is enabled the 
 aliases are looked up in hash maps maintained by observation and queries for 
 sling:alias along the same lines as Antonio's work.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (SLING-3844) Resolver.map() spends too much time looking up sling:alias

[Rob Ryan (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102237#comment-14102237
 ] 

Rob Ryan edited comment on SLING-3844 at 8/19/14 2:43 PM:
--

[~asanso] I don't follow. The reverse mapping is critical to the performance 
improvement, no? Without a map reading from child names to child aliases the 
resolver.map() loop which replaces names in the path with their alias will 
revert to its old bad performance. Do you see another way?

The bad performance comes from two factors: creating a resource for each 
element of the path being mapped and the actual lookup of the sling:alias 
property in that resource.


was (Author: rr...@adobe.com):
[~asanso] I don't follow the reverse mapping is critical to the performance 
improvement, no? Without a map reading from child names to child aliases the 
resolver.map() loop which replaces names in the path with their alias will 
revert to its old bad performance. Do you see another way?


 Resolver.map() spends too much time looking up sling:alias
 --

 Key: SLING-3844
 URL: https://issues.apache.org/jira/browse/SLING-3844
 Project: Sling
  Issue Type: Improvement
  Components: ResourceResolver
Affects Versions: Resource Resolver 1.1.0
Reporter: Rob Ryan
Assignee: Antonio Sanso
  Labels: Performance
 Attachments: sling.resourceresolver.diff


 In a performance test expected to reflect reasonably real-world conditions 
 (50 concurrent users of a mixed load 'forum' type application) I found 
 Resolver.map taking more that 30% of the time used. This was tracked 
 primarily to checking each path element of the mapped path for sling:alias 
 properties to substitute into the result.
 In consultation with [~cziegeler] and [~asanso] I proceeded to implement the 
 inverse of Antonio's work on sling:alias for Resolver.resolve. The resulting 
 patch is attached. In our case the Resolver.map cost fell from 30% of time 
 used to 5%.
 If the resource.resolver.optimize.alias.resolution setting of the Apache 
 Sling Resource Resolver Factory is set to false then the patch fallback to 
 the original method of finding aliases. When the optimization is enabled the 
 aliases are looked up in hash maps maintained by observation and queries for 
 sling:alias along the same lines as Antonio's work.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (SLING-3848) JcrNodeResource takes too long and initializes too much too soon

[Rob Ryan (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14101298#comment-14101298
 ] 

Rob Ryan commented on SLING-3848:
-

[~cziegeler] Thanks for the quick action.

WRT your comment about 99 % of cases resourceType always being needed was 
contradicted by my experience. Consider Resolver.map() where  each path up to 
the root would be resolvedwhen all it needed from each level was the 
sling:alias. In that case resourceType was irrelevant and in our use case 
Resolver,map() was consuming significant CPU due to that loop.  There is a 
separate fix for that leveraging [~asanso]'s work on vanity paths and aliases, 
but his work has to be disabled if there any many aliases or vanity paths... 
That wasn't the only place experiencing the cost of instantiating resources, 
but it is suggestive that there may be other places where resources are created 
when only limited data is needed. Bear in mind that our use case is *not* 
primarily sling render driven.

it take me awhile to get to it, but I'll re-verify.  I expect to find that the 
initialization of resourceType in the constructor will show to have a 
noticeable impact. I'll check also whether delayed initialization is 
significantly different than Felix's optimization.

 JcrNodeResource takes too long and initializes too much too soon
 

 Key: SLING-3848
 URL: https://issues.apache.org/jira/browse/SLING-3848
 Project: Sling
  Issue Type: Improvement
  Components: JCR
Reporter: Rob Ryan
Assignee: Carsten Ziegeler
 Fix For: JCR Resource 2.3.8, API 2.7.2

 Attachments: sling.api.diff, sling.jcr.resource.diff


 In a performance test expected to reflect reasonably real-world conditions 
 (50 concurrent users of a mixed load 'forum' type application) I found 
 org.apache.sling.jcr.resource.internal.helper.jcr.JcrNodeResource.JcrNodeResource(ResourceResolver,
  Node, ClassLoader) taking  more than 20% of time used. The majority of this 
 time was spent in setting the resource metadata and to a lesser extent the 
 resource type.
 Because the metadata especially is not often accessed and even the resource 
 type is not always accessed, delaying these initializations led to a 
 noticeable performance improvement.
 The attached patch delays resourcetype lookup and metadata lookups until 
 needed.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (SLING-3844) Resolver.map() spends too much time looking up sling:alias

[Rob Ryan (JIRA)]

Rob Ryan created SLING-3844:
---

 Summary: Resolver.map() spends too much time looking up sling:alias
 Key: SLING-3844
 URL: https://issues.apache.org/jira/browse/SLING-3844
 Project: Sling
  Issue Type: Improvement
  Components: ResourceResolver
Affects Versions: Resource Resolver 1.1.0
Reporter: Rob Ryan


In a performance test expected to reflect reasonably real-world conditions (50 
concurrent users of a mixed load 'forum' type application) I found Resolver.map 
taking more that 30% of the time used. This was tracked primarily to checking 
each path element of the mapped path for sling:alias properties to substitute 
into the result.

In consultation with [~cziegeler] and [~asanso] I proceeded to implement the 
inverse of Antonio's work on sling:alias for Resolver.resolve. The resulting 
patch is attached. In our case the Resolver.map cost fell from 30% of time used 
to 5%.

If the resource.resolver.optimize.alias.resolution setting of the Apache Sling 
Resource Resolver Factory is set to false then the patch fallback to the 
original method of finding aliases. When the optimization is enabled the 
aliases are looked up in hash maps maintained by observation and queries for 
sling:alias along the same lines as Antonio's work.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (SLING-3844) Resolver.map() spends too much time looking up sling:alias

[Rob Ryan (JIRA)]

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

Rob Ryan updated SLING-3844:


Attachment: sling.resourceresolver.diff

This patch implements optimization of Resolver.map by looking up sling:alias 
properties from maps maintained by MappingEntries.java.

 Resolver.map() spends too much time looking up sling:alias
 --

 Key: SLING-3844
 URL: https://issues.apache.org/jira/browse/SLING-3844
 Project: Sling
  Issue Type: Improvement
  Components: ResourceResolver
Affects Versions: Resource Resolver 1.1.0
Reporter: Rob Ryan
 Attachments: sling.resourceresolver.diff


 In a performance test expected to reflect reasonably real-world conditions 
 (50 concurrent users of a mixed load 'forum' type application) I found 
 Resolver.map taking more that 30% of the time used. This was tracked 
 primarily to checking each path element of the mapped path for sling:alias 
 properties to substitute into the result.
 In consultation with [~cziegeler] and [~asanso] I proceeded to implement the 
 inverse of Antonio's work on sling:alias for Resolver.resolve. The resulting 
 patch is attached. In our case the Resolver.map cost fell from 30% of time 
 used to 5%.
 If the resource.resolver.optimize.alias.resolution setting of the Apache 
 Sling Resource Resolver Factory is set to false then the patch fallback to 
 the original method of finding aliases. When the optimization is enabled the 
 aliases are looked up in hash maps maintained by observation and queries for 
 sling:alias along the same lines as Antonio's work.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (SLING-3844) Resolver.map() spends too much time looking up sling:alias

[Rob Ryan (JIRA)]

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

Rob Ryan updated SLING-3844:


Labels: Performance  (was: )

 Resolver.map() spends too much time looking up sling:alias
 --

 Key: SLING-3844
 URL: https://issues.apache.org/jira/browse/SLING-3844
 Project: Sling
  Issue Type: Improvement
  Components: ResourceResolver
Affects Versions: Resource Resolver 1.1.0
Reporter: Rob Ryan
  Labels: Performance
 Attachments: sling.resourceresolver.diff


 In a performance test expected to reflect reasonably real-world conditions 
 (50 concurrent users of a mixed load 'forum' type application) I found 
 Resolver.map taking more that 30% of the time used. This was tracked 
 primarily to checking each path element of the mapped path for sling:alias 
 properties to substitute into the result.
 In consultation with [~cziegeler] and [~asanso] I proceeded to implement the 
 inverse of Antonio's work on sling:alias for Resolver.resolve. The resulting 
 patch is attached. In our case the Resolver.map cost fell from 30% of time 
 used to 5%.
 If the resource.resolver.optimize.alias.resolution setting of the Apache 
 Sling Resource Resolver Factory is set to false then the patch fallback to 
 the original method of finding aliases. When the optimization is enabled the 
 aliases are looked up in hash maps maintained by observation and queries for 
 sling:alias along the same lines as Antonio's work.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (SLING-3848) JcrNodeResource takes too long and initializes too much too soon

[Rob Ryan (JIRA)]

Rob Ryan created SLING-3848:
---

 Summary: JcrNodeResource takes too long and initializes too much 
too soon
 Key: SLING-3848
 URL: https://issues.apache.org/jira/browse/SLING-3848
 Project: Sling
  Issue Type: Improvement
  Components: JCR
Reporter: Rob Ryan


In a performance test expected to reflect reasonably real-world conditions (50 
concurrent users of a mixed load 'forum' type application) I found 
org.apache.sling.jcr.resource.internal.helper.jcr.JcrNodeResource.JcrNodeResource(ResourceResolver,
 Node, ClassLoader) taking  more than 20% of time used. The majority of this 
time was spent in setting the resource metadata and to a lesser extent the 
resource type.

Because the metadata especially is not often accessed and even the resource 
type is not always accessed, delaying these initializations led to a noticeable 
performance improvement.

The attached patch delays resourcetype lookup and metadata lookups until needed.





--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (SLING-3848) JcrNodeResource takes too long and initializes too much too soon

[Rob Ryan (JIRA)]

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

Rob Ryan updated SLING-3848:


Attachment: sling.api.diff

This patch introduces a new protected method in the ResourceMetaData class so 
that subclasses can introduce values into the map as they are accessed.

 JcrNodeResource takes too long and initializes too much too soon
 

 Key: SLING-3848
 URL: https://issues.apache.org/jira/browse/SLING-3848
 Project: Sling
  Issue Type: Improvement
  Components: JCR
Reporter: Rob Ryan
 Attachments: sling.api.diff


 In a performance test expected to reflect reasonably real-world conditions 
 (50 concurrent users of a mixed load 'forum' type application) I found 
 org.apache.sling.jcr.resource.internal.helper.jcr.JcrNodeResource.JcrNodeResource(ResourceResolver,
  Node, ClassLoader) taking  more than 20% of time used. The majority of this 
 time was spent in setting the resource metadata and to a lesser extent the 
 resource type.
 Because the metadata especially is not often accessed and even the resource 
 type is not always accessed, delaying these initializations led to a 
 noticeable performance improvement.
 The attached patch delays resourcetype lookup and metadata lookups until 
 needed.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (SLING-3848) JcrNodeResource takes too long and initializes too much too soon

[Rob Ryan (JIRA)]

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

Rob Ryan updated SLING-3848:


Attachment: sling.jcr.resource.diff

This patch builds upon the sling.api.diff patch to offer delayed population of 
the resource metadata and the resourceType.

 JcrNodeResource takes too long and initializes too much too soon
 

 Key: SLING-3848
 URL: https://issues.apache.org/jira/browse/SLING-3848
 Project: Sling
  Issue Type: Improvement
  Components: JCR
Reporter: Rob Ryan
 Attachments: sling.api.diff, sling.jcr.resource.diff


 In a performance test expected to reflect reasonably real-world conditions 
 (50 concurrent users of a mixed load 'forum' type application) I found 
 org.apache.sling.jcr.resource.internal.helper.jcr.JcrNodeResource.JcrNodeResource(ResourceResolver,
  Node, ClassLoader) taking  more than 20% of time used. The majority of this 
 time was spent in setting the resource metadata and to a lesser extent the 
 resource type.
 Because the metadata especially is not often accessed and even the resource 
 type is not always accessed, delaying these initializations led to a 
 noticeable performance improvement.
 The attached patch delays resourcetype lookup and metadata lookups until 
 needed.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

RE: Support REST-ful APIs

[Rob Ryan]

Felix Meschberger wrote:
* Extension (and optional selectors) have not derived from the URL yet

One of the lessons I think I see from how selectors  extensions are working in 
the face of creation requests to non-existent resources is that there should be 
a way to *override* what is derived from the existing resolution process. 
Consider that some URLs end up containing period characters which have nothing 
to do with a desire for a selector or extension, a prominent example is user 
ids.

-Rob Ryan


-Original Message-
From: Felix Meschberger [mailto:fmesc...@adobe.com] 
Sent: Monday, April 07, 2014 12:25 AM
To: dev@sling.apache.org
Subject: Support REST-ful APIs

Hi all

TL;DR: Use Accept header to set request's selectors and extension. So an 
example Accept content type of application/x-players+json would set the 
selector string to players and the extension to json.

We always touted Sling to be a platform for REST-ful web applications. But we 
cheated a bit in that we invented request selectors and extensions for 
content negotiation instead of using the HTTP Accept header. The reason for 
this cheating was pure pragmatism since in Browsers the easy way to influence 
requests is basically just URLs and request parameters.

Hence we built all request processing, prominently script/servlet selection on 
these selectors and extensions. And this proved highly effective.

Still, trying to define pure REST-ful APIs we can assume applications to be 
able to set the HTTP Accept header and to be able to define clean URLs without 
selectors and extensions.

So for a browser we want to support something like:

 GET /teams/fcbasel.html HTTP/1.0
 Host: soccer.example.com

while for REST-ful APIs more something like:

 GET /teams/fcbasel HTTP/1.0
 Host: soccer.example.com
 Accept: application/x-players+json

What if Sling would convert the Accept content type 
application/x-players+json into

 selectors = [ players ]
 selectorString = players
 extension = json

This could be done in the Sling Engine's SlingRequestPathInfo constructor under 
the following conditions:

* Extension (and optional selectors) have not derived from the URL yet
* Accept header has a single content type (Browsers generally send a list of 
supported types)
* Accept header is an application type
* The sub type is converted to selector and extensions, where + is used as 
the separator

WDYT ?

Regards
Felix

[jira] [Commented] (SLING-3203) Post servlet's delete operation deletes parent of nonexisting node

[Rob Ryan (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949279#comment-13949279
 ] 

Rob Ryan commented on SLING-3203:
-

In the case an :applyTo is provided isn't this check too draconian?

Forbidding selectors on the sling post servlet ignores that filters and 
security checks might wish to use selectors to enforce security in front of the 
sling post servlet.

 Post servlet's delete operation deletes parent of nonexisting node
 --

 Key: SLING-3203
 URL: https://issues.apache.org/jira/browse/SLING-3203
 Project: Sling
  Issue Type: Bug
  Components: Servlets
Affects Versions: Servlets Post 2.3.2
Reporter: Bertrand Delacretaz
Assignee: Bertrand Delacretaz
 Fix For: Servlets Post 2.3.4

 Attachments: SLING-3203.patch


 In the below scenario, /tmp/test is gone after the delete operation - the 
 resource resolver goes up the path of the nonexisting node, and it's 
 /tmp/test that's provided to the DeleteOperation.
 I think we should change this (maybe with a backwards compatibility switch), 
 as it's clear that the user's intention in this case is not to delete 
 /tmp/test. Maybe just reject :delete operations if the request has any 
 selector or extensions.
 curl -u admin:admin -X POST http://localhost:8080/tmp/test/some.node
 curl -u admin:admin http://localhost:8080/tmp/test.tidy.2.json # looks good
 curl -u admin:admin -F:operation=delete 
 http://localhost:8080/tmp/test.other/nothing
 curl -u admin:admin http://localhost:8080/tmp/test.tidy.2.json # 404



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (SLING-2881) [I18N][Performance] JcrResourceBundleProvider clears the cache on mix:language changes

[Rob Ryan (JIRA)]

Rob Ryan created SLING-2881:
---

 Summary: [I18N][Performance] JcrResourceBundleProvider clears the 
cache on mix:language changes
 Key: SLING-2881
 URL: https://issues.apache.org/jira/browse/SLING-2881
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: i18n 2.2.4
 Environment: CQ5.6
Reporter: Rob Ryan


Performance of an appplication using Sling i18n JcrResourceBundleProvider 
suffers drastically if nodes with mixin type mix:language are modified 
frequently.

The reason for the performance degradation is that JcrResourceBundleProvider 
registers a JCR event listener for node types: mix:language and sling:Message. 
It then clears the i18n resource bundle cache whenever a node with these types 
appears in an event.

The JCR 2.0 spec indicates applications should use a mix:language type as the 
standard way to provide a property specifying the natural language which the 
content of a  node is expressed.

Therefore clearing the resource bundle cache on a change to *any* node with a 
mix:language type is inappropriately broad.



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira