Re: [VOTE] Release Apache Sling Models Impl 1.4.2

[Carsten Ziegeler]

+1

 

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

Re: [VOTE] Release Apache Sling Testing OSGi Mock 2.3.2, OSGi Mock 1.9.6, Sling Mock 2.2.10, Sling Mock 1.9.8

[Carsten Ziegeler]

+1

 

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

[jira] [Updated] (SLING-6849) Impersonation for group of users

[Krzysztof Watral (JIRA)]

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

Krzysztof Watral updated SLING-6849:

Component/s: (was: Authentication)

> Impersonation for group of users
> 
>
> Key: SLING-6849
> URL: https://issues.apache.org/jira/browse/SLING-6849
> Project: Sling
>  Issue Type: Improvement
>  Components: ResourceResolver
>Reporter: Krzysztof Watral
>  Labels: impersonation
>
> Currently we have two possibilities (which I know) to impersonate some 
> account as a different user:
> # First solution can be implemented in the following way:
> {code:java}
> Map authenticationInfo = Maps.newHashMap();
> authenticationInfo.put(ResourceResolverFactory.USER_IMPERSONATION, userId);
> resourceResolver = 
> resourceResolverFactory.getServiceResourceResolver(authenticationInfo);
> {code}
> it works, but adds a lot of effort for Administrators, they have to define 
> each user in list of possible impersonators (unfortunately this approach 
> doesn't support groups).
> # Second approach is to get user session using 
> SlingRepository.impersonateFroService:
> {code:java}
> slingRepository.impersonateFromService(null, credentials, null);
> {code}
> Unfortunately, this requires to pass userId and password, that is usually 
> impossible to get from programmatical point of view.
> To make life easier, it would be nice if one of the following suggestion 
> would be implemented:
>  - slingRepository.impersonateFromService(null, credentials, null); could 
> start accepting credentials without password
>  - impersonators could be configured for group of users



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

[jira] [Updated] (SLING-5965) Metrics and a Health-Check for Scheduler to detect long-running Quartz-Jobs

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-5965:

Fix Version/s: (was: Commons Scheduler 2.6.0)
   Commons Scheduler 2.6.2

> Metrics and a Health-Check for Scheduler to detect long-running Quartz-Jobs
> ---
>
> Key: SLING-5965
> URL: https://issues.apache.org/jira/browse/SLING-5965
> Project: Sling
>  Issue Type: New Feature
>  Components: Commons
>Affects Versions: Commons Scheduler 2.5.0
>Reporter: Stefan Egli
> Fix For: Commons Scheduler 2.6.2
>
> Attachments: SLING-5965.patch, SLING-5965.v2.patch.txt
>
>
> Sling Scheduler jobs (aka Quartz-Jobs) should typically be fast running jobs. 
> They are served from a thread-pool and should occupy that thread only for a 
> short amount of time.
> If there are 'misbehaving' quartz-jobs that run for a very long time, they 
> start to occupy threads from that thread-pool, thus have an influence on the 
> performance of other scheduled/quartz-jobs.
> We should have metrics (using 
> [sling.commons.metrics|https://sling.apache.org/documentation/bundles/metrics.html])
>  that provide information about internas of Sling Scheduler, such as average, 
> max etc duration of scheduled jobs, as well as how many jobs are currently 
> running and since when was the oldest job running.
> Based on this, a Health-Check can monitor the 'oldest job running' metric and 
> flag {{critical}} when eg the oldest job is older than {{60'000ms}} 
> (configurable, default).



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

[jira] [Commented] (SLING-6851) Karaf sling-extension-healthcheck feature doesn't start without healthcheck-api

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SLING-6851:
---

GitHub user bobpaulin opened a pull request:

https://github.com/apache/sling/pull/226

SLING-6851 - Add Healthcheck Api to healthcheck karaf feature.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bobpaulin/sling bug/SLING-6851

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/sling/pull/226.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #226


commit b23d398b788313395322b1b2d89720dd4ef83ce9
Author: Bob Paulin 
Date:   2017-05-12T03:30:14Z

SLING-6851 - Add Healthcheck Api to healthcheck karaf feature.




> Karaf sling-extension-healthcheck feature doesn't start without 
> healthcheck-api
> ---
>
> Key: SLING-6851
> URL: https://issues.apache.org/jira/browse/SLING-6851
> Project: Sling
>  Issue Type: Bug
>  Components: Karaf
>Reporter: Bob Paulin
>Priority: Minor
>
> The sling-extension-healthcheck feature doesn't start unless you install the 
> healthcheck-api.
> Suggest adding the api to the karaf feature.



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

[GitHub] sling pull request #226: SLING-6851 - Add Healthcheck Api to healthcheck kar...

[bobpaulin]

GitHub user bobpaulin opened a pull request:

https://github.com/apache/sling/pull/226

SLING-6851 - Add Healthcheck Api to healthcheck karaf feature.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bobpaulin/sling bug/SLING-6851

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/sling/pull/226.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #226


commit b23d398b788313395322b1b2d89720dd4ef83ce9
Author: Bob Paulin 
Date:   2017-05-12T03:30:14Z

SLING-6851 - Add Healthcheck Api to healthcheck karaf feature.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (SLING-6851) Karaf sling-extension-healthcheck feature doesn't start without healthcheck-api

[Bob Paulin (JIRA)]

Bob Paulin created SLING-6851:
-

 Summary: Karaf sling-extension-healthcheck feature doesn't start 
without healthcheck-api
 Key: SLING-6851
 URL: https://issues.apache.org/jira/browse/SLING-6851
 Project: Sling
  Issue Type: Bug
  Components: Karaf
Reporter: Bob Paulin
Priority: Minor


The sling-extension-healthcheck feature doesn't start unless you install the 
healthcheck-api.

Suggest adding the api to the karaf feature.



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

[jira] [Closed] (SLING-6844) Update to xss 1.0.18

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6844.
-

> Update to xss 1.0.18
> 
>
> Key: SLING-6844
> URL: https://issues.apache.org/jira/browse/SLING-6844
> Project: Sling
>  Issue Type: Bug
>  Components: XSS Protection API
>Reporter: Karl Pauls
>Assignee: Karl Pauls
> Fix For: XSS Protection API Compat 1.1.0
>
>
> We need to update the xss.compat bundle to the latest released xss 1.0.18 tag 
>  - the released version 1.0.0 wasn't on the latest tag by accident. 



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

Re: [RESULT] [Vote] Apache Sling XSS Protection Compat Bundle version 1.1.0

[Karl Pauls]

Time to call the vote on the Apache Sling XSS Protection Compat Bundle
version 1.1.0 release.

* +1 votes from Carsten Ziegeler, Daniel Klco, and Karl Pauls.

* No other votes.

The vote is successful. I will make the release artifacts available as
soon as possible.

Re: [Vote] Apache Sling XSS Protection Compat Bundle version 1.1.0

[Karl Pauls]

+1

regards,

Karl

On Mon, May 8, 2017 at 7:18 PM, Daniel Klco  wrote:
> +1
>
> On Mon, May 8, 2017 at 10:46 AM, Carsten Ziegeler 
> wrote:
>
>> +1
>>
>>
>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
>>



-- 
Karl Pauls
karlpa...@gmail.com

[jira] [Closed] (SLING-6668) Remove embedded Rhino from bundle

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6668.
-

> Remove embedded Rhino from bundle
> -
>
> Key: SLING-6668
> URL: https://issues.apache.org/jira/browse/SLING-6668
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Affects Versions: Scripting JavaScript 2.0.30
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Scripting JavaScript 3.0.0
>
> Attachments: SLING-6668.patch
>
>
> Scripting JavaScript should use bundle 
> {{org.apache.servicemix.bundles.rhino}} ({{1.7.7.1_1}}) instead.



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

[jira] [Closed] (SLING-6751) Migrate to OSGi R6 annotations

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6751.
-

> Migrate to OSGi R6 annotations
> --
>
> Key: SLING-6751
> URL: https://issues.apache.org/jira/browse/SLING-6751
> Project: Sling
>  Issue Type: Task
>  Components: Scripting
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Scripting JavaScript 3.0.0
>
>




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

[jira] [Closed] (SLING-6682) Replace commons.json usage in org.apache.sling.scripting.javascript

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6682.
-

> Replace commons.json usage in org.apache.sling.scripting.javascript
> ---
>
> Key: SLING-6682
> URL: https://issues.apache.org/jira/browse/SLING-6682
> Project: Sling
>  Issue Type: Sub-task
>  Components: Scripting
>Affects Versions: Scripting JavaScript 2.0.30
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>  Labels: patch-available
> Fix For: Scripting JavaScript 3.0.0
>
> Attachments: SLING-6682.patch
>
>




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

[jira] [Closed] (SLING-6644) Add extensions, mime types and names to RhinoJavaScriptEngineFactory's component properties

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6644.
-

> Add extensions, mime types and names to RhinoJavaScriptEngineFactory's 
> component properties
> ---
>
> Key: SLING-6644
> URL: https://issues.apache.org/jira/browse/SLING-6644
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Scripting JavaScript 3.0.0
>
>
> allows filtering {{ScriptEngineFactory}} services by extension, mime type and 
> name
> extensions: {{ecma}}, {{esp}}
> mime types: {{text/javascript}}, {{application/ecmascript}}, 
> {{application/javascript}}
> names: {{javascript}}, {{JavaScript}}, {{ecmascript}}, {{ECMAScript}}



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

Re: [RESULT] [VOTE] Apache Sling Scripting JavaScript 3.0.0 release

[Karl Pauls]

Time to call the vote on the Apache Sling Scripting JavaScript 3.0.0 release.

* +1 votes from Carsten Ziegeler, Stefan Seifert, Daniel Klco, and Karl Pauls.

* No other votes.

The vote is successful. I will make the release artifacts available as
soon as possible.

Re: [VOTE] Apache Sling Scripting JavaScript 3.0.0 release

[Karl Pauls]

+1

regards,

Karl

On Mon, May 8, 2017 at 9:39 PM, Daniel Klco  wrote:
> +1
>
> On Mon, May 8, 2017 at 10:37 AM, Stefan Seifert 
> wrote:
>
>> +1
>>
>>



-- 
Karl Pauls
karlpa...@gmail.com

[jira] [Resolved] (SLING-6804) Request to allow the health check servlet to directly query a single health check by name

[Justin Edelson (JIRA)]

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

Justin Edelson resolved SLING-6804.
---
Resolution: Fixed

fixed in r1794887 

Change is basically the patch attached plus the ability to pass both names and 
tags in the path, using the heuristic defined by [~henzlerg]

> Request to allow the health check servlet to directly query a single health 
> check by name
> -
>
> Key: SLING-6804
> URL: https://issues.apache.org/jira/browse/SLING-6804
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check
>Reporter: Clinton H Goudie-Nice
>Assignee: Justin Edelson
>Priority: Minor
> Fix For: Health Check Core 1.2.10, Health Check API 1.0.2
>
> Attachments: SLING-6804-allow-hc.name-in-hc-urls-simple.patch, 
> SLING-6804.diff
>
>
> AMS has a request to be able to access an individual health check by name
> For example: 
> http://localhost:4502/system/health/named/Sling%20Get%20Servlet.json
> And have it return the results for only this named health check.



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

[jira] [Updated] (SLING-6804) Request to allow the health check servlet to directly query a single health check by name

[Justin Edelson (JIRA)]

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

Justin Edelson updated SLING-6804:
--
Fix Version/s: Health Check API 1.0.2
   Health Check Core 1.2.10

> Request to allow the health check servlet to directly query a single health 
> check by name
> -
>
> Key: SLING-6804
> URL: https://issues.apache.org/jira/browse/SLING-6804
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check
>Reporter: Clinton H Goudie-Nice
>Assignee: Justin Edelson
>Priority: Minor
> Fix For: Health Check Core 1.2.10, Health Check API 1.0.2
>
> Attachments: SLING-6804-allow-hc.name-in-hc-urls-simple.patch, 
> SLING-6804.diff
>
>
> AMS has a request to be able to access an individual health check by name
> For example: 
> http://localhost:4502/system/health/named/Sling%20Get%20Servlet.json
> And have it return the results for only this named health check.



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

[jira] [Closed] (SLING-6757) Replace commons.json usage in org.apache.sling.testing.tools

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6757.
-

> Replace commons.json usage in org.apache.sling.testing.tools
> 
>
> Key: SLING-6757
> URL: https://issues.apache.org/jira/browse/SLING-6757
> Project: Sling
>  Issue Type: Sub-task
>  Components: Testing
>Affects Versions: org.apache.sling.testing.tools 1.0.14
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
> Fix For: org.apache.sling.testing.tools 1.0.16
>
>




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

[jira] [Closed] (SLING-6565) Teleporter: Improve bundle names to prevent conflicts in case of uninstall failures

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6565.
-

> Teleporter: Improve bundle names to prevent conflicts in case of uninstall 
> failures
> ---
>
> Key: SLING-6565
> URL: https://issues.apache.org/jira/browse/SLING-6565
> Project: Sling
>  Issue Type: Improvement
>  Components: Apache Sling Testing Rules
>Affects Versions: JUnit Tests Teleporter 1.0.12
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Minor
> Fix For: JUnit Tests Teleporter 1.0.14
>
>
> Currently each test bundle gets a unique symbolic name 
> (https://github.com/apache/sling/blob/trunk/testing/junit/teleporter/src/main/java/org/apache/sling/testing/teleporter/client/ClientSideTeleporter.java#L245).
>  That means that in case of uninstallation failures there might be multiple 
> bundles on the same server providing the same JUnit tests. Since it is then 
> not deterministic which bundle is used for executing the test the bundle 
> names should be always the same for the same test class.
> The only thing one needs to prevent is parallel execution of those JUnit 
> tests, because each bundle is deployed separately for each test method. If 
> this happens in parallel it may be that one bundle is just uninstalled, while 
> still being in use by he next test. This is a problem already with the 
> current approach, as you cannot tell which bundle is used for executing the 
> test.



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

[jira] [Closed] (SLING-6758) Replace commons.json usage in org.apache.sling.junit.core

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6758.
-

> Replace commons.json usage in org.apache.sling.junit.core
> -
>
> Key: SLING-6758
> URL: https://issues.apache.org/jira/browse/SLING-6758
> Project: Sling
>  Issue Type: Sub-task
>  Components: Testing
>Affects Versions: JUnit Core 1.0.23
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
> Fix For: JUnit Core 1.0.24
>
>




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

Re: [RESULT][VOTE] Apache Sling Junit Core 1.0.24, Junit Teleporter 1.0.14, and Testing Tools 1.0.16 releases

[Karl Pauls]

Time to call the vote on the Apache Sling Junit Core 1.0.24, Junit
Teleporter 1.0.14, and Testing Tools 1.0.16 releases.

* +1 votes from Carsten Ziegeler, Stefan Seifert, Daniel Klco, and Karl Pauls.

* No other votes.

The vote is successful. I will make the release artifacts available as
soon as possible.

Re: [VOTE] Apache Sling Junit Core 1.0.24, Junit Teleporter 1.0.14, and Testing Tools 1.0.16 releases

[Karl Pauls]

+1

regards,

Karl

On Mon, May 8, 2017 at 9:27 PM, Daniel Klco  wrote:
> +1
>
> On Mon, May 8, 2017 at 10:33 AM, Stefan Seifert 
> wrote:
>
>> +1
>>
>>
>>



-- 
Karl Pauls
karlpa...@gmail.com

[jira] [Closed] (SLING-6815) Allow for suppression of warning about adapter classes being in private packages

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6815.
-

> Allow for suppression of warning about adapter classes being in private 
> packages
> 
>
> Key: SLING-6815
> URL: https://issues.apache.org/jira/browse/SLING-6815
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Adapter 2.1.10, Sling Models Impl 1.4.2
>
>
> Issue SLING-6658 exposed (at least for me) that while the warning about 
> adapter classes being in private packages is helpful, there is no way to 
> suppress it when done intentionally. In the case of Sling Model classes, post 
> SLING-6658, there is a need for a way to suppress this warning.



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

[jira] [Closed] (SLING-6687) Replace commons.json usage in org.apache.sling.adapter

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6687.
-

> Replace commons.json usage in org.apache.sling.adapter
> --
>
> Key: SLING-6687
> URL: https://issues.apache.org/jira/browse/SLING-6687
> Project: Sling
>  Issue Type: Sub-task
>  Components: Extensions
>Affects Versions: Adapter 2.1.8
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>  Labels: patch-available
> Fix For: Adapter 2.1.10
>
> Attachments: SLING-6687.patch
>
>




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

Re: [RESULT][VOTE] Apache Sling Adapter 2.1.10 release

[Karl Pauls]

Time to call the vote on the Apache Sling Adapter 2.1.10 release.

* +1 votes from Carsten Ziegeler, Stefan Seifert, Daniel Klco, and Karl Pauls.

* No other votes.

The vote is successful. I will make the release artifacts available as
soon as possible.

Re: [VOTE] Apache Sling Adapter 2.1.10 release

[Karl Pauls]

+1

regards,

Karl

On Mon, May 8, 2017 at 9:00 PM, Daniel Klco  wrote:
> +1
>
> On Mon, May 8, 2017 at 10:29 AM, Stefan Seifert 
> wrote:
>
>> +1
>>
>>



-- 
Karl Pauls
karlpa...@gmail.com

[jira] [Closed] (SLING-6721) Migrate to R6 annotations, clean up dependencies

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6721.
-

> Migrate to R6 annotations, clean up dependencies
> 
>
> Key: SLING-6721
> URL: https://issues.apache.org/jira/browse/SLING-6721
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Servlets Post 2.3.16
>
>




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

[jira] [Closed] (SLING-6704) Migrate to R6 annotations, clean up dependencies

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6704.
-

> Migrate to R6 annotations, clean up dependencies
> 
>
> Key: SLING-6704
> URL: https://issues.apache.org/jira/browse/SLING-6704
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Servlets Get 2.1.24
>
>




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

[jira] [Closed] (SLING-6452) Update / Clean access manager project

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6452.
-

> Update / Clean access manager project
> -
>
> Key: SLING-6452
> URL: https://issues.apache.org/jira/browse/SLING-6452
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: JCR Jackrabbit Access Manager 3.0.0
>
>




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

[jira] [Closed] (SLING-6722) Deprecate AbstractPostOperation

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6722.
-

> Deprecate AbstractPostOperation
> ---
>
> Key: SLING-6722
> URL: https://issues.apache.org/jira/browse/SLING-6722
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Servlets Post 2.3.16
>
>
> The abstract class AbstractPostOperation is using javax.jcr api and therefore 
> creates a mixture between Sling's resource API and the JCR api. As we should 
> provide clear guidance to our clients, we should avoid this mixture.
> Therefore we should deprecate this class



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

[jira] [Closed] (SLING-6703) Sling Post Servlet: Do not hide original exception in AbstractPostResponse.setError

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6703.
-

> Sling Post Servlet: Do not hide original exception in 
> AbstractPostResponse.setError
> ---
>
> Key: SLING-6703
> URL: https://issues.apache.org/jira/browse/SLING-6703
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Affects Versions: Servlets Post 2.3.14
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Servlets Post 2.3.16
>
>
> Currently {{AbstractPostResponse.setError}} 
> (https://github.com/apache/sling/blob/4df9ab2d6592422889c71fa13afd453a10a5a626/bundles/servlets/post/src/main/java/org/apache/sling/servlets/post/AbstractPostResponse.java#L221)
>  always ignores the given {{Throwable}} and just creates a new generic 
> {{SlingException}}.
> To e.g. allow {{SlingPostProcessor}} to throw meaningful exceptions which 
> occur in the response body, the given exception should not be wrapped but 
> just the given throwable's message text should be given out in the document.



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

[jira] [Closed] (SLING-6790) Enable aliases even if referenced format is disabled

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6790.
-

> Enable aliases even if referenced format is disabled
> 
>
> Key: SLING-6790
> URL: https://issues.apache.org/jira/browse/SLING-6790
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Servlets Get 2.1.24
>
>
> When one of the default renderings is disabled and an alias exists for this, 
> the alias rendering is disabled as well. For example, it is common to have 
> the PDF rendering as an alias for XML (as the PDF rendering is based on using 
> an XML pipeline including XSLT to generate PDF). If XML is disabled, PDF 
> doesn't work either and right now, the only way to get PDF rendering work is 
> enabling XML as well. Which might not be what you want.
> So I think, if an alias exists - which is an explicit  configuration - this 
> should be enabled, regardless whether the underlying direct rendering is 
> disabled.



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

[jira] [Closed] (SLING-6684) Replace commons.json usage in org.apache.sling.jcr.jackrabbit.accessmanager

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6684.
-

> Replace commons.json usage in org.apache.sling.jcr.jackrabbit.accessmanager
> ---
>
> Key: SLING-6684
> URL: https://issues.apache.org/jira/browse/SLING-6684
> Project: Sling
>  Issue Type: Sub-task
>  Components: JCR
>Affects Versions: JCR Jackrabbit Access Manager 2.1.2
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>  Labels: patch-available
> Fix For: JCR Jackrabbit Access Manager 3.0.0
>
> Attachments: SLING-6684-2.patch, SLING-6684.patch
>
>
> This bundle has no tests so it is hard to say if stuff works. 



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

[jira] [Closed] (SLING-6723) Make dependency to javax.jcr, jcr.contentloader and jcr.api optional

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6723.
-

> Make dependency to javax.jcr, jcr.contentloader and jcr.api optional
> 
>
> Key: SLING-6723
> URL: https://issues.apache.org/jira/browse/SLING-6723
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Servlets Post 2.3.16
>
>
> In order to be able to run Sling in a very minimal version, the dependencies 
> to javax.jcr, jcr.api and jcr.contentloader should be optional. Otherwise a 
> whole set of modules needs to be dragged in just to make the servlets post 
> module provide the basic functionality (which is usually sufficient for most 
> applications)
> It seems with minimizing the dependency to JCR we can also clean up the code 
> as it is quiet of often adapting to JCR objects for no real reason and in 
> some cases mixing resource and node handling, where just sticking with one or 
> the other would do less operations



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

[jira] [Closed] (SLING-6681) Replace commons.json usage in org.apache.sling.servlets.post

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6681.
-

> Replace commons.json usage in org.apache.sling.servlets.post
> 
>
> Key: SLING-6681
> URL: https://issues.apache.org/jira/browse/SLING-6681
> Project: Sling
>  Issue Type: Sub-task
>  Components: Servlets
>Affects Versions: Servlets Post 2.3.14
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>  Labels: patch-available
> Fix For: Servlets Post 2.3.16
>
> Attachments: SLING-6681-2.patch, SLING-6681.patch
>
>




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

[jira] [Closed] (SLING-6720) Deprecate PostResponseWithErrorHandling

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6720.
-

> Deprecate PostResponseWithErrorHandling
> ---
>
> Key: SLING-6720
> URL: https://issues.apache.org/jira/browse/SLING-6720
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Servlets Post 2.3.16
>
>
> As part of SLING-2156 PostResponseWithErrorHandling has been added to the 
> public API, however as this is a component I think it should have never been 
> added to the API, but just the impl.
> Therefore we should move it to the impl and deprecate it in the API



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

[jira] [Closed] (SLING-6787) HTMLRendererServlet shoud properly encode output

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6787.
-

> HTMLRendererServlet shoud properly encode output
> 
>
> Key: SLING-6787
> URL: https://issues.apache.org/jira/browse/SLING-6787
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Affects Versions: Servlets Get 2.1.18
>Reporter: Alex COLLIGNON
>Assignee: Carsten Ziegeler
> Fix For: Servlets Get 2.1.24
>
> Attachments: 
> 0001-SLING-6787-HTMLRendererServlet-shoud-properly-encode.patch
>
>
> Some of the values rendered by HTMLRendererServlet can be (better) encoded.



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

[jira] [Closed] (SLING-6187) Validate that @-based postfix parameters are removed from the POST modification set before committing

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6187.
-

> Validate that @-based postfix parameters are removed from the POST 
> modification set before committing
> -
>
> 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
>
> Attachments: SLING-6187c.diff, SLING-6187.patch, 
> SLING-6187-profile.diff, SLING-6187-profile.diff, SLING-6187-validating.diff
>
>
> 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.15#6346)

[jira] [Closed] (SLING-6705) Make use of java.jcr api optional

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6705.
-

> Make use of java.jcr api optional
> -
>
> Key: SLING-6705
> URL: https://issues.apache.org/jira/browse/SLING-6705
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Servlets Get 2.1.24
>
>
> In order to reduce the required dependencies to run a minimal Sling we should 
> make the dependency to JCR optional



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

[jira] [Closed] (SLING-6064) Redirect servlet should encode url for redirecting

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6064.
-

> Redirect servlet should encode url for redirecting
> --
>
> Key: SLING-6064
> URL: https://issues.apache.org/jira/browse/SLING-6064
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Get 2.1.18
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Servlets Get 2.1.24
>
>
> The RedirectServlet is directly setting the location header (wondering why 
> sendRedirect is not used instead?) however it is not encoding the URL 
> (calling encodeRedirectURL). Therefore if query parameters are appended these 
> are not encoded. According to the servlet spec, the url should be encoded 
> before being passed to sendRedirect. I would assume the same applies to 
> setting the header as it goes in there unmodified



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

[jira] [Closed] (SLING-6715) SlingInfoServlet is overengineered

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6715.
-

> SlingInfoServlet is overengineered
> --
>
> Key: SLING-6715
> URL: https://issues.apache.org/jira/browse/SLING-6715
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Servlets Get 2.1.24
>
>
> The SlingInfoServlet is a little bit overengineered. It is using an 
> extensible provider concept, however the provider interface is private, there 
> is only a single implementation and in fact this is not extensible at all.



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

[jira] [Closed] (SLING-6743) Drop workspace support

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6743.
-

> Drop workspace support
> --
>
> Key: SLING-6743
> URL: https://issues.apache.org/jira/browse/SLING-6743
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Servlets Post 2.3.16
>
>
> We dropped workspace support from most other modules long time ago, it seems 
> we missed the servlets post module. We should remove it here as well as it is 
> not needed anymore.



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

[jira] [Closed] (SLING-6683) Replace commons.json usage in org.apache.sling.servlets.get

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6683.
-

> Replace commons.json usage in org.apache.sling.servlets.get
> ---
>
> Key: SLING-6683
> URL: https://issues.apache.org/jira/browse/SLING-6683
> Project: Sling
>  Issue Type: Sub-task
>  Components: Servlets
>Affects Versions: Servlets Get 2.1.20
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>  Labels: patch-available
> Fix For: Servlets Get 2.1.24
>
> Attachments: SLING-6683-2.patch, SLING-6683.patch
>
>
> We need to replace the usage of commons.json but this one does heavy rely on 
> some of the helper classes. Its going to be tricky to make sure it still 
> works as intended.



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

Re: [VOTE] Release Apache Sling Testing OSGi Mock 2.3.2, OSGi Mock 1.9.6, Sling Mock 2.2.10, Sling Mock 1.9.8

[Daniel Klco]

+1

On Thu, May 11, 2017 at 9:29 AM, Stefan Seifert 
wrote:

> +1
>
>
>

Re: [RESULT][VOTE] Apache Sling Servlets Get 2.1.24, Servlets Post 2.3.16, and JCR Jackrabbit Access Manager 3.0.0 releases

[Karl Pauls]

Time to call the vote on the Apache Sling Servlets Get 2.1.24,
Servlets Post 2.3.16, and JCR Jackrabbit Access Manager 3.0.0
releases.

* +1 votes from Carsten Ziegeler, Stefan Seifert, Daniel Klco, and Karl Pauls.

* No other votes.

The vote is successful. I will make the release artifacts available as
soon as possible.

Re: [VOTE] Apache Sling Servlets Get 2.1.24, Servlets Post 2.3.16, and JCR Jackrabbit Access Manager 3.0.0 releases

[Karl Pauls]

+1

regards,

Karl

On Mon, May 8, 2017 at 8:49 PM, Daniel Klco  wrote:
> +1
>
> On Mon, May 8, 2017 at 10:27 AM, Stefan Seifert 
> wrote:
>
>> +1
>>
>>



-- 
Karl Pauls
karlpa...@gmail.com

[GitHub] sling pull request #225: Adds missing assignment of name in MockRequestParam...

[Obirah]

GitHub user Obirah opened a pull request:

https://github.com/apache/sling/pull/225

Adds missing assignment of name in MockRequestParameter.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Obirah/sling mock-request-param

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/sling/pull/225.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #225


commit 25a15ec7c164f90278de9568e63a485d20897271
Author: Thomas Krause 
Date:   2017-05-11T18:49:56Z

Adds missing assignment of name in MockRequestParameter.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (SLING-6850) Address Launchpad homepage information architecture

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-6850:
---

definitely better than the old one - i'm fine with it.
the login/logout link should perhaps be somewhat separate from the "resources" 
list because it's more an action than a link.

> Address Launchpad homepage information architecture
> ---
>
> Key: SLING-6850
> URL: https://issues.apache.org/jira/browse/SLING-6850
> Project: Sling
>  Issue Type: Improvement
>Reporter: Chris Millar
>Priority: Minor
> Attachments: Launchpad - Current Design.png, Launchpad - Proposed 
> Design.png
>
>
> The launchpad homepage could use some love...
> # The page is not responsive.
> # Design is dated.
> # The page has several links that are either out of date (composum always 
> installed now), repeated (OSGi console), or not helpful (sign up).
> # Does not speak to audiences of different skill levels.
> *My proposal addresses these concerns with the following updates:*
> # Page is responsive
> # Page is designed to address three audiences:
> ## Brand new developer - Why did I just type `java -jar org.apache.sling`?
> ## Experienced developer - Give me a list of the guts in this site / app. 
> Give me external resources to help keep me going.
> ## Potential Contributor - How do I get involved?
> # Bad / duplicated / unused links have been removed. - I'm looking at you 
> signup page and client test page (which 500s in snapshot).
> # Apache logo has been added.
> # Retained most of the excellent welcome text (with updated links to Oak and 
> Felix).
> # Friendlier colors have been used.
> # Custom font (Open Sans, AL 2.0) has been used instead of Tahoma (not AL 2.0)
> # Slightly larger typography to meet current trends.
> # Used old yellow / blue horizontal rule as the design inspiration for the 
> left rail rule (that uses feather color palette).
> # Built out concise list of top resources for both the current site as well 
> as external resources.
> *Items worth discussing:*
> # Should the first heading under "Resources" be "This Site" or "This 
> Application"?
> # Should the HTL REPL be included in the list of links.
> # Should the Bootstrap clientlibs (used in HTL REPL) be used to build the 
> page even though they are MIT? If not, should we refactor the clientlibs 
> folder so REPL can be self contained and other libraries can also use 
> /etc/clientlibs?
> ## I have a flexbox based grid system I'd be willing to donate / use / 
> document.
> # Other things I'm not thinking of that may be contentious...



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

[jira] [Created] (SLING-6850) Address Launchpad homepage information architecture

[Chris Millar (JIRA)]

Chris Millar created SLING-6850:
---

 Summary: Address Launchpad homepage information architecture
 Key: SLING-6850
 URL: https://issues.apache.org/jira/browse/SLING-6850
 Project: Sling
  Issue Type: Improvement
Reporter: Chris Millar
Priority: Minor
 Attachments: Launchpad - Current Design.png, Launchpad - Proposed 
Design.png

The launchpad homepage could use some love...

# The page is not responsive.
# Design is dated.
# The page has several links that are either out of date (composum always 
installed now), repeated (OSGi console), or not helpful (sign up).
# Does not speak to audiences of different skill levels.

*My proposal addresses these concerns with the following updates:*
# Page is responsive
# Page is designed to address three audiences:
## Brand new developer - Why did I just type `java -jar org.apache.sling`?
## Experienced developer - Give me a list of the guts in this site / app. Give 
me external resources to help keep me going.
## Potential Contributor - How do I get involved?
# Bad / duplicated / unused links have been removed. - I'm looking at you 
signup page and client test page (which 500s in snapshot).
# Apache logo has been added.
# Retained most of the excellent welcome text (with updated links to Oak and 
Felix).
# Friendlier colors have been used.
# Custom font (Open Sans, AL 2.0) has been used instead of Tahoma (not AL 2.0)
# Slightly larger typography to meet current trends.
# Used old yellow / blue horizontal rule as the design inspiration for the left 
rail rule (that uses feather color palette).
# Built out concise list of top resources for both the current site as well as 
external resources.

*Items worth discussing:*
# Should the first heading under "Resources" be "This Site" or "This 
Application"?
# Should the HTL REPL be included in the list of links.
# Should the Bootstrap clientlibs (used in HTL REPL) be used to build the page 
even though they are MIT? If not, should we refactor the clientlibs folder so 
REPL can be self contained and other libraries can also use /etc/clientlibs?
## I have a flexbox based grid system I'd be willing to donate / use / document.
# Other things I'm not thinking of that may be contentious...



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

Re: [VOTE] new apache sling logo (provided by chris millar)

[Suren Konathala]

+1

On Thu, May 11, 2017 at 10:57 AM, Robert Munteanu 
wrote:

> Perhaps you should add in a stray  or  tag, just in
> case someone (like me) feels the need to make their mark and ask for a
> change ;-)
>
> But other than that looking forward to the redesign.
>
> Robert
>
> On Thu, 2017-05-11 at 09:01 -0600, Chris Millar wrote:
> > @rombert
> >
> > Thanks for leveling my expectations on the launchpad home page
> > redesign I'm about to submit.
> >
> > > On May 11, 2017, at 12:50 AM, Robert Munteanu 
> > > wrote:
> > >
> > > > On Wed, 2017-05-10 at 14:22 +, Stefan Seifert wrote:
> > > > Please vote to approve this new logo:
> > >
> > > +1
> > >
> > > (And yay for consensus on something UI-related :-) )
> > >
> > > Robert
>
>

[jira] [Closed] (SLING-6822) Health Check HTML Output puts "Finished At" under "Execution Time" column

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6822.
-

> Health Check HTML Output puts "Finished At" under "Execution Time" column
> -
>
> Key: SLING-6822
> URL: https://issues.apache.org/jira/browse/SLING-6822
> Project: Sling
>  Issue Type: Bug
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Health Check Core 1.2.8
>
>
> The HTML table includes both "Finished At" and "Execution Time" under the 
> "Execution Time" table header. There should be a separate header for 
> "Finished At".



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

[jira] [Closed] (SLING-6803) Sling health check servlet does not respond to a query for .json or .html on it's root relative path

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6803.
-

> Sling health check servlet does not respond to a query for .json or .html on 
> it's root relative path
> 
>
> Key: SLING-6803
> URL: https://issues.apache.org/jira/browse/SLING-6803
> Project: Sling
>  Issue Type: Bug
>  Components: Health Check
>Reporter: Clinton H Goudie-Nice
>Assignee: Justin Edelson
>Priority: Minor
> Fix For: Health Check Core 1.2.8
>
>
> After binding the health check servlet to a URI, such as /system/health:
> Executing http://localhost:4502/system/health/security.json works as expected 
> and returns json, however http://localhost:4502/system/health.json does not 
> return json.
> In order to obtain the full list in json, you need to either query 
> http://localhost:4502/system/health/.json or 
> http://localhost:4502/system/health?format=json
> I expect that /system/health.json should also work. 



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

[jira] [Closed] (SLING-6773) Separate HeathCheck API from Implementation

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6773.
-

> Separate HeathCheck API from Implementation
> ---
>
> Key: SLING-6773
> URL: https://issues.apache.org/jira/browse/SLING-6773
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check
>Affects Versions: Health Check Core 1.2.6
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Health Check Core 1.2.8, Health Check API 1.0.0
>
> Attachments: SLING-6773.diff
>
>
> Currently, the HealthCheck API and implementation are bundled together in one 
> bundle. In order for implementors of HealthChecks to only need to depend upon 
> a minimal dependency, we should package the API separately.



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

[jira] [Closed] (SLING-6693) Replace commons.json usage in org.apache.sling.hc.core

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6693.
-

> Replace commons.json usage in org.apache.sling.hc.core
> --
>
> Key: SLING-6693
> URL: https://issues.apache.org/jira/browse/SLING-6693
> Project: Sling
>  Issue Type: Sub-task
>  Components: Health Check
>Affects Versions: Health Check Core 1.2.6
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>  Labels: patch-available
> Fix For: Health Check Core 1.2.8
>
> Attachments: SLING-6693.patch
>
>




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

[jira] [Closed] (SLING-6806) Health Check servlet does not show associated tags in the html or json

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6806.
-

> Health Check servlet does not show associated tags in the html or json
> --
>
> Key: SLING-6806
> URL: https://issues.apache.org/jira/browse/SLING-6806
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check
>Reporter: Clinton H Goudie-Nice
>Assignee: Justin Edelson
>Priority: Minor
> Fix For: Health Check Core 1.2.8
>
>
> From the health check servlet, you cannot determine what tags are associated 
> with a given health check. You can visit the system console itself, but it 
> seems this information should be presented here.



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

[jira] [Closed] (SLING-6834) Introduce a new, verbose and text-based output format that can be used for console based applications

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6834.
-

> Introduce a new, verbose and text-based output format that can be used for 
> console based applications
> -
>
> Key: SLING-6834
> URL: https://issues.apache.org/jira/browse/SLING-6834
> Project: Sling
>  Issue Type: New Feature
>  Components: Health Check
>Affects Versions: Health Check Core 1.2.6
>Reporter: Georg Henzler
>Assignee: Georg Henzler
> Fix For: Health Check Core 1.2.8
>
>
> For both Jenkins pipelines and Docker container setups it would be nice to 
> have a simple text based response format that can be printed to the log (to 
> have them include more verbose information). 
> The existing formats html and json are not very readable in a log file, the 
> existing format txt is only printing OK, WARN or CRITICAL (minimised response 
> entity optimised for load balancer usage). 
> I would propose to add a new format {{.verbose.txt}} (was intially 
> {{exttxt}}). 



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

Re: [VOTE] new apache sling logo (provided by chris millar)

[Robert Munteanu]

Perhaps you should add in a stray  or  tag, just in
case someone (like me) feels the need to make their mark and ask for a
change ;-)

