[jira] [Commented] (SLING-5638) Sling:alias property not working if user does not have read access to the root node

[Antonio Sanso (JIRA)]

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

Antonio Sanso commented on SLING-5638:
--

documented limitation in r1739790

> Sling:alias property not working if user does not have read access to the 
> root node
> ---
>
> Key: SLING-5638
> URL: https://issues.apache.org/jira/browse/SLING-5638
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Reporter: Antonio Sanso
>Assignee: Antonio Sanso
> Fix For: Resource Resolver 1.5.0
>
> Attachments: SLING-5638-patch.txt
>
>
> issue ;- Sling:alias property not working if user is having read only access 
> to /content folder.
> Steps :-
> 1) Login using admin/admin.
> 2) Create page say mypage.html and provide sling:alias property say 
> mypagealias.
> 3) Create test user and provide read only access on /content folder from 
> useradmin console.
> 4) log out from admin user.
> 5) Hit the page http://localhost:4502/content//mypage.html it 
> will ask for the login ( login as test user ) it opens the page
> 6) hit the alias page 
> http://localhost:4502/content//mypagealias.html - it wont work.
> sling:alias property get stored at jcr:content node for the page in /content, 
> so user with read access on /content should access it. please correct me in 
> case I am missing something.
> to make it work user has to give root( read only ) access to test user only 
> then test user can access alias page. 



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

[jira] [Resolved] (SLING-5638) Sling:alias property not working if user does not have read access to the root node

[Antonio Sanso (JIRA)]

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

Antonio Sanso resolved SLING-5638.
--
   Resolution: Fixed
Fix Version/s: Resource Resolver 1.5.0

> Sling:alias property not working if user does not have read access to the 
> root node
> ---
>
> Key: SLING-5638
> URL: https://issues.apache.org/jira/browse/SLING-5638
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Reporter: Antonio Sanso
>Assignee: Antonio Sanso
> Fix For: Resource Resolver 1.5.0
>
> Attachments: SLING-5638-patch.txt
>
>
> issue ;- Sling:alias property not working if user is having read only access 
> to /content folder.
> Steps :-
> 1) Login using admin/admin.
> 2) Create page say mypage.html and provide sling:alias property say 
> mypagealias.
> 3) Create test user and provide read only access on /content folder from 
> useradmin console.
> 4) log out from admin user.
> 5) Hit the page http://localhost:4502/content//mypage.html it 
> will ask for the login ( login as test user ) it opens the page
> 6) hit the alias page 
> http://localhost:4502/content//mypagealias.html - it wont work.
> sling:alias property get stored at jcr:content node for the page in /content, 
> so user with read access on /content should access it. please correct me in 
> case I am missing something.
> to make it work user has to give root( read only ) access to test user only 
> then test user can access alias page. 



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

Re: [VOTE] Release Apache Sling Log Tracer 1.0.0

[Chetan Mehrotra]

+1 Approve the release

Chetan Mehrotra

Re: [VOTE] Release Apache Sling Scripting JSP-Taglib version 2.2.6

[Oliver Lietz]

On Thursday 14 April 2016 13:47:40 Julian Sedding wrote:
> Hi,
> 
> We solved 3 issues in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12328732

+1

O.

[jira] [Resolved] (SLING-4464) Use Sling Validation in Fling sample

[Oliver Lietz (JIRA)]

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

Oliver Lietz resolved SLING-4464.
-
Resolution: Done

[r1739998|https://svn.apache.org/r1739998]
[r173|https://svn.apache.org/r173]

> Use Sling Validation in Fling sample
> 
>
> Key: SLING-4464
> URL: https://issues.apache.org/jira/browse/SLING-4464
> Project: Sling
>  Issue Type: Task
>  Components: Samples
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>Priority: Minor
> Fix For: Samples Fling 0.0.2
>
>




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

[jira] [Resolved] (SLING-5655) Use Commons Messaging in Fling sample

[Oliver Lietz (JIRA)]

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

Oliver Lietz resolved SLING-5655.
-
Resolution: Done

[r1738384|https://svn.apache.org/r1738384]
[r1738385|https://svn.apache.org/r1738385]
[r1739994|https://svn.apache.org/r1739994]

> Use Commons Messaging in Fling sample
> -
>
> Key: SLING-5655
> URL: https://issues.apache.org/jira/browse/SLING-5655
> Project: Sling
>  Issue Type: New Feature
>  Components: Samples
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Samples Fling 0.0.2
>
>




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

[jira] [Resolved] (SLING-5663) Make Thymeleaf TemplateEngine available as service

[Oliver Lietz (JIRA)]

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

Oliver Lietz resolved SLING-5663.
-
Resolution: Done

[r1739985|https://svn.apache.org/r1739985]

> Make Thymeleaf TemplateEngine available as service
> --
>
> Key: SLING-5663
> URL: https://issues.apache.org/jira/browse/SLING-5663
> Project: Sling
>  Issue Type: New Feature
>  Components: Scripting
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Scripting Thymeleaf 0.1.8
>
>
> Sling Scripting ({{ThymeleafScriptEngine}}) is strongly tied to HTTP 
> requests. For rendering templates outside of web context service 
> {{org.thymeleaf.ITemplateEngine}} is a better choice.



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

[jira] [Resolved] (SLING-5579) setActive is not set to true during activation of CommonResourceResolverFactoryImpl

[Konrad Windszus (JIRA)]

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

Konrad Windszus resolved SLING-5579.

Resolution: Invalid

> setActive is not set to true during activation of 
> CommonResourceResolverFactoryImpl
> ---
>
> Key: SLING-5579
> URL: https://issues.apache.org/jira/browse/SLING-5579
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Reporter: Santiago García Pimentel
>
> CommonResourceResolverFactoryImpl holds a bolean isActive which should 
> reflect if the resource resolver is active or not, it is set to true only 
> during the declaration of the field and then to false in the deactivate 
> method of the component. It is never set to true again.
> Instead, isActive should be set to true in the activate method of the 
> component.
> org.apache.sling.api.resource.LoginException: ResourceResolverFactory is 
> deactivated.
>   at 
> org.apache.sling.resourceresolver.impl.CommonResourceResolverFactoryImpl.getResourceResolver(CommonResourceResolverFactoryImpl.java:146)
>   at 
> org.apache.sling.resourceresolver.impl.ResourceResolverFactoryImpl.getResourceResolver(ResourceResolverFactoryImpl.java:99)



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

[jira] [Commented] (SLING-1421) Resorce Resolver Mapping - Better Support for Multiple Domain/Protocol Mapping

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-1421:


Does proposal SLING-5672 sound like a viable way?

> Resorce Resolver Mapping - Better Support for Multiple Domain/Protocol Mapping
> --
>
> Key: SLING-1421
> URL: https://issues.apache.org/jira/browse/SLING-1421
> Project: Sling
>  Issue Type: Improvement
>  Components: ResourceResolver
>Affects Versions: JCR Resource 2.0.6
>Reporter: Stefan Seifert
> Attachments: 100303_slingtest-mapping.zip
>
>
> in our sling CMS-based web projects we've the following scenario:
> * most pages of a website are accessed via HTTP, but some of the via HTTPs 
> (e.g. including forms submitting personal data)
> * at the same time we use the mapping features at /etc/map to shorten the 
> urls for a given domain name
> * in fact we have to configure two mappings for two domain names (one for 
> HTTP and one for HTTPS), pointing to the same start path in JCR
> with this configuration in place the sling ResourceResolver.map method 
> sometimes produces unexpected or incorrect results with the current 
> implementation.
> if the current host name and port does not match with the configured mapping 
> host name and port sling automatically adds protocol, host name and port from 
> the configuration to the result of the map method. but in the case above with 
> multiple mappings for the same start path this cannot produce correct 
> results, because the decision whether the secure or non-secure domain name 
> should be chosen is custom application logic.
> i'm not sure what the best solution is for this problem, because the current 
> implementation makes sense in some way and works well for the simple 
> scenarios. but in complex scenarios with multiple domain mappings it would be 
> more practical to use the map method only for shortening the urls and not for 
> adding the hostname.
> of course it is possible to parse the value of the map method and strip off 
> any hostname returned manually and add an own one, but this seems not 
> "right". and if the cms does a check if the internal url is valid this url 
> can be treated as invalid.
> for easy reproduction of the scenario i've attached a simple test project 
> [^100303_slingtest-mapping.zip]. please deploy it to a sling instance using 
> "mvn install" and then call in the intro page 
> http://localhost:8080/content/slingtest-mapping.html and follow the 
> instructions on the page (two host names have to be added to the local hosts 
> file). the test project contains two templates/jsp components, a 
> configuration at /etc/map with two domain names pointing to the same path and 
> some sample content nodes.
> depending whether a default mapping "/content/-/" is configured in "apache 
> sling resource resolver" the generated links on the "site 1" test page are 
> correct. but the links generate on the "site 2" test pages are wrong.



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

[jira] [Updated] (SLING-5672) Allow wildcards within hostname, port and scheme to be used and still use the entry for reverse mapping

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-5672:
---
Description: 
Currently if any wildcards are used in the regular expressions for the Root 
Mapping Entries 
(http://sling.apache.org/documentation/the-sling-engine/mappings-for-resource-resolution.html#root-level-mappings)
 the entry is only considered for {{ResourceResolver.resolve(...)}}, i.e. 
inward mapping but no longer for {{ResourceResolver.map(...)}}, i.e. outward 
mapping.

While this makes sense for the {{URL path}} part it would be good to allow that 
for  {{scheme}}, {{host}} or {{port}}. So in case there is a wildcard regular 
expression being used on level 1 or 2 below the mapping entry root, this entry 
should still be considered for both inward and outward mapping.

  was:
Currently if any wildcards are used in the regular expressions for the Root 
Mapping Entries 
(http://sling.apache.org/documentation/the-sling-engine/mappings-for-resource-resolution.html#root-level-mappings)
 the entry is only considered for {{ResourceResolver.resolve(...)}}, i.e. 
inward mapping but no longer for {{ResourceResolver.map(...)}}, i.e. outward 
mapping.

While this makes sense for the URL path it would be good to allow that for  
scheme, host or port. So in case there is a wildcard regular expression being 
used on level 1 or 2 below the mapping entry root, this entry should still be 
considered for both incoming and outgoing mapping.


> Allow wildcards within hostname, port and scheme to be used and still use the 
> entry for reverse mapping
> ---
>
> Key: SLING-5672
> URL: https://issues.apache.org/jira/browse/SLING-5672
> Project: Sling
>  Issue Type: Improvement
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.4.10
>Reporter: Konrad Windszus
>
> Currently if any wildcards are used in the regular expressions for the Root 
> Mapping Entries 
> (http://sling.apache.org/documentation/the-sling-engine/mappings-for-resource-resolution.html#root-level-mappings)
>  the entry is only considered for {{ResourceResolver.resolve(...)}}, i.e. 
> inward mapping but no longer for {{ResourceResolver.map(...)}}, i.e. outward 
> mapping.
> While this makes sense for the {{URL path}} part it would be good to allow 
> that for  {{scheme}}, {{host}} or {{port}}. So in case there is a wildcard 
> regular expression being used on level 1 or 2 below the mapping entry root, 
> this entry should still be considered for both inward and outward mapping.



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

Re: Configuration of the ResourceResolver Mapping

[Konrad Windszus]

Again my answers are inline.

> On 19 Apr 2016, at 16:42, Julian Sedding  wrote:
> 
> Hi Konrad
> 
> See my reply inline.
> 
> Regards
> Julian
> 
> On Tue, Apr 19, 2016 at 3:32 PM, Konrad Windszus  wrote:
>> Hi Julian,
>> thanks for that hint. I will try it out.
>> Still it is not possible with b) to have the same mapping rule being applied 
>> to all hosts/schemes/ports without maintaining it separately for each 
>> host/scheme/port.
> 
> Absolutely, and that can be painful, especially if you only have a
> single vhost, but different environments (e.g. dev, test, stage,
> prod). I work around this by configuring the location of /etc/maps
> depending on the runmode. Still it requires me to maintain mappings
> for different environments.
> 
>> I very often use the vhost section in the web server in front to do the 
>> mapping from one vhost to a certain root path within the repo, e.g. 
>> /content/customer/website. Therefore within Sling I am mostly interested in 
>> stripping the first three levels for all paths starting with /content in the 
>> outward mapping. I currently do not see how to easily accomplish that with 
>> b).
> 
> I don't see how this can be done with a catch-all rule either. The
> config would need to be duplicated for each vhost.
> 
> Maybe we should start supporting a wildcard/regexp for the hostname?
> If it is e.g. "*", the rule applies to any value unless a more
> specific rule is found. WDYT?

That sounds like a reasonable proposal. I created the issue 
https://issues.apache.org/jira/browse/SLING-5672 for that.
I had a look in the code though, and in the current state I don't dare to 
commit anything within mapping classes. The logic is so complex and convoluted 
and the namings are confusing which are being used there. Therefore someone 
else would need to take that up.

> 
>> Thanks,
>> Konrad
>> 
>> 
>>> On 19 Apr 2016, at 15:12, Julian Sedding  wrote:
>>> 
>>> Hi Konrad
>>> 
>>> In my opinion b) is the preferred way, even though it is slightly more
>>> complicated to configure.
>>> 
>>> Use-case 1) is possible with b), but not very well documented.
>>> Essentially, you can provide a regexp as the value of
>>> sling:internalRedirect (and replacements in sling:match), in which
>>> case the mapping is only used for the outward mapping (i.e. RR.map()).
>>> See SLING-2560 for details.
>>> 
>>> If a) is not already deprecated, maybe we should deprecate it? The
>>> whole mapping business is overly complicated IMHO and any reduction of
>>> the complexity is welcome.
>>> 
>>> Regards
>>> Julian
>>> 
>>> On Tue, Apr 19, 2016 at 2:35 PM, Konrad Windszus  wrote:
 Currently there are two possibilities to configure the resource resolver 
 mapping:
 
 a) Through the OSGi property "resource.resolver.mapping" of the PID 
 org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl
 b) Through the resources below the path being specified by the OSGI 
 property "resource.resolver.map.location" of the PID 
 org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl
 
 Both possibilities are overlapping in certain parts, but some aspects can 
 only be configured in either a) or b). Let me quickly reconsider which way 
 supports which features
 
 1) Different incoming and outgoing mappings can only be given in a) 
 because b) will always assume the mapping is for both directions (except 
 in the case when regular expression are used, as then the entry in b) will 
 only be used for incoming mapping. To only specify an outgoing mapping 
 with b) is impossible)
 2) Mapping for a specific Host or Scheme can only be given in b). I opened 
 https://issues.apache.org/jira/browse/SLING-5670 about that!
 3) Redirecting for incoming mappings is only supported through b)
 3) Reconfiguring through a) is more expensive as this requires a lot of 
 depending OSGi services to be restarted!
 
 I have the feeling, that b) is the preferred way from a performance but 
 also from a feature point of view, but it is very sad that b) is lacking 
 the possibility 1.
 
 So instead of extending both mechanisms to make them cover the same 
 features, I would like to know what is the recommended approach.
 
 Then we can look into how to make the full feature set maintainable 
 through this preferred way of configuring and at the same time deprecate 
 the other.
 
 Thanks,
 Konrad
>> 

[jira] [Created] (SLING-5672) Allow wildcards within hostname, port and scheme to be used and still use the entry for reverse mapping

[Konrad Windszus (JIRA)]

Konrad Windszus created SLING-5672:
--

 Summary: Allow wildcards within hostname, port and scheme to be 
used and still use the entry for reverse mapping
 Key: SLING-5672
 URL: https://issues.apache.org/jira/browse/SLING-5672
 Project: Sling
  Issue Type: Improvement
  Components: ResourceResolver
Affects Versions: Resource Resolver 1.4.10
Reporter: Konrad Windszus