But other than that looking forward to the redesign.

Robert

On Thu, 2017-05-11 at 09:01 -0600, Chris Millar wrote:
> @rombert
> 
> Thanks for leveling my expectations on the launchpad home page
> redesign I'm about to submit.
> 
> > On May 11, 2017, at 12:50 AM, Robert Munteanu 
> > wrote:
> > 
> > > On Wed, 2017-05-10 at 14:22 +, Stefan Seifert wrote:
> > > Please vote to approve this new logo:
> > 
> > +1
> > 
> > (And yay for consensus on something UI-related :-) )
> > 
> > Robert

Re: [RESULT] [VOTE] Apache Sling Health Check API 1.0.0 and Core 1.2.8 releases

[Karl Pauls]

Time to call the vote on the Apache Sling Health Check API 1.0.0 and
Core 1.2.8 releases.

* +1 votes from Georg Henzler, Carsten Ziegeler, Stefan Egli, Stefan
Seifert, Daniel Klco, and Karl Pauls.

* No other votes.

The vote is successful. I will make the release artifacts available as
soon as possible.

Re: [VOTE] Apache Sling Health Check API 1.0.0 and Core 1.2.8 releases

[Karl Pauls]

+1

regards,

Karl

On Mon, May 8, 2017 at 8:47 PM, Daniel Klco  wrote:
> +1
>
> On Mon, May 8, 2017 at 10:23 AM, Stefan Seifert 
> wrote:
>
>> +1
>>
>>