Currently if any wildcards are used in the regular expressions for the Root 
Mapping Entries 
(http://sling.apache.org/documentation/the-sling-engine/mappings-for-resource-resolution.html#root-level-mappings)
 the entry is only considered for {{ResourceResolver.resolve(...)}}, i.e. 
inward mapping but no longer for {{ResourceResolver.map(...)}}, i.e. outward 
mapping.

While this makes sense for the URL path it would be good to allow that for  
scheme, host or port. So in case there is a wildcard regular expression being 
used on level 1 or 2 below the mapping entry root, this entry should still be 
considered for both incoming and outgoing mapping.



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

[jira] [Updated] (SLING-5671) Not matching port in the mapping entry still leads to using this entry for the outward mapping (used in ResourceResolver.map)

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-5671:
---
Summary: Not matching port in the mapping entry still leads to using this 
entry for the outward mapping (used in ResourceResolver.map)  (was: Not 
matching port in the mapping entry still uses the mapping for the outward 
mapping (used in ResourceResolver.map))

> Not matching port in the mapping entry still leads to using this entry for 
> the outward mapping (used in ResourceResolver.map)
> -
>
> Key: SLING-5671
> URL: https://issues.apache.org/jira/browse/SLING-5671
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.4.10
>Reporter: Konrad Windszus
>
> The following resource structure:
> {code}
> /etc/map
>   + http
> + localhost:80
>   + mappedpath
>   - sling:internalRedirect="/content/some/path"
> {code}
> leads to the following entry being listed in the outwards (mapping) map 
> (inside {{/system/console/jcrresolver}})
> {code}
> ^/content/some/path/  http://localhost/mappedpath/  external: 302
> {code}
> There are three things wrong here:
> # the entry in the system console exposes this entry as external redirect 
> with 302 status (although all mapping map entries can only be internal ones 
> IMHO)
> # That entry incorrectly applies to links towards that path even if the 
> request was done on another port. 
> # Even worse, if the request was done through another port, it will lead to 
> URLs like {{http://localhost/mappedpath/}} being generated with 
> {{ResourceResolver.map(...)}}.



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

Re: Configuration of the ResourceResolver Mapping

[Konrad Windszus]

I added documentation about SLING-2560 in https://svn.apache.org/r1739954.
Please quickly cross-check 
http://sling.staging.apache.org/documentation/the-sling-engine/mappings-for-resource-resolution.html,
 afterwards I will publish the changes.
Thanks,
Konrad

> On 19 Apr 2016, at 15:12, Julian Sedding  wrote:
> 
> Hi Konrad
> 
> In my opinion b) is the preferred way, even though it is slightly more
> complicated to configure.
> 
> Use-case 1) is possible with b), but not very well documented.
> Essentially, you can provide a regexp as the value of
> sling:internalRedirect (and replacements in sling:match), in which
> case the mapping is only used for the outward mapping (i.e. RR.map()).
> See SLING-2560 for details.
> 
> If a) is not already deprecated, maybe we should deprecate it? The
> whole mapping business is overly complicated IMHO and any reduction of
> the complexity is welcome.
> 
> Regards
> Julian
> 
> On Tue, Apr 19, 2016 at 2:35 PM, Konrad Windszus  wrote:
>> Currently there are two possibilities to configure the resource resolver 
>> mapping:
>> 
>> a) Through the OSGi property "resource.resolver.mapping" of the PID 
>> org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl
>> b) Through the resources below the path being specified by the OSGI property 
>> "resource.resolver.map.location" of the PID 
>> org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl
>> 
>> Both possibilities are overlapping in certain parts, but some aspects can 
>> only be configured in either a) or b). Let me quickly reconsider which way 
>> supports which features
>> 
>> 1) Different incoming and outgoing mappings can only be given in a) because 
>> b) will always assume the mapping is for both directions (except in the case 
>> when regular expression are used, as then the entry in b) will only be used 
>> for incoming mapping. To only specify an outgoing mapping with b) is 
>> impossible)
>> 2) Mapping for a specific Host or Scheme can only be given in b). I opened 
>> https://issues.apache.org/jira/browse/SLING-5670 about that!
>> 3) Redirecting for incoming mappings is only supported through b)
>> 3) Reconfiguring through a) is more expensive as this requires a lot of 
>> depending OSGi services to be restarted!
>> 
>> I have the feeling, that b) is the preferred way from a performance but also 
>> from a feature point of view, but it is very sad that b) is lacking the 
>> possibility 1.
>> 
>> So instead of extending both mechanisms to make them cover the same 
>> features, I would like to know what is the recommended approach.
>> 
>> Then we can look into how to make the full feature set maintainable through 
>> this preferred way of configuring and at the same time deprecate the other.
>> 
>> Thanks,
>> Konrad

Re: Configuration of the ResourceResolver Mapping

[Julian Sedding]

Hi Konrad

See my reply inline.

Regards
Julian

On Tue, Apr 19, 2016 at 3:32 PM, Konrad Windszus  wrote:
> Hi Julian,
> thanks for that hint. I will try it out.
> Still it is not possible with b) to have the same mapping rule being applied 
> to all hosts/schemes/ports without maintaining it separately for each 
> host/scheme/port.

Absolutely, and that can be painful, especially if you only have a
single vhost, but different environments (e.g. dev, test, stage,
prod). I work around this by configuring the location of /etc/maps
depending on the runmode. Still it requires me to maintain mappings
for different environments.

> I very often use the vhost section in the web server in front to do the 
> mapping from one vhost to a certain root path within the repo, e.g. 
> /content/customer/website. Therefore within Sling I am mostly interested in 
> stripping the first three levels for all paths starting with /content in the 
> outward mapping. I currently do not see how to easily accomplish that with b).

I don't see how this can be done with a catch-all rule either. The
config would need to be duplicated for each vhost.

Maybe we should start supporting a wildcard/regexp for the hostname?
If it is e.g. "*", the rule applies to any value unless a more
specific rule is found. WDYT?

> Thanks,
> Konrad
>
>
>> On 19 Apr 2016, at 15:12, Julian Sedding  wrote:
>>
>> Hi Konrad
>>
>> In my opinion b) is the preferred way, even though it is slightly more
>> complicated to configure.
>>
>> Use-case 1) is possible with b), but not very well documented.
>> Essentially, you can provide a regexp as the value of
>> sling:internalRedirect (and replacements in sling:match), in which
>> case the mapping is only used for the outward mapping (i.e. RR.map()).
>> See SLING-2560 for details.
>>
>> If a) is not already deprecated, maybe we should deprecate it? The
>> whole mapping business is overly complicated IMHO and any reduction of
>> the complexity is welcome.
>>
>> Regards
>> Julian
>>
>> On Tue, Apr 19, 2016 at 2:35 PM, Konrad Windszus  wrote:
>>> Currently there are two possibilities to configure the resource resolver 
>>> mapping:
>>>
>>> a) Through the OSGi property "resource.resolver.mapping" of the PID 
>>> org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl
>>> b) Through the resources below the path being specified by the OSGI 
>>> property "resource.resolver.map.location" of the PID 
>>> org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl
>>>
>>> Both possibilities are overlapping in certain parts, but some aspects can 
>>> only be configured in either a) or b). Let me quickly reconsider which way 
>>> supports which features
>>>
>>> 1) Different incoming and outgoing mappings can only be given in a) because 
>>> b) will always assume the mapping is for both directions (except in the 
>>> case when regular expression are used, as then the entry in b) will only be 
>>> used for incoming mapping. To only specify an outgoing mapping with b) is 
>>> impossible)
>>> 2) Mapping for a specific Host or Scheme can only be given in b). I opened 
>>> https://issues.apache.org/jira/browse/SLING-5670 about that!
>>> 3) Redirecting for incoming mappings is only supported through b)
>>> 3) Reconfiguring through a) is more expensive as this requires a lot of 
>>> depending OSGi services to be restarted!
>>>
>>> I have the feeling, that b) is the preferred way from a performance but 
>>> also from a feature point of view, but it is very sad that b) is lacking 
>>> the possibility 1.
>>>
>>> So instead of extending both mechanisms to make them cover the same 
>>> features, I would like to know what is the recommended approach.
>>>
>>> Then we can look into how to make the full feature set maintainable through 
>>> this preferred way of configuring and at the same time deprecate the other.
>>>
>>> Thanks,
>>> Konrad
>

[jira] [Created] (SLING-5671) Not matching port in the mapping entry still uses the mapping for the outward mapping (used in ResourceResolver.map)

[Konrad Windszus (JIRA)]

Konrad Windszus created SLING-5671:
--

 Summary: Not matching port in the mapping entry still uses the 
mapping for the outward mapping (used in ResourceResolver.map)
 Key: SLING-5671
 URL: https://issues.apache.org/jira/browse/SLING-5671
 Project: Sling
  Issue Type: Bug
  Components: ResourceResolver
Affects Versions: Resource Resolver 1.4.10
Reporter: Konrad Windszus


If you have the following resource structure:
{code}
/etc/map
  + http
+ localhost:80
  + mappedpath
  - sling:internalRedirect="/content/some/path"
{code}

leads to the following entry being listed in the outwards (mapping) map (inside 
{{/system/console/jcrresolver}})
{code}
^/content/some/path/  http://localhost/mappedpath/  external: 302
{code}

That entry applies to links towards that path even if the request was done on 
port 4502. Even worse, it will lead to URLs like 
{{http://localhost/mappedpath/}} being generated with 
{{ResourceResolver.map(...)}}.



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

[jira] [Updated] (SLING-5671) Not matching port in the mapping entry still uses the mapping for the outward mapping (used in ResourceResolver.map)

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-5671:
---
Description: 
The following resource structure:
{code}
/etc/map
  + http
+ localhost:80
  + mappedpath
  - sling:internalRedirect="/content/some/path"
{code}

leads to the following entry being listed in the outwards (mapping) map (inside 
{{/system/console/jcrresolver}})
{code}
^/content/some/path/  http://localhost/mappedpath/  external: 302
{code}

There are three things wrong here:
# the entry in the system console exposes this entry as external redirect with 
302 status (although all mapping map entries can only be internal ones IMHO)
# That entry incorrectly applies to links towards that path even if the request 
was done on another port. 
# Even worse, if the request was done through another port, it will lead to 
URLs like {{http://localhost/mappedpath/}} being generated with 
{{ResourceResolver.map(...)}}.

  was:
The following resource structure:
{code}
/etc/map
  + http
+ localhost:80
  + mappedpath
  - sling:internalRedirect="/content/some/path"
{code}

leads to the following entry being listed in the outwards (mapping) map (inside 
{{/system/console/jcrresolver}})
{code}
^/content/some/path/  http://localhost/mappedpath/  external: 302
{code}

There are three things wrong here:
# the entry in the system console links that as external redirect with 302 
(although all mapping map entries can only be internal ones IMHO)
# That entry incorrectly applies to links towards that path even if the request 
was done on another port. 
# Even worse, if the request was done through another port, it will lead to 
URLs like {{http://localhost/mappedpath/}} being generated with 
{{ResourceResolver.map(...)}}.


> Not matching port in the mapping entry still uses the mapping for the outward 
> mapping (used in ResourceResolver.map)
> 
>
> Key: SLING-5671
> URL: https://issues.apache.org/jira/browse/SLING-5671
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.4.10
>Reporter: Konrad Windszus
>
> The following resource structure:
> {code}
> /etc/map
>   + http
> + localhost:80
>   + mappedpath
>   - sling:internalRedirect="/content/some/path"
> {code}
> leads to the following entry being listed in the outwards (mapping) map 
> (inside {{/system/console/jcrresolver}})
> {code}
> ^/content/some/path/  http://localhost/mappedpath/  external: 302
> {code}
> There are three things wrong here:
> # the entry in the system console exposes this entry as external redirect 
> with 302 status (although all mapping map entries can only be internal ones 
> IMHO)
> # That entry incorrectly applies to links towards that path even if the 
> request was done on another port. 
> # Even worse, if the request was done through another port, it will lead to 
> URLs like {{http://localhost/mappedpath/}} being generated with 
> {{ResourceResolver.map(...)}}.



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

[jira] [Updated] (SLING-5671) Not matching port in the mapping entry still uses the mapping for the outward mapping (used in ResourceResolver.map)

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-5671:
---
Description: 
The following resource structure:
{code}
/etc/map
  + http
+ localhost:80
  + mappedpath
  - sling:internalRedirect="/content/some/path"
{code}

leads to the following entry being listed in the outwards (mapping) map (inside 
{{/system/console/jcrresolver}})
{code}
^/content/some/path/  http://localhost/mappedpath/  external: 302
{code}

There are three things wrong here:
# the entry in the system console links that as external redirect with 302 
(although all mapping map entries can only be internal ones IMHO)
# That entry incorrectly applies to links towards that path even if the request 
was done on another port. 
# Even worse, if the request was done through another port, it will lead to 
URLs like {{http://localhost/mappedpath/}} being generated with 
{{ResourceResolver.map(...)}}.

  was:
The following resource structure:
{code}
/etc/map
  + http
+ localhost:80
  + mappedpath
  - sling:internalRedirect="/content/some/path"
{code}

leads to the following entry being listed in the outwards (mapping) map (inside 
{{/system/console/jcrresolver}})
{code}
^/content/some/path/  http://localhost/mappedpath/  external: 302
{code}

That entry incorrectly applies to links towards that path even if the request 
was done on another port. Even worse, if the request was done through another 
port, it will lead to URLs like {{http://localhost/mappedpath/}} being 
generated with {{ResourceResolver.map(...)}}.


> Not matching port in the mapping entry still uses the mapping for the outward 
> mapping (used in ResourceResolver.map)
> 
>
> Key: SLING-5671
> URL: https://issues.apache.org/jira/browse/SLING-5671
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.4.10
>Reporter: Konrad Windszus
>
> The following resource structure:
> {code}
> /etc/map
>   + http
> + localhost:80
>   + mappedpath
>   - sling:internalRedirect="/content/some/path"
> {code}
> leads to the following entry being listed in the outwards (mapping) map 
> (inside {{/system/console/jcrresolver}})
> {code}
> ^/content/some/path/  http://localhost/mappedpath/  external: 302
> {code}
> There are three things wrong here:
> # the entry in the system console links that as external redirect with 302 
> (although all mapping map entries can only be internal ones IMHO)
> # That entry incorrectly applies to links towards that path even if the 
> request was done on another port. 
> # Even worse, if the request was done through another port, it will lead to 
> URLs like {{http://localhost/mappedpath/}} being generated with 
> {{ResourceResolver.map(...)}}.



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

[jira] [Updated] (SLING-5671) Not matching port in the mapping entry still uses the mapping for the outward mapping (used in ResourceResolver.map)

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-5671:
---
Description: 
The following resource structure:
{code}
/etc/map
  + http
+ localhost:80
  + mappedpath
  - sling:internalRedirect="/content/some/path"
{code}

leads to the following entry being listed in the outwards (mapping) map (inside 
{{/system/console/jcrresolver}})
{code}
^/content/some/path/  http://localhost/mappedpath/  external: 302
{code}

That entry incorrectly applies to links towards that path even if the request 
was done on another port. Even worse, if the request was done through another 
port, it will lead to URLs like {{http://localhost/mappedpath/}} being 
generated with {{ResourceResolver.map(...)}}.

  was:
The following resource structure:
{code}
/etc/map
  + http
+ localhost:80
  + mappedpath
  - sling:internalRedirect="/content/some/path"
{code}

leads to the following entry being listed in the outwards (mapping) map (inside 
{{/system/console/jcrresolver}})
{code}
^/content/some/path/  http://localhost/mappedpath/  external: 302
{code}

That entry applies to links towards that path even if the request was done on 
port 4502. Even worse, it will lead to URLs like 
{{http://localhost/mappedpath/}} being generated with 
{{ResourceResolver.map(...)}}.


> Not matching port in the mapping entry still uses the mapping for the outward 
> mapping (used in ResourceResolver.map)
> 
>
> Key: SLING-5671
> URL: https://issues.apache.org/jira/browse/SLING-5671
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.4.10
>Reporter: Konrad Windszus
>
> The following resource structure:
> {code}
> /etc/map
>   + http
> + localhost:80
>   + mappedpath
>   - sling:internalRedirect="/content/some/path"
> {code}
> leads to the following entry being listed in the outwards (mapping) map 
> (inside {{/system/console/jcrresolver}})
> {code}
> ^/content/some/path/  http://localhost/mappedpath/  external: 302
> {code}
> That entry incorrectly applies to links towards that path even if the request 
> was done on another port. Even worse, if the request was done through another 
> port, it will lead to URLs like {{http://localhost/mappedpath/}} being 
> generated with {{ResourceResolver.map(...)}}.



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

[jira] [Updated] (SLING-5671) Not matching port in the mapping entry still uses the mapping for the outward mapping (used in ResourceResolver.map)

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-5671:
---
Description: 
The following resource structure:
{code}
/etc/map
  + http
+ localhost:80
  + mappedpath
  - sling:internalRedirect="/content/some/path"
{code}

leads to the following entry being listed in the outwards (mapping) map (inside 
{{/system/console/jcrresolver}})
{code}
^/content/some/path/  http://localhost/mappedpath/  external: 302
{code}

That entry applies to links towards that path even if the request was done on 
port 4502. Even worse, it will lead to URLs like 
{{http://localhost/mappedpath/}} being generated with 
{{ResourceResolver.map(...)}}.

  was:
If you have the following resource structure:
{code}
/etc/map
  + http
+ localhost:80
  + mappedpath
  - sling:internalRedirect="/content/some/path"
{code}

leads to the following entry being listed in the outwards (mapping) map (inside 
{{/system/console/jcrresolver}})
{code}
^/content/some/path/  http://localhost/mappedpath/  external: 302
{code}

That entry applies to links towards that path even if the request was done on 
port 4502. Even worse, it will lead to URLs like 
{{http://localhost/mappedpath/}} being generated with 
{{ResourceResolver.map(...)}}.


> Not matching port in the mapping entry still uses the mapping for the outward 
> mapping (used in ResourceResolver.map)
> 
>
> Key: SLING-5671
> URL: https://issues.apache.org/jira/browse/SLING-5671
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.4.10
>Reporter: Konrad Windszus
>
> The following resource structure:
> {code}
> /etc/map
>   + http
> + localhost:80
>   + mappedpath
>   - sling:internalRedirect="/content/some/path"
> {code}
> leads to the following entry being listed in the outwards (mapping) map 
> (inside {{/system/console/jcrresolver}})
> {code}
> ^/content/some/path/  http://localhost/mappedpath/  external: 302
> {code}
> That entry applies to links towards that path even if the request was done on 
> port 4502. Even worse, it will lead to URLs like 
> {{http://localhost/mappedpath/}} being generated with 
> {{ResourceResolver.map(...)}}.



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

Re: Configuration of the ResourceResolver Mapping

[Ruben Reusser]

I think approach b) has a couple of short comings for larger sites as well

a good example are bucket pages (say you have to bucket content because 
otherwise you have to many subnodes). I've seen sites where these bucket 
pages are removed from the urls.


a secondary issue is that the upstream caching mechanism does not know 
about the mapping and therefore has trouble caching pages in a good 
manner (suffix and selector based pages)


I would honestly prefer an option c)

where
1) sling can be asked to resolve a short url to a long url (in 
conjunction with an apache module that can use this resolution for caching)
2) use a rewrite pipeline for outgoing url changes (there are also use 
cases for serving assets from a static domain)


Ruben

On 4/19/2016 6:18 AM, Bertrand Delacretaz wrote:

On Tue, Apr 19, 2016 at 3:12 PM, Julian Sedding  wrote:

...The whole mapping business is overly complicated IMHO and any reduction
of the complexity is welcome

Indeed. I would suggest that people who are actively managing large
Sling instances in the field (hint, hint ;-) come up with proposals
about how to simplify the whole thing.

-Bertrand

Re: Configuration of the ResourceResolver Mapping

[Konrad Windszus]

Hi Julian,
thanks for that hint. I will try it out.
Still it is not possible with b) to have the same mapping rule being applied to 
all hosts/schemes/ports without maintaining it separately for each 
host/scheme/port.
I very often use the vhost section in the web server in front to do the mapping 
from one vhost to a certain root path within the repo, e.g. 
/content/customer/website. Therefore within Sling I am mostly interested in 
stripping the first three levels for all paths starting with /content in the 
outward mapping. I currently do not see how to easily accomplish that with b).
Thanks,
Konrad


> On 19 Apr 2016, at 15:12, Julian Sedding  wrote:
> 
> Hi Konrad
> 
> In my opinion b) is the preferred way, even though it is slightly more
> complicated to configure.
> 
> Use-case 1) is possible with b), but not very well documented.
> Essentially, you can provide a regexp as the value of
> sling:internalRedirect (and replacements in sling:match), in which
> case the mapping is only used for the outward mapping (i.e. RR.map()).
> See SLING-2560 for details.
> 
> If a) is not already deprecated, maybe we should deprecate it? The
> whole mapping business is overly complicated IMHO and any reduction of
> the complexity is welcome.
> 
> Regards
> Julian
> 
> On Tue, Apr 19, 2016 at 2:35 PM, Konrad Windszus  wrote:
>> Currently there are two possibilities to configure the resource resolver 
>> mapping:
>> 
>> a) Through the OSGi property "resource.resolver.mapping" of the PID 
>> org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl
>> b) Through the resources below the path being specified by the OSGI property 
>> "resource.resolver.map.location" of the PID 
>> org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl
>> 
>> Both possibilities are overlapping in certain parts, but some aspects can 
>> only be configured in either a) or b). Let me quickly reconsider which way 
>> supports which features
>> 
>> 1) Different incoming and outgoing mappings can only be given in a) because 
>> b) will always assume the mapping is for both directions (except in the case 
>> when regular expression are used, as then the entry in b) will only be used 
>> for incoming mapping. To only specify an outgoing mapping with b) is 
>> impossible)
>> 2) Mapping for a specific Host or Scheme can only be given in b). I opened 
>> https://issues.apache.org/jira/browse/SLING-5670 about that!
>> 3) Redirecting for incoming mappings is only supported through b)
>> 3) Reconfiguring through a) is more expensive as this requires a lot of 
>> depending OSGi services to be restarted!
>> 
>> I have the feeling, that b) is the preferred way from a performance but also 
>> from a feature point of view, but it is very sad that b) is lacking the 
>> possibility 1.
>> 
>> So instead of extending both mechanisms to make them cover the same 
>> features, I would like to know what is the recommended approach.
>> 
>> Then we can look into how to make the full feature set maintainable through 
>> this preferred way of configuring and at the same time deprecate the other.
>> 
>> Thanks,
>> Konrad