-- 
Karl Pauls
karlpa...@gmail.com

[jira] [Closed] (SLING-6837) Migrate to R6 annotations

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6837.
-

> Migrate to R6 annotations
> -
>
> Key: SLING-6837
> URL: https://issues.apache.org/jira/browse/SLING-6837
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Discovery Commons 1.0.20
>
>




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

[jira] [Closed] (SLING-6836) Use Timer instead of scheduler for delayed execution

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6836.
-

> Use Timer instead of scheduler for delayed execution
> 
>
> Key: SLING-6836
> URL: https://issues.apache.org/jira/browse/SLING-6836
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Discovery Commons 1.0.20
>
>
> The InitDelayingTopologyEventListener currently uses a scheduler to schedule 
> the delay. However this creates a strong dependency on the scheduler and 
> might delay the event to an uncertain point in time as the pool of the 
> scheduler might be exhausted atm.
> For these schedules, it's better to use javas timer class.



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

[jira] [Closed] (SLING-6692) Replace commons.json usage in org.apache.sling.discovery.oak

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6692.
-

> Replace commons.json usage in org.apache.sling.discovery.oak
> 
>
> Key: SLING-6692
> URL: https://issues.apache.org/jira/browse/SLING-6692
> Project: Sling
>  Issue Type: Sub-task
>  Components: Extensions
>Affects Versions: Discovery Oak 1.2.10
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>  Labels: patch-available
> Fix For: Discovery Oak 1.2.18
>
> Attachments: SLING-6692.patch
>
>




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