Re: Configuration of the ResourceResolver Mapping

[Bertrand Delacretaz]

On Tue, Apr 19, 2016 at 3:12 PM, Julian Sedding  wrote:
> ...The whole mapping business is overly complicated IMHO and any reduction
> of the complexity is welcome

Indeed. I would suggest that people who are actively managing large
Sling instances in the field (hint, hint ;-) come up with proposals
about how to simplify the whole thing.

-Bertrand

Re: Configuration of the ResourceResolver Mapping

[Julian Sedding]

Hi Konrad

In my opinion b) is the preferred way, even though it is slightly more
complicated to configure.

Use-case 1) is possible with b), but not very well documented.
Essentially, you can provide a regexp as the value of
sling:internalRedirect (and replacements in sling:match), in which
case the mapping is only used for the outward mapping (i.e. RR.map()).
See SLING-2560 for details.

If a) is not already deprecated, maybe we should deprecate it? The
whole mapping business is overly complicated IMHO and any reduction of
the complexity is welcome.

Regards
Julian

On Tue, Apr 19, 2016 at 2:35 PM, Konrad Windszus  wrote:
> Currently there are two possibilities to configure the resource resolver 
> mapping:
>
> a) Through the OSGi property "resource.resolver.mapping" of the PID 
> org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl
> b) Through the resources below the path being specified by the OSGI property 
> "resource.resolver.map.location" of the PID 
> org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl
>
> Both possibilities are overlapping in certain parts, but some aspects can 
> only be configured in either a) or b). Let me quickly reconsider which way 
> supports which features
>
> 1) Different incoming and outgoing mappings can only be given in a) because 
> b) will always assume the mapping is for both directions (except in the case 
> when regular expression are used, as then the entry in b) will only be used 
> for incoming mapping. To only specify an outgoing mapping with b) is 
> impossible)
> 2) Mapping for a specific Host or Scheme can only be given in b). I opened 
> https://issues.apache.org/jira/browse/SLING-5670 about that!
> 3) Redirecting for incoming mappings is only supported through b)
> 3) Reconfiguring through a) is more expensive as this requires a lot of 
> depending OSGi services to be restarted!
>
> I have the feeling, that b) is the preferred way from a performance but also 
> from a feature point of view, but it is very sad that b) is lacking the 
> possibility 1.
>
> So instead of extending both mechanisms to make them cover the same features, 
> I would like to know what is the recommended approach.
>
> Then we can look into how to make the full feature set maintainable through 
> this preferred way of configuring and at the same time deprecate the other.
>
> Thanks,
> Konrad