[jira] [Closed] (SLING-6690) Replace commons.json usage in org.apache.sling.discovery.commons

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6690.
-

> Replace commons.json usage in org.apache.sling.discovery.commons
> 
>
> Key: SLING-6690
> URL: https://issues.apache.org/jira/browse/SLING-6690
> Project: Sling
>  Issue Type: Sub-task
>  Components: Extensions
>Affects Versions: Discovery Commons 1.0.12
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>  Labels: patch-available
> Fix For: Discovery Commons 1.0.20
>
> Attachments: SLING-6690.patch
>
>




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

[jira] [Closed] (SLING-6489) discovery.oak: log less frequent when slingId is not (yet) mapped

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6489.
-

> discovery.oak: log less frequent when slingId is not (yet) mapped
> -
>
> Key: SLING-6489
> URL: https://issues.apache.org/jira/browse/SLING-6489
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Discovery Oak 1.2.16
>Reporter: Stefan Egli
> Fix For: Discovery Oak 1.2.18
>
>
> When connecting an oak-run in read-write mode to a documentMk based cluster, 
> discovery.oak complains with the following info messages repeatedly:
> {noformat}
> 2017-01-27 17:32:09,970 INFO NA 
> [discovery.connectors.common.runner.cf92d88d-345a-4e65-b776-f18dde62e585.discoveryLiteCheck]
>  o.a.s.d.b.c.BaseDiscoveryService - getTopology: undefined cluster view: 
> NO_ESTABLISHED_VIEW] 
> org.apache.sling.discovery.base.commons.UndefinedClusterViewException: no 
> slingId mapped for clusterNodeId=2 
> 2017-01-27 17:32:11,971 INFO NA 
> [discovery.connectors.common.runner.cf92d88d-345a-4e65-b776-f18dde62e585.discoveryLiteCheck]
>  o.a.s.d.o.c.OakClusterViewService - getLocalClusterView: undefined 
> clusterView: NO_ESTABLISHED_VIEW - no slingId mapped for clusterNodeId=2 
> 2017-01-27 17:32:11,971 INFO NA 
> [discovery.connectors.common.runner.cf92d88d-345a-4e65-b776-f18dde62e585.discoveryLiteCheck]
>  o.a.s.d.b.c.BaseDiscoveryService - getTopology: undefined cluster view: 
> NO_ESTABLISHED_VIEW] 
> org.apache.sling.discovery.base.commons.UndefinedClusterViewException: no 
> slingId mapped for clusterNodeId=2 
> 2017-01-27 17:32:13,972 INFO NA 
> [discovery.connectors.common.runner.cf92d88d-345a-4e65-b776-f18dde62e585.discoveryLiteCheck]
>  o.a.s.d.o.c.OakClusterViewService - getLocalClusterView: undefined 
> clusterView: NO_ESTABLISHED_VIEW - no slingId mapped for clusterNodeId=2 
> 2017-01-27 17:32:13,972 INFO NA 
> [discovery.connectors.common.runner.cf92d88d-345a-4e65-b776-f18dde62e585.discoveryLiteCheck]
>  o.a.s.d.b.c.BaseDiscoveryService - getTopology: undefined cluster view: 
> NO_ESTABLISHED_VIEW] 
> org.apache.sling.discovery.base.commons.UndefinedClusterViewException: no 
> slingId mapped for clusterNodeId=2 
> 2017-01-27 17:32:15,973 INFO NA 
> [discovery.connectors.common.runner.cf92d88d-345a-4e65-b776-f18dde62e585.discoveryLiteCheck]
>  o.a.s.d.o.c.OakClusterViewService - getLocalClusterView: undefined 
> clusterView: NO_ESTABLISHED_VIEW - no slingId mapped for clusterNodeId=2 
> {noformat}
> while this is 'by design' (being that oak-run represents only half of the 
> expected discovery.oak/discovery-lite stack) we could lower the frequency of 
> these messages to keep the log file cleaner. Perhaps log only every 5-10min.



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

Re: [RESULT][VOTE] Apache Sling Discovery Commons 1.0.20, Base 2.0.0, Impl 1.2.12, Oak 1.2.18 releases

[Karl Pauls]

Time to call the vote on the Apache Sling Discovery Commons 1.0.20,
Base 2.0.0, Impl 1.2.12, Oak 1.2.18 releases.

* +1 votes from Carsten Ziegeler, Stefan Egli, Daniel Klco, and Karl Pauls.

* No other votes.

The vote is successful. I will make the release artifacts available as
soon as possible.

Re: [VOTE] Apache Sling Discovery Commons 1.0.20, Base 2.0.0, Impl 1.2.12, Oak 1.2.18 releases

[Karl Pauls]

+1

regards,

Karl

On Mon, May 8, 2017 at 4:11 PM, Daniel Klco  wrote:
> +1
>
> On Mon, May 8, 2017 at 8:15 AM, Stefan Egli  wrote:
>
>> +1
>>
>> Cheers,
>> Stefan
>>
>> On 08/05/17 12:47, "Karl Pauls"  wrote:
>>
>> >I would like to call a vote on the following releases,
>> >
>> >Discovery Commons 1.0.20
>> >We solved 3 issues in this release:
>> >https://issues.apache.org/jira/browse/SLING/fixforversion/12338717
>> >
>> >Discovery Base 2.0.0
>> >We solved 2 issues in this release:
>> >https://issues.apache.org/jira/browse/SLING/fixforversion/12338718
>> >
>> >Discovery Impl 1.2.12
>> >We solved 1 issue in this release:
>> >https://issues.apache.org/jira/browse/SLING/fixforversion/12338719
>> >
>> >Discovery Oak 1.2.18
>> >We solved 2 issues in this release:
>> >https://issues.apache.org/jira/browse/SLING/fixforversion/12338720/
>> >
>> >Staging repository:
>> >https://repository.apache.org/content/repositories/orgapachesling-1707/
>> >
>> >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 1707 /tmp/sling-staging
>> >
>> >Please vote to approve these releases:
>> >
>> >  [ ] +1 Approve the releases
>> >  [ ]  0 Don't care
>> >  [ ] -1 Don't release, because ...
>>
>>
>>