Configuration of the ResourceResolver Mapping

[Konrad Windszus]

Currently there are two possibilities to configure the resource resolver 
mapping:

a) Through the OSGi property "resource.resolver.mapping" of the PID 
org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl
b) Through the resources below the path being specified by the OSGI property 
"resource.resolver.map.location" of the PID 
org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl

Both possibilities are overlapping in certain parts, but some aspects can only 
be configured in either a) or b). Let me quickly reconsider which way supports 
which features

1) Different incoming and outgoing mappings can only be given in a) because b) 
will always assume the mapping is for both directions (except in the case when 
regular expression are used, as then the entry in b) will only be used for 
incoming mapping. To only specify an outgoing mapping with b) is impossible)
2) Mapping for a specific Host or Scheme can only be given in b). I opened 
https://issues.apache.org/jira/browse/SLING-5670 about that!
3) Redirecting for incoming mappings is only supported through b) 
3) Reconfiguring through a) is more expensive as this requires a lot of 
depending OSGi services to be restarted!

I have the feeling, that b) is the preferred way from a performance but also 
from a feature point of view, but it is very sad that b) is lacking the 
possibility 1.

So instead of extending both mechanisms to make them cover the same features, I 
would like to know what is the recommended approach.

Then we can look into how to make the full feature set maintainable through 
this preferred way of configuring and at the same time deprecate the other.

Thanks,
Konrad

[jira] [Created] (SLING-5670) The OSGi property "resource.resolver.mapping" does not allow to restrict mapping to certain schemes or hosts

[Konrad Windszus (JIRA)]

Konrad Windszus created SLING-5670:
--

 Summary: The OSGi property "resource.resolver.mapping" does not 
allow to restrict mapping to certain schemes or hosts
 Key: SLING-5670
 URL: https://issues.apache.org/jira/browse/SLING-5670
 Project: Sling
  Issue Type: Improvement
  Components: ResourceResolver
Affects Versions: Resource Resolver 1.4.10
Reporter: Konrad Windszus


In contrast to what the external mapping configuration in {{/etc/map}} allows, 
the OSGi configuration property "resource.resolver.mapping" does not allow to 
restrict either incoming or outgoing mappings to certain hosts or schemes.
The according code is in 
https://github.com/apache/sling/blob/c9e59667d8f9cd698bc33a51f3e6a22e85d4a952/bundles/resourceresolver/src/main/java/org/apache/sling/resourceresolver/impl/mapping/MapEntries.java#L1333
 for incoming mapping (resolve) and in 
https://github.com/apache/sling/blob/c9e59667d8f9cd698bc33a51f3e6a22e85d4a952/bundles/resourceresolver/src/main/java/org/apache/sling/resourceresolver/impl/mapping/MapEntries.java#L1351
 for outgoing mappings (map).




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

Re: [RT] A Batch jobs API to complement the existing Jobs API

[Bertrand Delacretaz]

Hi,

On Mon, Apr 18, 2016 at 4:20 PM, Timothée Maret
 wrote:
> ...One aspect that may differentiate asset processing from general job use
> case is the guarantees offered from the job delivery. Some use case would
> be fine with "at-least-one" or "maybe" delivery whereas some use case will
> need "exactly-one" delivery

It's not only about delivering the job submission message, in some
cases it's the whole job execution that needs to be exactly once, for
example.

Designing (or configuring if using the SLING-5646 stuff) a batch job
engine with relatively relaxed requirements about message delivery
(like at least once for the job submission message) might make it much
simpler to implement it in a scalable way.

Of course there are some cases where exactly once *execution* of batch
jobs is required, but then the whole execution chain should be
considered, maybe using a distinct distributed consensus service to
coordinate the whole execution chain.

Ian mentioned to me that some queuing systems can play this role by
having a two-phase "take message from queue" mechanism IIUC, where a
job executor has to confirm success before a message is considered
consume, that could also play this role.

My point is that in some cases the whole job execution chain has to be
considered for exactly once or at least once semantics.

-Bertrand

Re: [RT] A Batch jobs API to complement the existing Jobs API

[Bertrand Delacretaz]

Hi,

On Mon, Apr 18, 2016 at 4:04 PM, Ian Boston  wrote:
> ...I am not certain how a Callable will work with a distributed
> implementation,...

Ok, what shape a batch job takes is not very important at this stage,
I get your point.

...
>> void registerBatchEventListener(BatchEventsListener bleh, JobId
>> ... restrictToSpecificJobIds);
>>  }
>
> IIUC this is a bit on an Anti pattern with OSGi. AFAIK the Whiteboard
> pattern is prefered...

Makes sense. And it makes the API even simpler.

> ...Is there a reason that you think the implementation under SLING-5646 won't
> support the batch use case ?...

I suppose it would work, like this:
1. To submit a job, send it to a Queue that's appropriately configured
2. Subscribe to a Topic to receive events about the job's execution
3. All good if a DONE message is received on that topic
4. If an ERROR message is received, or if timeout, act accordingly

That certainly works but requires some non obvious conventions, as
opposed to an API like the one I suggested which is narrower and more
self-explaining.

But maybe we can leave those kinds of details to users of a job
execution system based on SLING-5646.

-Bertrand

Re: [VOTE] Release Apache Sling Scripting JSP-Taglib version 2.2.6

[Julian Sedding]

We're missing one binding vote. Anyone?

Regards
Julian

On Thu, Apr 14, 2016 at 3:33 PM, Daniel Klco  wrote:
> +1
>
> On Thu, Apr 14, 2016 at 7:47 AM, Julian Sedding  wrote:
>
>> Hi,
>>
>> We solved 3 issues in this release:
>> https://issues.apache.org/jira/browse/SLING/fixforversion/12328732
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachesling-1453/
>>
>> You can use this UNIX script to download the release and verify the
>> signatures:
>> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>>
>> Usage:
>> sh check_staged_release.sh 1453 /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
>> Julian
>>

[VOTE] Release Apache Sling Log Tracer 1.0.0

[Chetan Mehrotra]

Hi,

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

** New Feature
* [SLING-5459] - Recording of tracer logs

** Sub-task
* [SLING-5504] - Reduce memory footprint of stored recording data
* [SLING-5505] - Allow recording of caller stacktrace with the logs
* [SLING-5507] - Collect more details around query execution

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

You can use this UNIX script to download the release and verify the
signatures:
http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh

Usage:
sh check_staged_release.sh 1455 /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.

[jira] [Resolved] (SLING-5459) Recording of tracer logs

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra resolved SLING-5459.

Resolution: Fixed

All planned work done