-- 
Karl Pauls
karlpa...@gmail.com

Re: [VOTE] new apache sling logo (provided by chris millar)

[Bertrand Delacretaz]

On Thu, May 11, 2017 at 5:01 PM, Chris Millar  wrote:
> ...Thanks for leveling my expectations on the launchpad home page redesign 
> I'm about to submit...

As long as the stylesheet is named bikeshedding.css it should be fine.

-Bertrand

Re: [VOTE] new apache sling logo (provided by chris millar)

[Chris Millar]

@rombert

Thanks for leveling my expectations on the launchpad home page redesign I'm 
about to submit.

> On May 11, 2017, at 12:50 AM, Robert Munteanu  wrote:
> 
>> On Wed, 2017-05-10 at 14:22 +, Stefan Seifert wrote:
>> Please vote to approve this new logo:
> 
> +1
> 
> (And yay for consensus on something UI-related :-) )
> 
> Robert

Re: [VOTE] Release Apache Sling Models Impl 1.4.2

[Justin Edelson]

+1

On Thu, May 11, 2017 at 9:30 AM Stefan Seifert 
wrote:

> +1
>
>
>

RE: [VOTE] Release Apache Sling Models Impl 1.4.2

[Stefan Seifert]

+1

RE: [VOTE] Release Apache Sling Testing OSGi Mock 2.3.2, OSGi Mock 1.9.6, Sling Mock 2.2.10, Sling Mock 1.9.8

[Stefan Seifert]

+1

[jira] [Updated] (SLING-6849) Impersonation for group of users

[Krzysztof Watral (JIRA)]

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

Krzysztof Watral updated SLING-6849:

Description: 
Currently we have two possibilities (which I know) to impersonate some account 
as a different user:
# First solution can be implemented in the following way:
{code:java}
Map authenticationInfo = Maps.newHashMap();
authenticationInfo.put(ResourceResolverFactory.USER_IMPERSONATION, userId);
resourceResolver = 
resourceResolverFactory.getServiceResourceResolver(authenticationInfo);
{code}
it works, but adds a lot of effort for Administrators, they have to define each 
user in list of possible impersonators (unfortunately this approach doesn't 
support groups).
# Second approach is to get user session using 
SlingRepository.impersonateFroService:
{code:java}
slingRepository.impersonateFromService(null, credentials, null);
{code}
Unfortunately, this requires to pass userId and password, that is usually 
impossible to get from programmatical point of view.

To make life easier, it would be nice if one of the following suggestion would 
be implemented:
 - slingRepository.impersonateFromService(null, credentials, null); could start 
accepting credentials without password
 - impersonators could be configured for group of users


  was:
Currently we have two possibilities (which I know) to impersonate some account 
as a different user:
# First solution can be implemented in the following way:
{code:java}
Map authenticationInfo = Maps.newHashMap();
authenticationInfo.put(ResourceResolverFactory.USER_IMPERSONATION, userId);
resourceResolver = 
resourceResolverFactory.getServiceResourceResolver(authenticationInfo);
{code}
it works, but adds a lot of effort for Administrators, they have to define each 
user in list of possible impersonators (unfortunately this approach doesn't 
support a groups with users).
# Second approach is to get user session using 
SlingRepository.impersonateFroService:
{code:java}
slingRepository.impersonateFromService(null, credentials, null);
{code}
Unfortunately, this requires to pass userId and password, that is usually 
impossible to get from programmatical point of view.

To make life easier, it would be nice if one of the following suggestion would 
be implemented:
 - slingRepository.impersonateFromService(null, credentials, null); could start 
accepting credentials without password
 - impersonators could be configured for group of users



> Impersonation for group of users
> 
>
> Key: SLING-6849
> URL: https://issues.apache.org/jira/browse/SLING-6849
> Project: Sling
>  Issue Type: Improvement
>  Components: Authentication, ResourceResolver
>Reporter: Krzysztof Watral
>  Labels: impersonation
>
> Currently we have two possibilities (which I know) to impersonate some 
> account as a different user:
> # First solution can be implemented in the following way:
> {code:java}
> Map authenticationInfo = Maps.newHashMap();
> authenticationInfo.put(ResourceResolverFactory.USER_IMPERSONATION, userId);
> resourceResolver = 
> resourceResolverFactory.getServiceResourceResolver(authenticationInfo);
> {code}
> it works, but adds a lot of effort for Administrators, they have to define 
> each user in list of possible impersonators (unfortunately this approach 
> doesn't support groups).
> # Second approach is to get user session using 
> SlingRepository.impersonateFroService:
> {code:java}
> slingRepository.impersonateFromService(null, credentials, null);
> {code}
> Unfortunately, this requires to pass userId and password, that is usually 
> impossible to get from programmatical point of view.
> To make life easier, it would be nice if one of the following suggestion 
> would be implemented:
>  - slingRepository.impersonateFromService(null, credentials, null); could 
> start accepting credentials without password
>  - impersonators could be configured for group of users



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

[VOTE] Release Apache Sling Testing OSGi Mock 2.3.2, OSGi Mock 1.9.6, Sling Mock 2.2.10, Sling Mock 1.9.8

[Stefan Seifert]

Hi,

Apache Sling Testing OSGi Mock 2.3.2  (1 issue)
https://issues.apache.org/jira/browse/SLING/fixforversion/12340492

Apache Sling Testing OSGi Mock 1.9.6  (1 issue)
https://issues.apache.org/jira/browse/SLING/fixforversion/12340239

Apache Sling Testing Sling Mock 2.2.10  (2 issues)
https://issues.apache.org/jira/browse/SLING/fixforversion/12340538

Apache Sling Testing Sling Mock 1.9.8  (1 issue)
https://issues.apache.org/jira/browse/SLING/fixforversion/12340276

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

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

Please vote to approve this release:

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

This majority vote is open for at least 72 hours.

stefan

[jira] [Updated] (SLING-6849) Impersonation for group of users

[Krzysztof Watral (JIRA)]

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

Krzysztof Watral updated SLING-6849:

Description: 
Currently we have two possibilities (which I know) to impersonate some account 
as a different user:
# First solution can be implemented in the following way:
{code:java}
Map authenticationInfo = Maps.newHashMap();
authenticationInfo.put(ResourceResolverFactory.USER_IMPERSONATION, userId);
resourceResolver = 
resourceResolverFactory.getServiceResourceResolver(authenticationInfo);
{code}
it works, but adds a lot of effort for Administrators, they have to define each 
user in list of possible impersonators (unfortunately this approach doesn't 
support a groups with users).
# Second approach is to get user session using 
SlingRepository.impersonateFroService:
{code:java}
slingRepository.impersonateFromService(null, credentials, null);
{code}
Unfortunately, this requires to pass userId and password, that is usually 
impossible to get from programmatical point of view.

To make life easier, it would be nice if one of the following suggestion would 
be implemented:
 - slingRepository.impersonateFromService(null, credentials, null); could start 
accepting credentials without password
 - impersonators could be configured for group of users


  was:
Currently we have two possibilities (which I know) to impersonate some account 
as a different user:
# First solution can be implemented in the following way:
{code:java}
Map authenticationInfo = Maps.newHashMap();
authenticationInfo.put(ResourceResolverFactory.USER_IMPERSONATION, userId);
resourceResolver = 
resourceResolverFactory.getServiceResourceResolver(authenticationInfo);
{code}
it works, but adds a lot of effort for Administrators, because they have to 
define each user in list of possible impersonators (unfortunately this approach 
doesn't support a group of users).
# Second approach is to get user session using 
SlingRepository.impersonateFroService:
{code:java}
slingRepository.impersonateFromService(null, credentials, null);
{code}
Unfortunately, this requires to pass userId and password, that is usually 
impossible to get from programmatical point of view.

To make life easier, it would be nice if one of the following suggestion would 
be implemented:
 - slingRepository.impersonateFromService(null, credentials, null); could start 
accepting credentials without password
 - impersonators could be configured for group of users



> Impersonation for group of users
> 
>
> Key: SLING-6849
> URL: https://issues.apache.org/jira/browse/SLING-6849
> Project: Sling
>  Issue Type: Improvement
>  Components: Authentication, ResourceResolver
>Reporter: Krzysztof Watral
>  Labels: impersonation
>
> Currently we have two possibilities (which I know) to impersonate some 
> account as a different user:
> # First solution can be implemented in the following way:
> {code:java}
> Map authenticationInfo = Maps.newHashMap();
> authenticationInfo.put(ResourceResolverFactory.USER_IMPERSONATION, userId);
> resourceResolver = 
> resourceResolverFactory.getServiceResourceResolver(authenticationInfo);
> {code}
> it works, but adds a lot of effort for Administrators, they have to define 
> each user in list of possible impersonators (unfortunately this approach 
> doesn't support a groups with users).
> # Second approach is to get user session using 
> SlingRepository.impersonateFroService:
> {code:java}
> slingRepository.impersonateFromService(null, credentials, null);
> {code}
> Unfortunately, this requires to pass userId and password, that is usually 
> impossible to get from programmatical point of view.
> To make life easier, it would be nice if one of the following suggestion 
> would be implemented:
>  - slingRepository.impersonateFromService(null, credentials, null); could 
> start accepting credentials without password
>  - impersonators could be configured for group of users



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

[VOTE] Release Apache Sling Models Impl 1.4.2

[Stefan Seifert]

Hi,

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

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

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

Please vote to approve this release:

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

This majority vote is open for at least 72 hours.

stefan

[jira] [Resolved] (SLING-6848) Package level monitoring should be only enabled consciously

[Tommaso Teofili (JIRA)]

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

Tommaso Teofili resolved SLING-6848.

Resolution: Fixed
  Assignee: Tommaso Teofili

fixed in r1794817.

> Package level monitoring should be only enabled consciously
> ---
>
> Key: SLING-6848
> URL: https://issues.apache.org/jira/browse/SLING-6848
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution Core 0.2.8
>
> Attachments: SLING-6848.0.patch
>
>
> I have noticed that by default all {{DistributionPackages}} get an MBean 
> registered by {{MonitoringDistributionPackageBuilder}}. 
> While that's fine for monitoring purposes, I think that slows down a 
> distribution request a bit, therefore I was wondering if it wouldn't be 
> better to set the default _monitored package size_ to 0 (currently it's 100) 
> and do MBean registration only if that value is higher than 0.
> [~simone.tripodi] what do you think ?



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

Re: [VOTE] new apache sling logo (provided by chris millar)

[Bertrand Delacretaz]

On Wed, May 10, 2017 at 4:22 PM, Stefan Seifert  wrote:
> ..Please vote to approve this new logo..

+1, thank you Chris!

> ...bertrand also recommended we should add a credit for chris on the sling 
> website (perhaps on the project team page?)...

Sounds good to me, I suggest a "special thanks" section at the
beginning of http://sling.apache.org/project-information/project-team.html

-Bertrand

Re: [VOTE] new apache sling logo (provided by chris millar)

[Julian Sedding]

+1

Regards
Julian

On Thu, May 11, 2017 at 9:20 AM, Karl Pauls  wrote:
> +1
>
> regards,
>
> Karl
>
> On Thursday, May 11, 2017, Robert Munteanu  wrote:
>
>> On Wed, 2017-05-10 at 14:22 +, Stefan Seifert wrote:
>> > Please vote to approve this new logo:
>>
>> +1
>>
>> (And yay for consensus on something UI-related :-) )
>>
>> Robert
>
>
>
> --
> Karl Pauls
> karlpa...@gmail.com

[jira] [Commented] (SLING-6785) Add support for scoped lifecycle of sling models

[Christophe Jelger (JIRA)]

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

Christophe Jelger commented on SLING-6785:
--

[~justinedelson] Thx for the feature, I could finally test it today, works 
perfectly as expected. Cool stuff!

> Add support for scoped lifecycle of sling models
> 
>
> Key: SLING-6785
> URL: https://issues.apache.org/jira/browse/SLING-6785
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Christophe Jelger
>Assignee: Justin Edelson
>Priority: Minor
> Fix For: Sling Models API 1.3.4, Sling Models Impl 1.4.0
>
> Attachments: SLING-6785.diff, SLING-6785.diff
>
>
> Similar to the scopes of JEE beans 
> (http://docs.oracle.com/javaee/6/tutorial/doc/gjbbk.html), it would be nice 
> to have the possibility to set a scope for sling models.
> For example, a sling model instance could be reused for all the components 
> within the same HTTP request, thus avoiding that multiple instances of the 
> "same" model are created.
> This could be an attribute of the {{@model}} annotation, for example 
> something like:
> {{@model(scope="request")}}
> The {{request}} scope sounds straightforward for a sling model adapted from a 
> request.
> For models adapted from a resource, there are scenarios where the resource 
> itself is not relevant once the model has been instantiated, so it would 
> still be useful to be able to obtain the same model instance for different 
> components and resources within the same HTTP request.
> We could possibly have the same scopes than the JEE beans scope: {{request}}, 
> {{session}}, and {{application}}.



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

Re: Revisiting ServiceUserMapped

[Julian Sedding]

Definitely +1 on doing this right.

Regardless of the above, the goals I read in this thread are the following:
- only register a service if the required service-user is available
(ServiceUserMapped)
- announce service-users lazily

An implementation could consist of a component, let's call it
ServiceUserRegistry. The ServiceUserRegistry looks for
ServiceUserProvider services (e.g. a SlingRepository implementation
could also implement this interface). Furthermore, the
ServiceUserRegistry implements FindHook (in theory I think a
ListenerHook would be better, but this does not work with the current
Felix SCR implementation) looking for requests for ServiceUserMapped
services and their (optional) sub-service name. If a service is
requested that is not yet available, the ServiceUserRegistry asks all
ServiceUserProviders if they can provide a suitable service user. If
that is the case it registers an appropriately configured service
(this could be achieved by means of a ComponentFactory).

Unregistering of service users that go away could be handled on two
levels: 1. if a ServiceUserProvider is unregistered, all service-users
it provided need to be unregistered as well. 2. A ServiceUserProvider
needs to be able to signal the ServiceUserRegistry that a user has
disappeared.

With the introduction of a default service-user mapping, at least the
name ServiceUserMapped seems no longer appropriate. We could rename it
to ServiceUser or ServiceUserAvailable. And/or I could imagine going a
step further and provide a ServiceResourceResolverFactory (an
interface with a single method "createResourceResolver(Map authInfo)"
or maybe a second one with no args for convenience). A consumer would
inject the ServiceResourceResolverFactory instead of a
ResourceResolverFactory. The @Reference target filter could optionally
indicate a subservice name.

Please feel free to rip this apart or improve on it! ;)

Regards
Julian


On Thu, May 11, 2017 at 10:49 AM, Bertrand Delacretaz
 wrote:
> Hi,
>
> On Thu, May 11, 2017 at 9:39 AM, Carsten Ziegeler  
> wrote:
>> ...Service users are a very low level
>> configuration of the data store and we could assume that this is
>> correctly configured - as well as the mapping...
>
> I think the main goal of ServiceUserMapped is to have components wait
> at startup until the mappings (+ service users but that doesn't work)
> are available.
>
> So "configuration is correct" is just part of the deal.
>
> How about having the code that registers the ServiceUserMapped markers
> wait for the SlingRepository service?
>
> If service users are registered via repoinit, waiting for
> SlingRepository waits for all of them, assuming the configuration is
> correct. And if not those services will generally fail loudly.
>
> -Bertrand

Re: Revisiting ServiceUserMapped

[Konrad Windszus]

There is indeed a very valid use case for ServiceUserMapped and that is using 
the service resolver in the activate() method.
If the configuration or system user is not available at that point, the 
activate() fails with an exception and the component is never being restarted 
(even if at a later point in time both configuration and the bound system user 
is there).
This functionality is IMHO crucial, because at least during development it 
could be that the configuration mapping is not yet provided when the service 
would be first started. Just failing once and never retry again, is IMHO 
against all OSGi services practice. So having an explicit dependency against 
that feels right.
If it is too complicated to check for the existence of the service user we 
could at least keep the current dependency, which enforces that the service is 
not started until at least the configuration is available. This is very helpful 
and should not be removed.
Konrad


> On 11. May 2017, at 09:39, Carsten Ziegeler  wrote:
> 
> From the few responses in this thread I have the feeling that the
> preference is on implementing this correctly.
> 
> However, we're still lacking a good idea on how exactly to implement this.
> 
> Now, I think it is not a good idea to expose each and every service user
> as a service in the service registry. I don't want to make that
> information generally available. But then the question is how can the
> service user mapper implementation find out about this?
> 
> The other option we have is to accept that this is not worth the effort
> and we simply remove the ServiceUserMapped support (deprecate it and
> remove the usage in Sling). Service users are a very low level
> configuration of the data store and we could assume that this is
> correctly configured - as well as the mapping.
> 
> Thoughts?
> 
> Regards
> Carsten
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: Revisiting ServiceUserMapped

[Bertrand Delacretaz]

Hi,

On Thu, May 11, 2017 at 9:39 AM, Carsten Ziegeler  wrote:
> ...Service users are a very low level
> configuration of the data store and we could assume that this is
> correctly configured - as well as the mapping...

I think the main goal of ServiceUserMapped is to have components wait
at startup until the mappings (+ service users but that doesn't work)
are available.

So "configuration is correct" is just part of the deal.

How about having the code that registers the ServiceUserMapped markers
wait for the SlingRepository service?

If service users are registered via repoinit, waiting for
SlingRepository waits for all of them, assuming the configuration is
correct. And if not those services will generally fail loudly.

-Bertrand

Re: Revisiting ServiceUserMapped

[Timothee Maret]

Hi Carsten,

2017-05-11 9:39 GMT+02:00 Carsten Ziegeler :

> From the few responses in this thread I have the feeling that the
> preference is on implementing this correctly.
>
> However, we're still lacking a good idea on how exactly to implement this.
>
> Now, I think it is not a good idea to expose each and every service user
> as a service in the service registry. I don't want to make that
> information generally available. But then the question is how can the
> service user mapper implementation find out about this?
>
> The other option we have is to accept that this is not worth the effort
> and we simply remove the ServiceUserMapped support (deprecate it and
> remove the usage in Sling). Service users are a very low level
> configuration of the data store and we could assume that this is
> correctly configured - as well as the mapping.
>

I think deprecating makes sense, indeed service users seem rather like
configurations than resources to be managed during the app runtime.

Also, if a component still needs to detect this miss configuration upon
activation, it could still do it by explicitly invoking
ServiceUserMapper#getServiceUserID.

Regards,

Timothee


>
> Thoughts?
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

[jira] [Updated] (SLING-4752) New resource query API

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-4752:

Fix Version/s: JCR Resource 3.0.2
   Resource Resolver 1.5.26
   API 2.16.4

> New resource query API
> --
>
> Key: SLING-4752
> URL: https://issues.apache.org/jira/browse/SLING-4752
> Project: Sling
>  Issue Type: Improvement
>  Components: API, JCR, ResourceResolver
>Reporter: Carsten Ziegeler
> Fix For: API 2.16.4, Resource Resolver 1.5.26, JCR Resource 3.0.2
>
> Attachments: api-patch.txt, resourceresolver-patch.txt
>
>
> Discussion thread:
> http://mail-archives.apache.org/mod_mbox/sling-dev/201505.mbox/%3C555983F6.7020100%40apache.org%3E
> Starting mail:
> The current resource query api has several problems:
> - it's using the JCR spec to define a query
> - it's not clear which queries are supported by providers
> - queries are string based
> - implementing queries in a resource provider is way too hard as this
> would require to implement the complete jcr query api.
> I've created a draft for a new, object based API at [1]. The main idea
> is to use a builder pattern to create Query objects. This are immutable
> and have a unique identifier. The QueryManager service can be used to
> execute a query in the context of a resource resolver. The manager
> delegates the query to the providers. As each Query object has this
> identifier, implementations can use this to cache the parsing of the query.
> In addition to the query object you can pass in query instructions to
> specify a limit or range for the query.
> Obviously this is a reduced set compared to the full fledged jcr search
> api, however it should be suitable for the majority of use cases.
> [1]
> https://svn.apache.org/repos/asf/sling/whiteboard/cziegeler/api-v3/src/main/java/org/apache/sling/api/resource/query/



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

[jira] [Resolved] (SLING-1719) add a method to determine if a resource represents a multi-valued property

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-1719.
-
Resolution: Won't Fix

There is no activity for over 6 years here, therefore resolving as wont fix

> add a method to determine if a resource represents a multi-valued property
> --
>
> Key: SLING-1719
> URL: https://issues.apache.org/jira/browse/SLING-1719
> Project: Sling
>  Issue Type: Improvement
>  Components: API, JCR
>Reporter: Justin Edelson
>Priority: Minor
>
> see http://markmail.org/message/k3kz2737ykt52zpy for discussion



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

[jira] [Assigned] (SLING-4752) New resource query API

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler reassigned SLING-4752:
---

Assignee: Carsten Ziegeler

> New resource query API
> --
>
> Key: SLING-4752
> URL: https://issues.apache.org/jira/browse/SLING-4752
> Project: Sling
>  Issue Type: Improvement
>  Components: API, JCR, ResourceResolver
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: API 2.16.4, Resource Resolver 1.5.26, JCR Resource 3.0.2
>
> Attachments: api-patch.txt, resourceresolver-patch.txt
>
>
> Discussion thread:
> http://mail-archives.apache.org/mod_mbox/sling-dev/201505.mbox/%3C555983F6.7020100%40apache.org%3E
> Starting mail:
> The current resource query api has several problems:
> - it's using the JCR spec to define a query
> - it's not clear which queries are supported by providers
> - queries are string based
> - implementing queries in a resource provider is way too hard as this
> would require to implement the complete jcr query api.
> I've created a draft for a new, object based API at [1]. The main idea
> is to use a builder pattern to create Query objects. This are immutable
> and have a unique identifier. The QueryManager service can be used to
> execute a query in the context of a resource resolver. The manager
> delegates the query to the providers. As each Query object has this
> identifier, implementations can use this to cache the parsing of the query.
> In addition to the query object you can pass in query instructions to
> specify a limit or range for the query.
> Obviously this is a reduced set compared to the full fledged jcr search
> api, however it should be suitable for the majority of use cases.
> [1]
> https://svn.apache.org/repos/asf/sling/whiteboard/cziegeler/api-v3/src/main/java/org/apache/sling/api/resource/query/



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

[jira] [Updated] (SLING-6501) Incorrect normalization of path of an asset with name beginning with '.'

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-6501:

Fix Version/s: API 2.16.4

> Incorrect normalization of path of an asset with name beginning with '.'
> 
>
> Key: SLING-6501
> URL: https://issues.apache.org/jira/browse/SLING-6501
> Project: Sling
>  Issue Type: Bug
>  Components: API
>Reporter: Gaurav Gupta
> Fix For: API 2.16.4
>
>
> When a new asset named ".jpg" is being modified in JCR, 
> [ResourceUtil.normalize()|https://sling.apache.org/apidocs/sling7/org/apache/sling/api/resource/ResourceUtil.html#normalize-java.lang.String-]
>  method returns an incorrect normalized path which leads to the creation of a 
> folder named '.jp' under the same parent node. A small test shows this 
> anomaly.
> {code:java}
> public class RUNormalizeTest {
>   public static String toPropertyPath(String paramName, String path) {
> if (!paramName.startsWith("/")) {
> paramName = ResourceUtil.normalize(path + '/' + paramName);
> }
> return paramName;
> }
>   
>   public static void main(String[] args) {
>   String pName = 
> "./jpg_folder/.jpg/jcr:content/metadata/dc:title";
>   String path = "/content/dam";
>   System.out.println(toPropertyPath(pName,path));
>   }
> }
> {code}
> Expected output: /content/dam/jpg_folder/.jpg/jcr:content/metadata/dc:title 
> Output: /content/dam/jpg_folder/.jp/jcr:content/metadata/dc:title
> In the above code, the properties of an asset named '.jpg' are being 
> modified. However, the normalize method returns an incorrect path for the 
> input path.



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

Re: Revisiting ServiceUserMapped

[Carsten Ziegeler]

>From the few responses in this thread I have the feeling that the
preference is on implementing this correctly.

However, we're still lacking a good idea on how exactly to implement this.

Now, I think it is not a good idea to expose each and every service user
as a service in the service registry. I don't want to make that
information generally available. But then the question is how can the
service user mapper implementation find out about this?

The other option we have is to accept that this is not worth the effort
and we simply remove the ServiceUserMapped support (deprecate it and
remove the usage in Sling). Service users are a very low level
configuration of the data store and we could assume that this is
correctly configured - as well as the mapping.

Thoughts?

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

[jira] [Created] (SLING-6849) Impersonation for group of users

[Krzysztof Watral (JIRA)]

Krzysztof Watral created SLING-6849:
---

 Summary: Impersonation for group of users
 Key: SLING-6849
 URL: https://issues.apache.org/jira/browse/SLING-6849
 Project: Sling
  Issue Type: Improvement
  Components: Authentication, ResourceResolver
Reporter: Krzysztof Watral


Currently we have two possibilities (which I know) to impersonate some account 
as a different user:
# First solution can be implemented in the following way:
{code:java}
Map authenticationInfo = Maps.newHashMap();
authenticationInfo.put(ResourceResolverFactory.USER_IMPERSONATION, userId);
resourceResolver = 
resourceResolverFactory.getServiceResourceResolver(authenticationInfo);
{code}
it works, but adds a lot of effort for Administrators, because they have to 
define each user in list of possible impersonators (unfortunately this approach 
doesn't support a group of users).
# Second approach is to get user session using 
SlingRepository.impersonateFroService:
{code:java}
slingRepository.impersonateFromService(null, credentials, null);
{code}
Unfortunately, this requires to pass userId and password, that is usually 
impossible to get from programmatical point of view.

To make life easier, it would be nice if one of the following suggestion would 
be implemented:
 - slingRepository.impersonateFromService(null, credentials, null); could start 
accepting credentials without password
 - impersonators could be configured for group of users




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

Re: [VOTE] new apache sling logo (provided by chris millar)

[Karl Pauls]

+1

regards,

Karl

On Thursday, May 11, 2017, Robert Munteanu  wrote:

> On Wed, 2017-05-10 at 14:22 +, Stefan Seifert wrote:
> > Please vote to approve this new logo:
>
> +1
>
> (And yay for consensus on something UI-related :-) )
>
> Robert



-- 
Karl Pauls
karlpa...@gmail.com

Re: [VOTE] new apache sling logo (provided by chris millar)

[Robert Munteanu]

On Wed, 2017-05-10 at 14:22 +, Stefan Seifert wrote:
> Please vote to approve this new logo:

+1

(And yay for consensus on something UI-related :-) )

Robert

signature.asc
Description: This is a digitally signed message part

Re: Sling IDE Tooling: rep:policy issue

[Robert Munteanu]

Hi Andy,

On Wed, 2017-05-10 at 15:58 -0700, Andreas Schaefer Sr. wrote:
> Hi Robert
> 
> A client for the IntelliJ plugin asked why he cannot edit a
> _rep_policy.xml file and deploy it. Debugging the issue
> I see a Constraint Violation because rep:policy is protected. I
> tested this will Eclipse and it does work their
> either.

Yes, it's not implemented at the moment. Top of my head, ACLs, user and
group definitions do not work. The entries may not be changed through
the regular Session/Node API of the interface but need to be handled
through special interfaces:

- https://wiki.apache.org/jackrabbit/AccessControl
- https://wiki.apache.org/jackrabbit/UserManagement


> I assume that for rep:policy changes the user needs to deploy it as
> package rather than pushing it through
> the Remote Repository Manager. Is that correct? If not how can I make
> it work?

The Sling commands need to be enhanced to handle users, groups and ACLs
 separately. I would first look in the FileVault source code to see how
it's done, it might be interesting to get all the corners right.

We're tracking this under 

  https://issues.apache.org/jira/browse/SLING-3827

which also has a link to how FileVault handles things.

Robert