> Recording of tracer logs
> 
>
> Key: SLING-5459
> URL: https://issues.apache.org/jira/browse/SLING-5459
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: Log Tracer 1.0.0
>
> Attachments: SLING-5459-v1.patch, tracer-recording.json
>
>
> Sling Log Tracer currently provides support for fine grained control of 
> enabling logs for specific request. To make this log more accessible it would 
> be useful to have a feature where the client can also fetch the logs from 
> specific request over HTTP.
> This feature would work like below
> # Client sends an HTTP request with header {{Sling-Tracer-Record​}}  set to 
> true
> {noformat}
> curl -D - -u admin:admin \
>   -H "Sling-Tracer-Record : true" \
>  -d "./jcr:content/jcr:title=Summer Collection" \
>  -d ":name=summer-collection" \
>  -d "./jcr:primaryType=sling:Folder" \
>  -d "./jcr:content/jcr:primaryType=nt:unstructured" \
>  -d "tracers=oak-writes" \
>  http://localhost:4802/content/dam/
> {noformat}
> # Server includes a request id as part of {{Sling-Tracer-Request-Id}} 
> response headers
> {noformat}
> HTTP/1.1 201 Created
> Date: Wed, 27 Jan 2016 07:30:22 GMT
> Sling-Tracer-Request-Id: 9b5b01f6-f269-47c3-a889-2dc8d4d7938f
> X-Content-Type-Options: nosniff
> X-Frame-Options: SAMEORIGIN
> Location: /content/dam/summer-collection
> Content-Type: text/html; charset=UTF-8
> Transfer-Encoding: chunked
> {noformat}
> # The logs in json format can then be fetched like 
> http://localhost:4802/system/console/tracer/9b5b01f6-f269-47c3-a889-2dc8d4d7938f.json
>  (see [attached output|^tracer-recording.json]. it includes following data 
> for now. It can be extended as per need
> ## RequestProgressTracker logs
> ## JCR Queries made
> Key points
> # Request id is randomly generated
> # The access to request log is via Web Console Plugin servlet hence its only 
> accessible to admin user account
> # The request data would only be recorded for those request which have the 
> {{​Sling-Tracer-Record}} header set. The data would be kept in memory for 
> *some time* with the assumption that client would fetch it soon. After some 
> time the data would expire
> # This feature would need to explicitly enabled via config option
> # The feature is somewhat similar to 'Recent Request' support. However it 
> exposes a JSON rendition and only keeps the data for request where client 
> requested that. 
> # For this feature dependency is added for Guava Cache to make use of space 
> bound/expiring cache. We can to an extent use {{LinkedHashMap}} but given 
> that Guava is now being used in Sling for Oak it makes sense to make use of 
> its feature. If required can look into embedding minimum required set



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

[jira] [Commented] (SLING-5459) Recording of tracer logs

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra commented on SLING-5459:


Opened SLING-5669 to track that

> Recording of tracer logs
> 
>
> Key: SLING-5459
> URL: https://issues.apache.org/jira/browse/SLING-5459
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: Log Tracer 1.0.0
>
> Attachments: SLING-5459-v1.patch, tracer-recording.json
>
>
> Sling Log Tracer currently provides support for fine grained control of 
> enabling logs for specific request. To make this log more accessible it would 
> be useful to have a feature where the client can also fetch the logs from 
> specific request over HTTP.
> This feature would work like below
> # Client sends an HTTP request with header {{Sling-Tracer-Record​}}  set to 
> true
> {noformat}
> curl -D - -u admin:admin \
>   -H "Sling-Tracer-Record : true" \
>  -d "./jcr:content/jcr:title=Summer Collection" \
>  -d ":name=summer-collection" \
>  -d "./jcr:primaryType=sling:Folder" \
>  -d "./jcr:content/jcr:primaryType=nt:unstructured" \
>  -d "tracers=oak-writes" \
>  http://localhost:4802/content/dam/
> {noformat}
> # Server includes a request id as part of {{Sling-Tracer-Request-Id}} 
> response headers
> {noformat}
> HTTP/1.1 201 Created
> Date: Wed, 27 Jan 2016 07:30:22 GMT
> Sling-Tracer-Request-Id: 9b5b01f6-f269-47c3-a889-2dc8d4d7938f
> X-Content-Type-Options: nosniff
> X-Frame-Options: SAMEORIGIN
> Location: /content/dam/summer-collection
> Content-Type: text/html; charset=UTF-8
> Transfer-Encoding: chunked
> {noformat}
> # The logs in json format can then be fetched like 
> http://localhost:4802/system/console/tracer/9b5b01f6-f269-47c3-a889-2dc8d4d7938f.json
>  (see [attached output|^tracer-recording.json]. it includes following data 
> for now. It can be extended as per need
> ## RequestProgressTracker logs
> ## JCR Queries made
> Key points
> # Request id is randomly generated
> # The access to request log is via Web Console Plugin servlet hence its only 
> accessible to admin user account
> # The request data would only be recorded for those request which have the 
> {{​Sling-Tracer-Record}} header set. The data would be kept in memory for 
> *some time* with the assumption that client would fetch it soon. After some 
> time the data would expire
> # This feature would need to explicitly enabled via config option
> # The feature is somewhat similar to 'Recent Request' support. However it 
> exposes a JSON rendition and only keeps the data for request where client 
> requested that. 
> # For this feature dependency is added for Guava Cache to make use of space 
> bound/expiring cache. We can to an extent use {{LinkedHashMap}} but given 
> that Guava is now being used in Sling for Oak it makes sense to make use of 
> its feature. If required can look into embedding minimum required set



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

[jira] [Resolved] (SLING-5507) Collect more details around query execution

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra resolved SLING-5507.

Resolution: Fixed

> Collect more details around query execution
> ---
>
> Key: SLING-5507
> URL: https://issues.apache.org/jira/browse/SLING-5507
> Project: Sling
>  Issue Type: Sub-task
>  Components: Extensions
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
>  Labels: docs-impacting
> Fix For: Log Tracer 1.0.0
>
>
> As part of response for queries following data should be collected
> # Source Class from where query was done - Make attempt to remove framework 
> layers!
> # Query Plan
> # Query duration if possible



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

[jira] [Updated] (SLING-5669) Restrict usage of log tracing feature with access control

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra updated SLING-5669:
---
Description: 
In SLING-5459 [~bdelacretaz] suggested that Tracer should provide a way to 
secure use of the tracing feature to specific user.

This can be done by having a specific path in content and check that current 
user has read permission on that path. This would ensure that feature can be 
more safely enabled. Note that even without this trace logs are only accessible 
to admin user only.

  was:
In SLING-5459 [~bdelacretaz] suggested that Tracer should provide a way to 
secure use of the tracing feature to specific user.

This can be done by having a specific path in content and check that current 
user has read permission on that path. This would ensure that feature can be 
more safely enabled


> Restrict usage of log tracing feature with access control
> -
>
> Key: SLING-5669
> URL: https://issues.apache.org/jira/browse/SLING-5669
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: Log Tracer 1.0.2
>
>
> In SLING-5459 [~bdelacretaz] suggested that Tracer should provide a way to 
> secure use of the tracing feature to specific user.
> This can be done by having a specific path in content and check that current 
> user has read permission on that path. This would ensure that feature can be 
> more safely enabled. Note that even without this trace logs are only 
> accessible to admin user only.



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

[jira] [Updated] (SLING-5669) Restrict usage of log tracing feature with access control

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra updated SLING-5669:
---
Fix Version/s: (was: Log Tracer 1.0.0)
   Log Tracer 1.0.2

> Restrict usage of log tracing feature with access control
> -
>
> Key: SLING-5669
> URL: https://issues.apache.org/jira/browse/SLING-5669
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: Log Tracer 1.0.2
>
>
> In SLING-5459 [~bdelacretaz] suggested that Tracer should provide a way to 
> secure use of the tracing feature to specific user.
> This can be done by having a specific path in content and check that current 
> user has read permission on that path. This would ensure that feature can be 
> more safely enabled



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

[jira] [Created] (SLING-5669) Restrict usage of log tracing feature with access control

[Chetan Mehrotra (JIRA)]

Chetan Mehrotra created SLING-5669:
--

 Summary: Restrict usage of log tracing feature with access control
 Key: SLING-5669
 URL: https://issues.apache.org/jira/browse/SLING-5669
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
 Fix For: Log Tracer 1.0.0


In SLING-5459 [~bdelacretaz] suggested that Tracer should provide a way to 
secure use of the tracing feature to specific user.

This can be done by having a specific path in content and check that current 
user has read permission on that path. This would ensure that feature can be 
more safely enabled



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

[jira] [Commented] (SLING-5638) Sling:alias property not working if user does not have read access to the root node

[Antonio Sanso (JIRA)]

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

Antonio Sanso commented on SLING-5638:
--

[~bdelacretaz] I have edited the wrong comment . Thanks for spotting.

I also removed the commented test. This was there and commented from long time 
(do not know why though)

> Sling:alias property not working if user does not have read access to the 
> root node
> ---
>
> Key: SLING-5638
> URL: https://issues.apache.org/jira/browse/SLING-5638
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Reporter: Antonio Sanso
>Assignee: Antonio Sanso
> Attachments: SLING-5638-patch.txt
>
>
> issue ;- Sling:alias property not working if user is having read only access 
> to /content folder.
> Steps :-
> 1) Login using admin/admin.
> 2) Create page say mypage.html and provide sling:alias property say 
> mypagealias.
> 3) Create test user and provide read only access on /content folder from 
> useradmin console.
> 4) log out from admin user.
> 5) Hit the page http://localhost:4502/content//mypage.html it 
> will ask for the login ( login as test user ) it opens the page
> 6) hit the alias page 
> http://localhost:4502/content//mypagealias.html - it wont work.
> sling:alias property get stored at jcr:content node for the page in /content, 
> so user with read access on /content should access it. please correct me in 
> case I am missing something.
> to make it work user has to give root( read only ) access to test user only 
> then test user can access alias page. 



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

[jira] [Comment Edited] (SLING-5638) Sling:alias property not working if user does not have read access to the root node

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz edited comment on SLING-5638 at 4/19/16 6:48 AM:
-

[~asanso] there's a commented out test_resolve_with_sling_alias_limited_access 
method in ResourceResolverTest, could you check and remove it if it's not 
needed anymore?

Also, there are comments like "//deny jcr:all on /content" and "//grant read on 
/content/child" in the active test method that don't match what's happening 
(the tests use /), please have a look.


was (Author: bdelacretaz):
[~asanso] there's a commented out test_resolve_with_sling_alias_limited_access 
method in ResourceResolverTest, could you check and remove it if it's not 
needed anymore?

> Sling:alias property not working if user does not have read access to the 
> root node
> ---
>
> Key: SLING-5638
> URL: https://issues.apache.org/jira/browse/SLING-5638
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Reporter: Antonio Sanso
>Assignee: Antonio Sanso
> Attachments: SLING-5638-patch.txt
>
>
> issue ;- Sling:alias property not working if user is having read only access 
> to /content folder.
> Steps :-
> 1) Login using admin/admin.
> 2) Create page say mypage.html and provide sling:alias property say 
> mypagealias.
> 3) Create test user and provide read only access on /content folder from 
> useradmin console.
> 4) log out from admin user.
> 5) Hit the page http://localhost:4502/content//mypage.html it 
> will ask for the login ( login as test user ) it opens the page
> 6) hit the alias page 
> http://localhost:4502/content//mypagealias.html - it wont work.
> sling:alias property get stored at jcr:content node for the page in /content, 
> so user with read access on /content should access it. please correct me in 
> case I am missing something.
> to make it work user has to give root( read only ) access to test user only 
> then test user can access alias page. 



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

[jira] [Commented] (SLING-5638) Sling:alias property not working if user does not have read access to the root node

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-5638:


[~asanso] there's a commented out test_resolve_with_sling_alias_limited_access 
method in ResourceResolverTest, could you check and remove it if it's not 
needed anymore?

> Sling:alias property not working if user does not have read access to the 
> root node
> ---
>
> Key: SLING-5638
> URL: https://issues.apache.org/jira/browse/SLING-5638
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Reporter: Antonio Sanso
>Assignee: Antonio Sanso
> Attachments: SLING-5638-patch.txt
>
>
> issue ;- Sling:alias property not working if user is having read only access 
> to /content folder.
> Steps :-
> 1) Login using admin/admin.
> 2) Create page say mypage.html and provide sling:alias property say 
> mypagealias.
> 3) Create test user and provide read only access on /content folder from 
> useradmin console.
> 4) log out from admin user.
> 5) Hit the page http://localhost:4502/content//mypage.html it 
> will ask for the login ( login as test user ) it opens the page
> 6) hit the alias page 
> http://localhost:4502/content//mypagealias.html - it wont work.
> sling:alias property get stored at jcr:content node for the page in /content, 
> so user with read access on /content should access it. please correct me in 
> case I am missing something.
> to make it work user has to give root( read only ) access to test user only 
> then test user can access alias page. 



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

[jira] [Commented] (SLING-5638) Sling:alias property not working if user does not have read access to the root node

[Antonio Sanso (JIRA)]

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

Antonio Sanso commented on SLING-5638:
--

enabled IT in r1739845 

> Sling:alias property not working if user does not have read access to the 
> root node
> ---
>
> Key: SLING-5638
> URL: https://issues.apache.org/jira/browse/SLING-5638
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Reporter: Antonio Sanso
>Assignee: Antonio Sanso
> Attachments: SLING-5638-patch.txt
>
>
> issue ;- Sling:alias property not working if user is having read only access 
> to /content folder.
> Steps :-
> 1) Login using admin/admin.
> 2) Create page say mypage.html and provide sling:alias property say 
> mypagealias.
> 3) Create test user and provide read only access on /content folder from 
> useradmin console.
> 4) log out from admin user.
> 5) Hit the page http://localhost:4502/content//mypage.html it 
> will ask for the login ( login as test user ) it opens the page
> 6) hit the alias page 
> http://localhost:4502/content//mypagealias.html - it wont work.
> sling:alias property get stored at jcr:content node for the page in /content, 
> so user with read access on /content should access it. please correct me in 
> case I am missing something.
> to make it work user has to give root( read only ) access to test user only 
> then test user can access alias page. 



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

[jira] [Commented] (SLING-5664) Models: OSGiServiceInjector does not consider service.ranking

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-5664:


And a followup commit in [r1739844|https://svn.apache.org/r1739844]

> Models: OSGiServiceInjector does not consider service.ranking
> -
>
> Key: SLING-5664
> URL: https://issues.apache.org/jira/browse/SLING-5664
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Sling Models Impl 1.2.6
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Sling Models Impl 1.2.8
>
> Attachments: SLING-5664-v01.patch
>
>
> The injector is using {{BundleContext.getServiceReferences(Class, String)}} 
> or {{SlingScriptHelper.getServices(Class, String)}} 
> (https://github.com/apache/sling/blob/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/injectors/OSGiServiceInjector.java#L97).
>  From the returned array it just takes the first item.
> Unfortunately the order in that array is not-deterministic, especially it is 
> not necessarily that way that items with a higher service.ranking are 
> returned first.



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

[jira] [Commented] (SLING-5638) Sling:alias property not working if user does not have read access to the root node

[Antonio Sanso (JIRA)]

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

Antonio Sanso commented on SLING-5638:
--

thanks [~cziegeler] . I have applied the patch in r1739843

> Sling:alias property not working if user does not have read access to the 
> root node
> ---
>
> Key: SLING-5638
> URL: https://issues.apache.org/jira/browse/SLING-5638
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Reporter: Antonio Sanso
>Assignee: Antonio Sanso
> Attachments: SLING-5638-patch.txt
>
>
> issue ;- Sling:alias property not working if user is having read only access 
> to /content folder.
> Steps :-
> 1) Login using admin/admin.
> 2) Create page say mypage.html and provide sling:alias property say 
> mypagealias.
> 3) Create test user and provide read only access on /content folder from 
> useradmin console.
> 4) log out from admin user.
> 5) Hit the page http://localhost:4502/content//mypage.html it 
> will ask for the login ( login as test user ) it opens the page
> 6) hit the alias page 
> http://localhost:4502/content//mypagealias.html - it wont work.
> sling:alias property get stored at jcr:content node for the page in /content, 
> so user with read access on /content should access it. please correct me in 
> case I am missing something.
> to make it work user has to give root( read only ) access to test user only 
> then test user can access alias page. 



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