[jira] [Comment Edited] (SLING-5006) Allow to enable the usage of regular JCR users for service resolvers

[Marius Petria (JIRA)]

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

Marius Petria edited comment on SLING-5006 at 11/2/15 2:02 PM:
---

As the validators are invoked everytime a mapping is requested, I think at 
least in theory they can be dynamic so there is no guarantee that a mapping 
won't switch from valid to invalid or viceversa even if the validator stays the 
same. So maybe services should not be informed about this, they will just start 
to fail for subsequent mapping requests. EDIT: On the other hand the "dynamic" 
service validator is an extreme case, so I think restarting everything on a 
validator change is OK.


was (Author: mpetria):
As the validators are invoked everytime a mapping is requested, I think at 
least in theory they can be dynamic so there is no guarantee that a mapping 
won't switch from valid to invalid or viceversa even if the validator stays the 
same. So basically I do not think that services should be informed about this, 
they will just start to fail for subsequent mapping requests.

> Allow to enable the usage of regular JCR users for service resolvers
> 
>
> Key: SLING-5006
> URL: https://issues.apache.org/jira/browse/SLING-5006
> Project: Sling
>  Issue Type: Improvement
>  Components: Service User Mapper
>Affects Versions: Service User Mapper 1.2.0, JCR Resource 2.5.6
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Service User Mapper 1.2.2, JCR Resource 2.6.0
>
> Attachments: SLING-5006-serviceusermapper-v01.diff, 
> SLING-5006-uservalidator-v01.diff
>
>
> With SLING-3854 a {{ServiceUserValidator}} interface was introduced. 
> Basically all OSGi services implementing that interface may decide whether 
> certain users can be used as backing user for a call to 
> {{ResourceResolverFactory.getServiceResolver(...)}}. The only implementation 
> of that in Sling is {{JcrSystemUserValidator}} which only allows to use JCR 
> system users.
> The list of all those services is bound in the {{ServiceUserMapperImpl}} 
> dynamically.
> If you for example want to use that service to relax the policy being 
> introduced with SLING-3854 (to e.g. allow all users as service users) you may 
> register your own service just returning {{true}} for all users in the only 
> method {{isValid}}. Unfortunately you don't know when your 
> {{ServiceUserValidator}} service is bound (due to the dynamic restart 
> behaviour of services). Therefore other services cannot rely on the fact that 
> your own {{ServiceUserValidator}} is being available at a certain point in 
> time and therefore their call to 
> {{ResourceResolverFactory.getServiceResolver(...)}} may fail, if they rely on 
> a non-System JCR user. Therefore this mechanism is not suitable to disable 
> the enforcing of JCR system users.
> Instead I would propose the following:
> # allow to configure the {{JcrSystemUserValidator}} via an OSGi property 
> named {{allowOnlySystemUsers}} which by default should be {{true}}.
> # within the method {{JcrSystemUserValidator.isValidUser}} you either allow 
> all users or leave the current logic in place (in case 
> {{allowOnlySystemUsers}} is {{true}}).
> Only that way it would be possible to reliably allow all users as service 
> users which is especially helpful during development of a certain feature 
> (although this is probably not a config you would set on a production 
> instance).



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

[jira] [Created] (SLING-5241) discovery.impl.SingleInstanceTest.testTopologyEventListeners failed on jenkins

[Stefan Egli (JIRA)]

Stefan Egli created SLING-5241:
--

 Summary: 
discovery.impl.SingleInstanceTest.testTopologyEventListeners failed on jenkins
 Key: SLING-5241
 URL: https://issues.apache.org/jira/browse/SLING-5241
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: Discovery Impl 1.1.8
Reporter: Stefan Egli
Assignee: Stefan Egli
 Fix For: Discovery Impl 1.2.0


discovery.impl.SingleInstanceTest.testTopologyEventListeners failed on jenkins:
https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/1915/testReport/junit/org.apache.sling.discovery.impl.cluster/SingleInstanceTest/testTopologyEventListeners/
{code}
Error Message

expected:<0> but was:<1>

Stacktrace

java.lang.AssertionError: expected:<0> but was:<1>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:542)
at 
org.apache.sling.discovery.base.its.AbstractSingleInstanceTest.testTopologyEventListeners(AbstractSingleInstanceTest.java:206)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
at 
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
{code}



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

[jira] [Resolved] (SLING-5242) VotingHander should only receive events under (configured) /var/discovery/impl

[Stefan Egli (JIRA)]

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

Stefan Egli resolved SLING-5242.

Resolution: Fixed

fixed in http://svn.apache.org/viewvc?rev=1712050=rev

> VotingHander should only receive events under (configured) /var/discovery/impl
> --
>
> Key: SLING-5242
> URL: https://issues.apache.org/jira/browse/SLING-5242
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Discovery Impl 1.1.8
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Discovery Impl 1.2.0
>
>
> So far the discovery.impl's VotingHandler was registering itself as 
> EventHandler for everything, filtering out at start of {{handleEvent}} if the 
> event was not applicable for it (ie if it was not under /var/discovery/impl). 
> This is extremely inefficient. The reason for doing it this way was the fact 
> that the path (/var/discovery/impl) was configurable and could thus not be 
> set as a annotation property to the VotingHandler class. However, that is 
> possible via an explicit service registration.



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

[jira] [Resolved] (SLING-5195) HeartbeatHandler should check for topology changes independently of long-during session.saves

[Stefan Egli (JIRA)]

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

Stefan Egli resolved SLING-5195.

Resolution: Fixed

considering done as more testing didn't unveil a bug at this stage.

> HeartbeatHandler should check for topology changes independently of 
> long-during session.saves
> -
>
> Key: SLING-5195
> URL: https://issues.apache.org/jira/browse/SLING-5195
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Discovery Impl 1.1.8
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Discovery Impl 1.2.0
>
>
> When running discovery.impl in a DocumentNodeStore cluster that is under 
> heavy load and thus produces large delays, the HeartbeatHandler can sometimes 
> be blocked in session.save for non-trivial amounts of time - longer than the 
> heartbeat timeout for example. This has the effect that both the 
> {{lastHeartbeat}} property is no longer updated but also that the topology is 
> not checked and updated towards the listeners. These two facts should be 
> separated within the HeartbeatHandler though.



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

[jira] [Commented] (SLING-5216) Concurrent creation of voting can lead to continuous re-voting

[Stefan Egli (JIRA)]

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

Stefan Egli commented on SLING-5216:


added another specific case for concurrent voting in 
http://svn.apache.org/viewvc?rev=1712016=rev

> Concurrent creation of voting can lead to continuous re-voting
> --
>
> Key: SLING-5216
> URL: https://issues.apache.org/jira/browse/SLING-5216
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Discovery Impl 1.0.2
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Blocker
> Fix For: Discovery Impl 1.2.0
>
>
> This is a regression of SLING-3195:
> With SLING-3195 the cluster view id was redefined from being a unique 
> per-voting/per view-incarnation id to being a stable, persisted, permanent 
> cluster Id (see [in 
> View.java|https://github.com/apache/sling/blob/bac2a2bf4c3ccdf6fa13866ffe6930c20b0230d6/bundles/extensions/discovery/impl/src/main/java/org/apache/sling/discovery/impl/common/View.java#L96]).
>  This was achieving the goal of exposing a stable view id for users of the 
> discovery API. 
> However, it introduced a regression in that this same {{getViewId()}} was 
> also used during voting when multiple votings happened simultaneously, to 
> agree on the lowest such 'view incarnation id'. With the change to making 
> this viewId the stable one though, and not adjusting its usage in this 
> multiple-votings-sorting, this sorting became broken. Basically now when 
> multiple votings happen simultaneously, then it can be that the participating 
> instances sort differently and don't agree on one vote. Resulting in the 
> {{HeartbeatHandler}} to come to the conclusion that there is no winner (as 
> there should only be 1), and start a fresh vote. Resulting in repeated new 
> votings being created.



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

[jira] [Comment Edited] (SLING-5216) Concurrent creation of voting can lead to continuous re-voting

[Stefan Egli (JIRA)]

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

Stefan Egli edited comment on SLING-5216 at 11/2/15 2:48 PM:
-

added another specific test case for concurrent voting in 
http://svn.apache.org/viewvc?rev=1712016=rev


was (Author: egli):
added another specific case for concurrent voting in 
http://svn.apache.org/viewvc?rev=1712016=rev

> Concurrent creation of voting can lead to continuous re-voting
> --
>
> Key: SLING-5216
> URL: https://issues.apache.org/jira/browse/SLING-5216
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Discovery Impl 1.0.2
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Blocker
> Fix For: Discovery Impl 1.2.0
>
>
> This is a regression of SLING-3195:
> With SLING-3195 the cluster view id was redefined from being a unique 
> per-voting/per view-incarnation id to being a stable, persisted, permanent 
> cluster Id (see [in 
> View.java|https://github.com/apache/sling/blob/bac2a2bf4c3ccdf6fa13866ffe6930c20b0230d6/bundles/extensions/discovery/impl/src/main/java/org/apache/sling/discovery/impl/common/View.java#L96]).
>  This was achieving the goal of exposing a stable view id for users of the 
> discovery API. 
> However, it introduced a regression in that this same {{getViewId()}} was 
> also used during voting when multiple votings happened simultaneously, to 
> agree on the lowest such 'view incarnation id'. With the change to making 
> this viewId the stable one though, and not adjusting its usage in this 
> multiple-votings-sorting, this sorting became broken. Basically now when 
> multiple votings happen simultaneously, then it can be that the participating 
> instances sort differently and don't agree on one vote. Resulting in the 
> {{HeartbeatHandler}} to come to the conclusion that there is no winner (as 
> there should only be 1), and start a fresh vote. Resulting in repeated new 
> votings being created.



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

[jira] [Commented] (SLING-5006) Allow to enable the usage of regular JCR users for service resolvers

[Marius Petria (JIRA)]

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

Marius Petria commented on SLING-5006:
--

I do not think there is a known race condition and it was just a suspect for 
some errors. Maybe [~cziegeler] can say more. My opinion is that we can resolve 
the issue now.

> Allow to enable the usage of regular JCR users for service resolvers
> 
>
> Key: SLING-5006
> URL: https://issues.apache.org/jira/browse/SLING-5006
> Project: Sling
>  Issue Type: Improvement
>  Components: Service User Mapper
>Affects Versions: Service User Mapper 1.2.0, JCR Resource 2.5.6
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Service User Mapper 1.2.2, JCR Resource 2.6.0
>
> Attachments: SLING-5006-serviceusermapper-v01.diff, 
> SLING-5006-uservalidator-v01.diff
>
>
> With SLING-3854 a {{ServiceUserValidator}} interface was introduced. 
> Basically all OSGi services implementing that interface may decide whether 
> certain users can be used as backing user for a call to 
> {{ResourceResolverFactory.getServiceResolver(...)}}. The only implementation 
> of that in Sling is {{JcrSystemUserValidator}} which only allows to use JCR 
> system users.
> The list of all those services is bound in the {{ServiceUserMapperImpl}} 
> dynamically.
> If you for example want to use that service to relax the policy being 
> introduced with SLING-3854 (to e.g. allow all users as service users) you may 
> register your own service just returning {{true}} for all users in the only 
> method {{isValid}}. Unfortunately you don't know when your 
> {{ServiceUserValidator}} service is bound (due to the dynamic restart 
> behaviour of services). Therefore other services cannot rely on the fact that 
> your own {{ServiceUserValidator}} is being available at a certain point in 
> time and therefore their call to 
> {{ResourceResolverFactory.getServiceResolver(...)}} may fail, if they rely on 
> a non-System JCR user. Therefore this mechanism is not suitable to disable 
> the enforcing of JCR system users.
> Instead I would propose the following:
> # allow to configure the {{JcrSystemUserValidator}} via an OSGi property 
> named {{allowOnlySystemUsers}} which by default should be {{true}}.
> # within the method {{JcrSystemUserValidator.isValidUser}} you either allow 
> all users or leave the current logic in place (in case 
> {{allowOnlySystemUsers}} is {{true}}).
> Only that way it would be possible to reliably allow all users as service 
> users which is especially helpful during development of a certain feature 
> (although this is probably not a config you would set on a production 
> instance).



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

[jira] [Commented] (SLING-5006) Allow to enable the usage of regular JCR users for service resolvers

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-5006:


I don't say, each toggle of any service user from valid to invalid or 
vice-versa should require a restart of all {{ServiceUserMapped}} services (that 
is also not possible), but at least the most common-use cases we may cover 
should require the restart of the service. In this case it is really only the 
configuration of the {{JcrSystemUserValidator}} which enforces a restart of all 
dependent services.

> Allow to enable the usage of regular JCR users for service resolvers
> 
>
> Key: SLING-5006
> URL: https://issues.apache.org/jira/browse/SLING-5006
> Project: Sling
>  Issue Type: Improvement
>  Components: Service User Mapper
>Affects Versions: Service User Mapper 1.2.0, JCR Resource 2.5.6
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Service User Mapper 1.2.2, JCR Resource 2.6.0
>
> Attachments: SLING-5006-serviceusermapper-v01.diff, 
> SLING-5006-uservalidator-v01.diff
>
>
> With SLING-3854 a {{ServiceUserValidator}} interface was introduced. 
> Basically all OSGi services implementing that interface may decide whether 
> certain users can be used as backing user for a call to 
> {{ResourceResolverFactory.getServiceResolver(...)}}. The only implementation 
> of that in Sling is {{JcrSystemUserValidator}} which only allows to use JCR 
> system users.
> The list of all those services is bound in the {{ServiceUserMapperImpl}} 
> dynamically.
> If you for example want to use that service to relax the policy being 
> introduced with SLING-3854 (to e.g. allow all users as service users) you may 
> register your own service just returning {{true}} for all users in the only 
> method {{isValid}}. Unfortunately you don't know when your 
> {{ServiceUserValidator}} service is bound (due to the dynamic restart 
> behaviour of services). Therefore other services cannot rely on the fact that 
> your own {{ServiceUserValidator}} is being available at a certain point in 
> time and therefore their call to 
> {{ResourceResolverFactory.getServiceResolver(...)}} may fail, if they rely on 
> a non-System JCR user. Therefore this mechanism is not suitable to disable 
> the enforcing of JCR system users.
> Instead I would propose the following:
> # allow to configure the {{JcrSystemUserValidator}} via an OSGi property 
> named {{allowOnlySystemUsers}} which by default should be {{true}}.
> # within the method {{JcrSystemUserValidator.isValidUser}} you either allow 
> all users or leave the current logic in place (in case 
> {{allowOnlySystemUsers}} is {{true}}).
> Only that way it would be possible to reliably allow all users as service 
> users which is especially helpful during development of a certain feature 
> (although this is probably not a config you would set on a production 
> instance).



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

[jira] [Resolved] (SLING-5241) discovery.impl.SingleInstanceTest.testTopologyEventListeners failed on jenkins

[Stefan Egli (JIRA)]

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

Stefan Egli resolved SLING-5241.

Resolution: Fixed

increasing wait time for receiving an event from 0.5s to 1.0s
http://svn.apache.org/viewvc?rev=1712022=rev

> discovery.impl.SingleInstanceTest.testTopologyEventListeners failed on jenkins
> --
>
> Key: SLING-5241
> URL: https://issues.apache.org/jira/browse/SLING-5241
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Discovery Impl 1.1.8
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Discovery Impl 1.2.0
>
>
> discovery.impl.SingleInstanceTest.testTopologyEventListeners failed on 
> jenkins:
> https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/1915/testReport/junit/org.apache.sling.discovery.impl.cluster/SingleInstanceTest/testTopologyEventListeners/
> {code}
> Error Message
> expected:<0> but was:<1>
> Stacktrace
> java.lang.AssertionError: expected:<0> but was:<1>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:743)
>   at org.junit.Assert.assertEquals(Assert.java:118)
>   at org.junit.Assert.assertEquals(Assert.java:555)
>   at org.junit.Assert.assertEquals(Assert.java:542)
>   at 
> org.apache.sling.discovery.base.its.AbstractSingleInstanceTest.testTopologyEventListeners(AbstractSingleInstanceTest.java:206)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:483)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {code}



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

[jira] [Created] (SLING-5242) VotingHander should only receive events under (configured) /var/discovery/impl

[Stefan Egli (JIRA)]

Stefan Egli created SLING-5242:
--

 Summary: VotingHander should only receive events under 
(configured) /var/discovery/impl
 Key: SLING-5242
 URL: https://issues.apache.org/jira/browse/SLING-5242
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Affects Versions: Discovery Impl 1.1.8
Reporter: Stefan Egli
Assignee: Stefan Egli
 Fix For: Discovery Impl 1.2.0


So far the discovery.impl's VotingHandler was registering itself as 
EventHandler for everything, filtering out at start of {{handleEvent}} if the 
event was not applicable for it (ie if it was not under /var/discovery/impl). 
This is extremely inefficient. The reason for doing it this way was the fact 
that the path (/var/discovery/impl) was configurable and could thus not be set 
as a annotation property to the VotingHandler class. However, that is possible 
via an explicit service registration.



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

[jira] [Commented] (SLING-5006) Allow to enable the usage of regular JCR users for service resolvers

[Marius Petria (JIRA)]

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

Marius Petria commented on SLING-5006:
--

As the validators are invoked everytime a mapping is requested, I think at 
least in theory they can be dynamic so there is no guarantee that a mapping 
won't switch from valid to invalid or viceversa even if the validator stays the 
same. So basically I do not think that services should be informed about this, 
they will just start to fail for subsequent mapping requests.

> Allow to enable the usage of regular JCR users for service resolvers
> 
>
> Key: SLING-5006
> URL: https://issues.apache.org/jira/browse/SLING-5006
> Project: Sling
>  Issue Type: Improvement
>  Components: Service User Mapper
>Affects Versions: Service User Mapper 1.2.0, JCR Resource 2.5.6
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Service User Mapper 1.2.2, JCR Resource 2.6.0
>
> Attachments: SLING-5006-serviceusermapper-v01.diff, 
> SLING-5006-uservalidator-v01.diff
>
>
> With SLING-3854 a {{ServiceUserValidator}} interface was introduced. 
> Basically all OSGi services implementing that interface may decide whether 
> certain users can be used as backing user for a call to 
> {{ResourceResolverFactory.getServiceResolver(...)}}. The only implementation 
> of that in Sling is {{JcrSystemUserValidator}} which only allows to use JCR 
> system users.
> The list of all those services is bound in the {{ServiceUserMapperImpl}} 
> dynamically.
> If you for example want to use that service to relax the policy being 
> introduced with SLING-3854 (to e.g. allow all users as service users) you may 
> register your own service just returning {{true}} for all users in the only 
> method {{isValid}}. Unfortunately you don't know when your 
> {{ServiceUserValidator}} service is bound (due to the dynamic restart 
> behaviour of services). Therefore other services cannot rely on the fact that 
> your own {{ServiceUserValidator}} is being available at a certain point in 
> time and therefore their call to 
> {{ResourceResolverFactory.getServiceResolver(...)}} may fail, if they rely on 
> a non-System JCR user. Therefore this mechanism is not suitable to disable 
> the enforcing of JCR system users.
> Instead I would propose the following:
> # allow to configure the {{JcrSystemUserValidator}} via an OSGi property 
> named {{allowOnlySystemUsers}} which by default should be {{true}}.
> # within the method {{JcrSystemUserValidator.isValidUser}} you either allow 
> all users or leave the current logic in place (in case 
> {{allowOnlySystemUsers}} is {{true}}).
> Only that way it would be possible to reliably allow all users as service 
> users which is especially helpful during development of a certain feature 
> (although this is probably not a config you would set on a production 
> instance).



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

[jira] [Created] (SLING-5240) Remove loginAdministrative() usage from org.apache.sling.tenant

[Antonio Sanso (JIRA)]

Antonio Sanso created SLING-5240:


 Summary: Remove loginAdministrative() usage from 
org.apache.sling.tenant
 Key: SLING-5240
 URL: https://issues.apache.org/jira/browse/SLING-5240
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Antonio Sanso


Counted 1 occurrence



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

[jira] [Created] (SLING-5244) discovery.impl.cluster.voting.VotingHandlerTest.testConcurrentVotesTwoNodes failed on jenkins

[Stefan Egli (JIRA)]

Stefan Egli created SLING-5244:
--

 Summary: 
discovery.impl.cluster.voting.VotingHandlerTest.testConcurrentVotesTwoNodes 
failed on jenkins
 Key: SLING-5244
 URL: https://issues.apache.org/jira/browse/SLING-5244
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: Discovery Impl 1.1.8
Reporter: Stefan Egli
Assignee: Stefan Egli
 Fix For: Discovery Impl 1.2.2


https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/1918/testReport/junit/org.apache.sling.discovery.impl.cluster.voting/VotingHandlerTest/testConcurrentVotesTwoNodes/
{code}
Error Message

expected:<456> but was:<455>

Stacktrace

java.lang.AssertionError: expected:<456> but was:<455>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:542)
at 
org.apache.sling.discovery.impl.cluster.voting.VotingHandlerTest.doTestConcurrentVotes(VotingHandlerTest.java:466)
at 
org.apache.sling.discovery.impl.cluster.voting.VotingHandlerTest.testConcurrentVotesTwoNodes(VotingHandlerTest.java:322)
{code}



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

Re: [VOTE] Release Apache Sling discovery.commons 1.0.2, discovery.base 1.0.2, discovery.oak 1.0.2, discovery.impl 1.2.0

[Carsten Ziegeler]

+1

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

Re: [VOTE] Release Apache Sling discovery.commons 1.0.2, discovery.base 1.0.2, discovery.oak 1.0.2, discovery.impl 1.2.0

[Carsten Ziegeler]

+1


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

[jira] [Commented] (SLING-5051) RequestDispatcher forward breaks i18n

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek commented on SLING-5051:
--

You can also simply adjust the service ranking in your filter to be lower than 
the i18n filter. You can see the actual filter order at 
http://localhost:4502/system/console/status-slingfilter

> RequestDispatcher forward breaks i18n
> -
>
> Key: SLING-5051
> URL: https://issues.apache.org/jira/browse/SLING-5051
> Project: Sling
>  Issue Type: Bug
>  Components: General
> Environment: Adobe Experience Manager 6.1
>Reporter: Sothea Nim
>
> I just noticed that on AEM 6, in my Filter, when I call RequestDispatcher 
> forward, i.e. request.getRequestDispatcher(...).forward(req, res);, it cause 
> i18n to break. Here's a snippet of my codes:
> ...
> boolean filtered = false;
> SlingHttpServletRequest request = req instanceof SlingHttpServletRequest ? 
> (SlingHttpServletRequest) req : null;
> SlingHttpServletResponse response = res instanceof SlingHttpServletResponse ? 
> (SlingHttpServletResponse) res : null;
> 
> if (request != null && response != null) {
> 
> // block of codes to resolve the request uri and get the new desired URI 
> 
> if (this.resolvedUriResource != null) {
> String uri = this.resolvedUriResource.getPath() + ".html";
> RequestDispatcherOptions options = new RequestDispatcherOptions();
> options.setAddSelectors(uriSelectors);
> 
> this.filterConfig.getServletContext().getRequestDispatcher(uri).forward(req, 
> res); // OR
> //request.getRequestDispatcher(this.resolvedUriResource, 
> options).forward(req, res);
> filtered = true;
> }
> }
> if (!filtered) {
> chain.doFilter(req, res);
> }
> ...
> Obtain the package contained detailed codes here: 
> http://www.sotheanim.com/images/www.sotheanim.com/blog/aem61-i18n-issue-samplepackage.zip
>  
> (/sixd/bundle/src/main/java/com/sixd/i18nissue/filter/PathResolutionFilter.java)



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

[RESULT][VOTE] Release Apache Sling Discovery Commons 1.0.0, Discovery Base 1.0.0, Discovery Oak 1.0.0

[Stefan Egli]

The vote passes with 3 binding +1 votes. I'll promote the release.

Cheers,
Stefan

On 26/10/15 17:47, "Stefan Egli"  wrote:

>Hi,
>
>For the following three, new releases we solved:
>
>Discovery Commons 1.0.0 - 7 issues
>https://issues.apache.org/jira/browse/SLING/fixforversion/12332165
>
>Discovery Base 1.0.0 - 2 issues
>https://issues.apache.org/jira/browse/SLING/fixforversion/12333957
>
>Discovery Oak 1.0.0 - 3 issues
>https://issues.apache.org/jira/browse/SLING/fixforversion/12333958
>
>Staging repository:
>https://repository.apache.org/content/repositories/orgapachesling-1361/
>
>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 1361 /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.
>
>Cheers,
>
>Stefan
>
>

[jira] [Updated] (SLING-5243) discovery.impl.cluster.SingleInstanceTest.testBootstrap failed on jenkins

[Stefan Egli (JIRA)]

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

Stefan Egli updated SLING-5243:
---
Description: 
the following test failed: 
https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/1918/testReport/junit/org.apache.sling.discovery.impl.cluster/SingleInstanceTest/testBootstrap/
{code}
Error Message

expected:<1> but was:<0>

Stacktrace

java.lang.AssertionError: expected:<1> but was:<0>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:542)
at 
org.apache.sling.discovery.base.its.AbstractSingleInstanceTest.testBootstrap(AbstractSingleInstanceTest.java:284)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
at 
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
{code}

  was:the following test failed: 
https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/1918/testReport/junit/org.apache.sling.discovery.impl.cluster/SingleInstanceTest/testBootstrap/


> discovery.impl.cluster.SingleInstanceTest.testBootstrap failed on jenkins
> -
>
> Key: SLING-5243
> URL: https://issues.apache.org/jira/browse/SLING-5243
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Discovery Impl 1.1.8
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Minor
> Fix For: Discovery Impl 1.2.2
>
> Attachments: SingleInstanceTest.testBootstrap.failure1918.txt
>
>
> the following test failed: 
> https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/1918/testReport/junit/org.apache.sling.discovery.impl.cluster/SingleInstanceTest/testBootstrap/
> {code}
> Error Message
> expected:<1> but was:<0>
> Stacktrace
> java.lang.AssertionError: expected:<1> but was:<0>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:743)
>   at org.junit.Assert.assertEquals(Assert.java:118)
>   at org.junit.Assert.assertEquals(Assert.java:555)
>   at org.junit.Assert.assertEquals(Assert.java:542)
>   at 
> org.apache.sling.discovery.base.its.AbstractSingleInstanceTest.testBootstrap(AbstractSingleInstanceTest.java:284)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> 

[jira] [Created] (SLING-5243) discovery.impl.cluster.SingleInstanceTest.testBootstrap failed on jenkins

[Stefan Egli (JIRA)]

Stefan Egli created SLING-5243:
--

 Summary: discovery.impl.cluster.SingleInstanceTest.testBootstrap 
failed on jenkins
 Key: SLING-5243
 URL: https://issues.apache.org/jira/browse/SLING-5243
 Project: Sling
  Issue Type: Bug
Affects Versions: Discovery Impl 1.1.8
Reporter: Stefan Egli
Assignee: Stefan Egli
Priority: Minor
 Fix For: Discovery Impl 1.2.2
 Attachments: SingleInstanceTest.testBootstrap.failure1918.txt

the following test failed: 
https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/1918/testReport/junit/org.apache.sling.discovery.impl.cluster/SingleInstanceTest/testBootstrap/



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

[jira] [Updated] (SLING-5243) discovery.impl.cluster.SingleInstanceTest.testBootstrap failed on jenkins

[Stefan Egli (JIRA)]

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

Stefan Egli updated SLING-5243:
---
Attachment: SingleInstanceTest.testBootstrap.failure1918.txt

Attached [^SingleInstanceTest.testBootstrap.failure1918.txt]

> discovery.impl.cluster.SingleInstanceTest.testBootstrap failed on jenkins
> -
>
> Key: SLING-5243
> URL: https://issues.apache.org/jira/browse/SLING-5243
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Discovery Impl 1.1.8
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Minor
> Fix For: Discovery Impl 1.2.2
>
> Attachments: SingleInstanceTest.testBootstrap.failure1918.txt
>
>
> the following test failed: 
> https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/1918/testReport/junit/org.apache.sling.discovery.impl.cluster/SingleInstanceTest/testBootstrap/
> {code}
> Error Message
> expected:<1> but was:<0>
> Stacktrace
> java.lang.AssertionError: expected:<1> but was:<0>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:743)
>   at org.junit.Assert.assertEquals(Assert.java:118)
>   at org.junit.Assert.assertEquals(Assert.java:555)
>   at org.junit.Assert.assertEquals(Assert.java:542)
>   at 
> org.apache.sling.discovery.base.its.AbstractSingleInstanceTest.testBootstrap(AbstractSingleInstanceTest.java:284)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:483)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {code}



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

[jira] [Closed] (SLING-5131) Introduce ConsistencyService to discovery.commons

[Stefan Egli (JIRA)]

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

Stefan Egli closed SLING-5131.
--

> Introduce ConsistencyService to discovery.commons
> -
>
> Key: SLING-5131
> URL: https://issues.apache.org/jira/browse/SLING-5131
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Discovery Commons 1.0.0
>
>
> As described [in 
> SLING-4627|https://issues.apache.org/jira/browse/SLING-4627?focusedCommentId=14532334=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14532334]
>  doing any kind of discovery implementation on top of an eventually 
> consistent repository requires synchronization with this very repository in 
> order to ensure all events of an old incarnation of a view are processed 
> before a new incarnation of a view is announced to everybody. Thus a 
> cluster-wide synchronization is required.
> Such a synchronization can be achieved fairly straight-forward by storing a 
> well-defined 'sync token' into a location which is known to everybody else in 
> the cluster - and having everybody wait for seeing this token before 
> continuing.



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

[jira] [Closed] (SLING-4665) Provide a Helper class to compare topology views

[Stefan Egli (JIRA)]

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

Stefan Egli closed SLING-4665.
--

> Provide a Helper class to compare topology views
> 
>
> Key: SLING-4665
> URL: https://issues.apache.org/jira/browse/SLING-4665
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Timothee Maret
>Assignee: Stefan Egli
> Fix For: Discovery Commons 1.0.0
>
> Attachments: SLING-4665.patch
>
>
> As discussed in SLING-4627, the Sling discovery would benefit from having a 
> helper class that allow applications to compare two different topology views.
> As suggested by [~egli] this could be developed in a new bundle
> {code}
> org.apache.sling
> org.apache.sling.discovery.commons
> {code}
> The issue has no component/version assigned as it may require creating a new 
> one for discovery.common.



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

[jira] [Closed] (SLING-5173) factor away reusable base (incl connectors) of discovery.impl into discovery.base

[Stefan Egli (JIRA)]

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

Stefan Egli closed SLING-5173.
--

> factor away reusable base (incl connectors) of discovery.impl into 
> discovery.base
> -
>
> Key: SLING-5173
> URL: https://issues.apache.org/jira/browse/SLING-5173
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Affects Versions: Discovery Impl 1.1.8
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Discovery Impl 1.2.0, Discovery Commons 1.0.0, Discovery 
> Base 1.0.0, Discovery Oak 1.0.0
>
>
> As noted [in 
> SLING-4603|https://issues.apache.org/jira/browse/SLING-4603?focusedCommentId=14953201=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14953201]
>  as part of introducing discovery.oak, discovery.impl should be split: any 
> part of discovery.impl that is not strictly related to repository-heartbeats 
> should be moved into a {{discovery.base}} such that both {{discovery.impl}} 
> and {{discovery.oak}} can make use of it. This includes topology connectors, 
> but also includes some further parts such as the new integration into 
> {{ViewStateManager}} etc. {{discovery.base}} is therefore a very special, 
> dedicated base bundle for both impl and oak.



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

[jira] [Closed] (SLING-4627) TOPOLOGY_CHANGED in an eventually consistent repository

[Stefan Egli (JIRA)]

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

Stefan Egli closed SLING-4627.
--

> TOPOLOGY_CHANGED in an eventually consistent repository
> ---
>
> Key: SLING-4627
> URL: https://issues.apache.org/jira/browse/SLING-4627
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Critical
> Fix For: Discovery Commons 1.0.0, Discovery Oak 1.0.0
>
> Attachments: SLING-4627.patch, SLING-4627.patch
>
>
> This is a parent ticket describing the +coordination effort needed between 
> properly sending TOPOLOGY_CHANGED when running ontop of an eventually 
> consistent repository+. These findings are independent of the implementation 
> details used inside the discovery implementation, so apply to discovery.impl, 
> discovery.etcd/.zookeeper/.oak etc. Tickets to implement this for specific 
> implementation are best created separately (eg sub-task or related..). Also 
> note that this assumes immediately sending TOPOLOGY_CHANGING as described [in 
> SLING-3432|https://issues.apache.org/jira/browse/SLING-3432?focusedCommentId=14492494=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14492494]
> h5. The spectrum of possible TOPOLOGY_CHANGED events include the following 
> scenarios:
> || scenario || classification || action ||
> | A. change is completely outside of local cluster | (/) uncritical | changes 
> outside the cluster are considered uncritical for this exercise. |
> | B. a new instance joins the local cluster, this new instance is by contract 
> not the leader (leader must be stable \[0\]) | (/) uncritical | a join of an 
> instance is uncritical due to the fact that it merely joins the cluster and 
> has thus no 'backlog' of changes that might be propagating through the 
> (eventually consistent) repository. |
> | C. a non-leader *leaves* the local cluster | (x) *critical* | changes that 
> were written by the leaving instance might still not be *seen* by all 
> surviving (ie it can be that discovery is faster than the repository) and 
> this must be assured before sending out TOPOLOGY_CHANGED. This is because the 
> leaving instance could have written changes that are *topology dependent* and 
> thus those changes must first be settled in the repository before continuing 
> with a *new topology*. |
> | D. the leader *leaves* the local cluster (and thus a new leader is elected) 
> | (x)(x) *very critical* | same as C except that this is more critical due to 
> the fact that the leader left |
> | E. -the leader of the local cluster changes (without leaving)- this is not 
> supported by contract (leader must be stable \[0\]) | (/) -irrelevant- | |
> So both C and D are about an instance leaving. And as mentioned above the 
> survivors must assure they have read all changes of the leavers. There are 
> two parts to this:
> * the leaver could have pending writes that are not yet in mongoD: I don't 
> think this is the case. The only thing that can remain could be an 
> uncommitted branch and that would be rolled back afaik.
> ** Exception to this is a partition: where the leaver didn't actually crash 
> but is still hooked to the repository. *For this I'm not sure how it can be 
> solved* yet.
> * the survivers could however not yet have read all changes (pending in the 
> background read) and one way to make sure they did is to have each surviving 
> instance write a (pseudo-) sync token to the repository. Once all survivors 
> have seen this sync token of all other survivors, the assumption is that all 
> pending changes are "flushed" through the eventually consistent repository 
> and that it is safe to send out a TOPOLOGY_CHANGED event. 
> * this sync token must be *conflict free* and could be eg: 
> {{/var/discovery/oak/clusterInstances//syncTokens/}} - 
> where {{newViewId}} is defined by whatever discovery mechanism is used
> * a special case is when only one instance is remaining. It can then not wait 
> for any other survivor to send a sync token. In that case sync tokens would 
> not work. All it could then possibly do is to wait for a certain time (which 
> should be larger than any expected background-read duration)
> [~mreutegg], [~chetanm] can you pls confirm/comment on the above "flush/sync 
> token" approach? Thx!
> /cc [~marett]
> \[0\] - see [getLeader() in 
> ClusterView|https://github.com/apache/sling/blob/trunk/bundles/extensions/discovery/api/src/main/java/org/apache/sling/discovery/ClusterView.java]



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

[jira] [Closed] (SLING-4603) discovery.oak: oak-based discovery implementation

[Stefan Egli (JIRA)]

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

Stefan Egli closed SLING-4603.
--

> discovery.oak: oak-based discovery implementation
> -
>
> Key: SLING-4603
> URL: https://issues.apache.org/jira/browse/SLING-4603
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>  Labels: Sling-9-ReleaseNotes
> Fix For: Discovery Oak 1.0.0
>
>
> When discovery is used in a stack based on jackrabbit oak as the repository, 
> the current way of discoving instances somewhat sounds like duplicating work: 
> oak, or more precisely documentnodestore, itself has a low-level [lease 
> mechanism|http://jackrabbit.apache.org/oak/docs/nodestore/documentmk.html] 
> where it stores information about the cluster nodes including a {{leaseEnd}} 
> indicating at what time others can consider a particular node as 
> dead/crashed. This corresponds pretty much to the discovery.impl heartbeat 
> mechanism. And in a stack which is built ontop of oak-documentMk, we could be 
> making use of this fact and delegate the decision about whether a node in a 
> cluster is alive or not to the oak layer. Also, with OAK-2597 the relevant 
> information: {{ActiveClusterNodes}} is nicely exposed via JMX - so that can 
> become the new source of truth defining the cluster view.
> When replacing discovery-owned heartbeats with oak-owned ones, there is one 
> important detail to be watched out for: it can no longer easily be determined 
> from another instance in the cluster, whether it has this new discovery 
> bundle activated or not. Hence it is not given that when a voting happens, 
> that all {{active}} nodes (as reported by oak-documentMk) are actually going 
> to respond. So the 'silent instance due to deactivated discovery bundle' case 
> needs special attention/handling.
> Other than that, given the normal case of all {{active}} nodes having the 
> bundle activated, the voting mechanism can stay the same as in 
> discovery.impl. The topology connectors can be treated the same too (by 
> storing announcements to their respective 
> {{/var/discovery/clusterInstances//announcements/}}
>  node. The properties can be handled the same too (by storing to 
> {{/properties}} node. Only thing that gets replaced is the {{heartbeats}}.
> Note that in order for such an oak-based discovery.impl this oak-lease 
> mechanism must be very robust (it should be so by its own interest already). 
> However, there are currently a few issues that should probably first be 
> resolved until discovery can be based on this: OAK-2739, OAK-2682 and 
> OAK-2681 are currently known in this area.



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

[jira] [Closed] (SLING-5196) missing dependency when using maven-bundle-plugin 3.0.0 in discovery.base and discovery.impl

[Stefan Egli (JIRA)]

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

Stefan Egli closed SLING-5196.
--

> missing dependency when using maven-bundle-plugin 3.0.0 in discovery.base and 
> discovery.impl
> 
>
> Key: SLING-5196
> URL: https://issues.apache.org/jira/browse/SLING-5196
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Discovery Impl 1.2.0, Discovery Base 1.0.0
>
>
> When using the default maven-bundle-plugin version inherited from parent (25 
> atm), which is 3.0.0, then the following dependencies cannot be resolved in 
> AEM 5.6.1:
> {code}
> javax.servlet,version=[2.6,3) -- Cannot be resolved
> javax.servlet.http,version=[2.6,3) -- Cannot be resolved
> org.apache.commons.codec.binary,version=[1.6,2) -- Cannot be resolved
> {code}
> thus switching back to 2.5.3 for discovery.base to remain 
> backwards-compatibility



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

[jira] [Closed] (SLING-5188) Some WebConsole plugins are placed in the 'main' category

[Stefan Egli (JIRA)]

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

Stefan Egli closed SLING-5188.
--

> Some WebConsole plugins are placed in the 'main' category
> -
>
> Key: SLING-5188
> URL: https://issues.apache.org/jira/browse/SLING-5188
> Project: Sling
>  Issue Type: Improvement
>Affects Versions: Engine 2.4.4, Commons Mime 2.1.8, Auth Core 1.3.12, 
> Installer Console 1.0.0, Discovery Impl 1.1.8
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Commons Mime 2.1.10, Auth Core 1.3.14, Installer Console 
> 1.0.2, Discovery Impl 1.2.0, Engine 2.4.6, Discovery Oak 1.0.0
>
>
> Some WebConsole plugins don't specify a category and they end up in the 
> 'main' menu.
> They should be under Sling instead:
> - Authenticator
> - Mime Types
> - OSGi Installer
> - Recent Requests
> - Topoloy Management



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

[jira] [Closed] (SLING-4685) Introduce generic discovery.commons.ViewStateManager sharable for impls

[Stefan Egli (JIRA)]

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

Stefan Egli closed SLING-4685.
--

> Introduce generic discovery.commons.ViewStateManager sharable for impls
> ---
>
> Key: SLING-4685
> URL: https://issues.apache.org/jira/browse/SLING-4685
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Discovery Commons 1.0.0
>
> Attachments: SLING-4685.patch
>
>
> With multiple discovery implementations existing/upcoming it starts to become 
> valuable to share code that can be shared. And with the introduction of 
> discovery.commons we have a nice place for this.
> As a first thing, I propose to introduce a discovery.commons.ViewStateManager 
> (the name can be changed if wished of course): this one is capable of 
> managing a number of TopologyChangeListeners, can be in deactivated/activated 
> state and can react on {{handleChanging}} and {{handleNewView}} events and 
> translates all of those to correct events that it sends to the registered 
> listeners accordingly.
> This also takes into account the fact that the TOPOLOGY_INIT should be sent 
> only when the first valid view is available - which is flagged to 
> ViewStateManager via {{handleNewView}}.



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

[jira] [Closed] (SLING-4697) add support for PROPERTIES_CHANGED to ViewStateManager

[Stefan Egli (JIRA)]

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

Stefan Egli closed SLING-4697.
--

> add support for PROPERTIES_CHANGED to ViewStateManager
> --
>
> Key: SLING-4697
> URL: https://issues.apache.org/jira/browse/SLING-4697
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Discovery Commons 1.0.0
>
>
> The {{discovery.commons.providers.ViewStateManager}} currently only supports 
> TOPOLOGY_INIT, TOPOLOGY_CHANGING and TOPOLOGY_CHANGED - it should also 
> support PROPERTIES_CHANGED.



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

[jira] [Closed] (SLING-5191) Rename ConsistencyService to ClusterSyncService

[Stefan Egli (JIRA)]

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

Stefan Egli closed SLING-5191.
--

> Rename ConsistencyService to ClusterSyncService
> ---
>
> Key: SLING-5191
> URL: https://issues.apache.org/jira/browse/SLING-5191
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Discovery Commons 1.0.0
>
>
> Think 'ConsistencyService' is slightly misleading - thus renamed to 
> ClusterSyncService. That more describes what it does: it does a sync 
> throughout the cluster (by having each instance write a shared token into 
> well-known place - thus once everybody else sees this we've done a sync)



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

[jira] [Updated] (SLING-5246) discovery.impl.cluster.SingleInstanceTest.testTopologyEventListeners failed on jenkins

[Stefan Egli (JIRA)]

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

Stefan Egli updated SLING-5246:
---
Attachment: SingleInstanceTest.testTopologyEventListeners.failure1919.txt

Attached [^SingleInstanceTest.testTopologyEventListeners.failure1919.txt]

> discovery.impl.cluster.SingleInstanceTest.testTopologyEventListeners failed 
> on jenkins
> --
>
> Key: SLING-5246
> URL: https://issues.apache.org/jira/browse/SLING-5246
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Discovery Impl 1.2.0
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Discovery Impl 1.2.2
>
> Attachments: 
> SingleInstanceTest.testTopologyEventListeners.failure1919.txt
>
>
> https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/1919/testReport/junit/org.apache.sling.discovery.impl.cluster/SingleInstanceTest/testTopologyEventListeners/
> {code}
> Error Message
> expected:<0> but was:<1>
> Stacktrace
> java.lang.AssertionError: expected:<0> but was:<1>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:743)
>   at org.junit.Assert.assertEquals(Assert.java:118)
>   at org.junit.Assert.assertEquals(Assert.java:555)
>   at org.junit.Assert.assertEquals(Assert.java:542)
>   at 
> org.apache.sling.discovery.base.its.AbstractSingleInstanceTest.testTopologyEventListeners(AbstractSingleInstanceTest.java:206)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:483)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {code}



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

Re: [VOTE] Release Apache Sling discovery.commons 1.0.2, discovery.base 1.0.2, discovery.oak 1.0.2, discovery.impl 1.2.0

[Stefan Egli]

+1

Cheers,
Stefan

On 02/11/15 18:13, "Stefan Egli"  wrote:

>Hi,
>
>For the following three, new releases we solved:
>
>Discovery Commons 1.0.2 - 2 issues
>https://issues.apache.org/jira/browse/SLING/fixforversion/12333980
>
>Discovery Base 1.0.2 - 2 issues
>https://issues.apache.org/jira/browse/SLING/fixforversion/12333979
>
>Discovery Oak 1.0.2 - 2 issues
>https://issues.apache.org/jira/browse/SLING/fixforversion/12333978
>
>Discovery Impl 1.2.0 - 13 issues
>https://issues.apache.org/jira/browse/SLING/fixforversion/12333413
>
>
>Staging repository:
>https://repository.apache.org/content/repositories/orgapachesling-1362/
>
>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 1362 /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.
>
>Cheers,
>
>Stefan
>
>

[VOTE] Release Apache Sling discovery.commons 1.0.2, discovery.base 1.0.2, discovery.oak 1.0.2, discovery.impl 1.2.0

[Stefan Egli]

Hi,

For the following three, new releases we solved:

Discovery Commons 1.0.2 - 2 issues
https://issues.apache.org/jira/browse/SLING/fixforversion/12333980

Discovery Base 1.0.2 - 2 issues
https://issues.apache.org/jira/browse/SLING/fixforversion/12333979

Discovery Oak 1.0.2 - 2 issues
https://issues.apache.org/jira/browse/SLING/fixforversion/12333978

Discovery Impl 1.2.0 - 13 issues
https://issues.apache.org/jira/browse/SLING/fixforversion/12333413


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

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

Cheers,

Stefan

[jira] [Updated] (SLING-5243) discovery.impl.cluster.SingleInstanceTest.testBootstrap failed on jenkins

[Stefan Egli (JIRA)]

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

Stefan Egli updated SLING-5243:
---
Attachment: VotingHandlerTest.testConcurrentVotesTwoNodes.failure1918.txt

Attached [^VotingHandlerTest.testConcurrentVotesTwoNodes.failure1918.txt]

> discovery.impl.cluster.SingleInstanceTest.testBootstrap failed on jenkins
> -
>
> Key: SLING-5243
> URL: https://issues.apache.org/jira/browse/SLING-5243
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Discovery Impl 1.1.8
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Minor
> Fix For: Discovery Impl 1.2.2
>
> Attachments: SingleInstanceTest.testBootstrap.failure1918.txt, 
> VotingHandlerTest.testConcurrentVotesTwoNodes.failure1918.txt
>
>
> the following test failed: 
> https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/1918/testReport/junit/org.apache.sling.discovery.impl.cluster/SingleInstanceTest/testBootstrap/
> {code}
> Error Message
> expected:<1> but was:<0>
> Stacktrace
> java.lang.AssertionError: expected:<1> but was:<0>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:743)
>   at org.junit.Assert.assertEquals(Assert.java:118)
>   at org.junit.Assert.assertEquals(Assert.java:555)
>   at org.junit.Assert.assertEquals(Assert.java:542)
>   at 
> org.apache.sling.discovery.base.its.AbstractSingleInstanceTest.testBootstrap(AbstractSingleInstanceTest.java:284)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:483)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {code}



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

[jira] [Created] (SLING-5245) discovery.impl.cluster.SingleInstanceTest.testPropertyProviders failed on jenkins

[Stefan Egli (JIRA)]

Stefan Egli created SLING-5245:
--

 Summary: 
discovery.impl.cluster.SingleInstanceTest.testPropertyProviders failed on 
jenkins
 Key: SLING-5245
 URL: https://issues.apache.org/jira/browse/SLING-5245
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: Discovery Impl 1.2.0
Reporter: Stefan Egli
Assignee: Stefan Egli
 Fix For: Discovery Impl 1.2.2


https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/1919/testReport/junit/org.apache.sling.discovery.impl.cluster/SingleInstanceTest/testPropertyProviders/
{code}
Error Message

no established view at the moment

Stacktrace

org.apache.sling.discovery.base.commons.UndefinedClusterViewException: no 
established view at the moment
at 
org.apache.sling.discovery.impl.cluster.ClusterViewServiceImpl.getLocalClusterView(ClusterViewServiceImpl.java:102)
at 
org.apache.sling.discovery.base.its.AbstractSingleInstanceTest.testPropertyProviders(AbstractSingleInstanceTest.java:143)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
at 
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
{code}



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

[jira] [Created] (SLING-5246) discovery.impl.cluster.SingleInstanceTest.testTopologyEventListeners failed on jenkins

[Stefan Egli (JIRA)]

Stefan Egli created SLING-5246:
--

 Summary: 
discovery.impl.cluster.SingleInstanceTest.testTopologyEventListeners failed on 
jenkins
 Key: SLING-5246
 URL: https://issues.apache.org/jira/browse/SLING-5246
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: Discovery Impl 1.2.0
Reporter: Stefan Egli
Assignee: Stefan Egli
 Fix For: Discovery Impl 1.2.2


https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/1919/testReport/junit/org.apache.sling.discovery.impl.cluster/SingleInstanceTest/testTopologyEventListeners/
{code}
Error Message

expected:<0> but was:<1>

Stacktrace

java.lang.AssertionError: expected:<0> but was:<1>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:542)
at 
org.apache.sling.discovery.base.its.AbstractSingleInstanceTest.testTopologyEventListeners(AbstractSingleInstanceTest.java:206)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
at 
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
{code}



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

[jira] [Updated] (SLING-5245) discovery.impl.cluster.SingleInstanceTest.testPropertyProviders failed on jenkins

[Stefan Egli (JIRA)]

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

Stefan Egli updated SLING-5245:
---
Attachment: SingleInstanceTest.testPropertyProviders.failure1919.txt

Attached [^SingleInstanceTest.testPropertyProviders.failure1919.txt]

> discovery.impl.cluster.SingleInstanceTest.testPropertyProviders failed on 
> jenkins
> -
>
> Key: SLING-5245
> URL: https://issues.apache.org/jira/browse/SLING-5245
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Discovery Impl 1.2.0
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Discovery Impl 1.2.2
>
> Attachments: SingleInstanceTest.testPropertyProviders.failure1919.txt
>
>
> https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/1919/testReport/junit/org.apache.sling.discovery.impl.cluster/SingleInstanceTest/testPropertyProviders/
> {code}
> Error Message
> no established view at the moment
> Stacktrace
> org.apache.sling.discovery.base.commons.UndefinedClusterViewException: no 
> established view at the moment
>   at 
> org.apache.sling.discovery.impl.cluster.ClusterViewServiceImpl.getLocalClusterView(ClusterViewServiceImpl.java:102)
>   at 
> org.apache.sling.discovery.base.its.AbstractSingleInstanceTest.testPropertyProviders(AbstractSingleInstanceTest.java:143)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:483)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {code}



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

[jira] [Commented] (SLING-5006) Allow to enable the usage of regular JCR users for service resolvers

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-5006:


You are right that the {{ServiceUserMapped}} only says that a service mapping 
configuration for a specific user is there. But I would extend its usage so 
that dependent services are also restarted if a change on the validator 
happened. That is useful as a very common pattern is:
1. Have a new service using a service resolver in its {{activate}} method
2. Make that service have a dependency on {{ServiceUserMapped}} for the used 
service user


Now if you would reconfigure the {{JcrSystemUserValidator}} to also allow 
non-system users, all services having a static reference to 
{{ServiceUserMapped}} would be restarted. If you would not do that, the 
{{activate}} method may have thrown an exception due to usage of a non-system 
user. If you would not use the same marker dependency for that purpose, that 
service would not be restarted after that exception (and would therefore not be 
available after a restart of the according bundles).
In theory one could also use that in other {{ServiceUserValidator}} s to 
restart dependent services on configuration updates (as those might have an 
influence on which service users are considered valid).

As those {{ServiceUserValidator}} changes should not happen frequently I think 
restarting all dependent services should be fine from a performance 
perspective. WDYT?

> Allow to enable the usage of regular JCR users for service resolvers
> 
>
> Key: SLING-5006
> URL: https://issues.apache.org/jira/browse/SLING-5006
> Project: Sling
>  Issue Type: Improvement
>  Components: Service User Mapper
>Affects Versions: Service User Mapper 1.2.0, JCR Resource 2.5.6
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Service User Mapper 1.2.2, JCR Resource 2.6.0
>
> Attachments: SLING-5006-serviceusermapper-v01.diff, 
> SLING-5006-uservalidator-v01.diff
>
>
> With SLING-3854 a {{ServiceUserValidator}} interface was introduced. 
> Basically all OSGi services implementing that interface may decide whether 
> certain users can be used as backing user for a call to 
> {{ResourceResolverFactory.getServiceResolver(...)}}. The only implementation 
> of that in Sling is {{JcrSystemUserValidator}} which only allows to use JCR 
> system users.
> The list of all those services is bound in the {{ServiceUserMapperImpl}} 
> dynamically.
> If you for example want to use that service to relax the policy being 
> introduced with SLING-3854 (to e.g. allow all users as service users) you may 
> register your own service just returning {{true}} for all users in the only 
> method {{isValid}}. Unfortunately you don't know when your 
> {{ServiceUserValidator}} service is bound (due to the dynamic restart 
> behaviour of services). Therefore other services cannot rely on the fact that 
> your own {{ServiceUserValidator}} is being available at a certain point in 
> time and therefore their call to 
> {{ResourceResolverFactory.getServiceResolver(...)}} may fail, if they rely on 
> a non-System JCR user. Therefore this mechanism is not suitable to disable 
> the enforcing of JCR system users.
> Instead I would propose the following:
> # allow to configure the {{JcrSystemUserValidator}} via an OSGi property 
> named {{allowOnlySystemUsers}} which by default should be {{true}}.
> # within the method {{JcrSystemUserValidator.isValidUser}} you either allow 
> all users or leave the current logic in place (in case 
> {{allowOnlySystemUsers}} is {{true}}).
> Only that way it would be possible to reliably allow all users as service 
> users which is especially helpful during development of a certain feature 
> (although this is probably not a config you would set on a production 
> instance).



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

[jira] [Commented] (SLING-5006) Allow to enable the usage of regular JCR users for service resolvers

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-5006:


Looks good to me, thanks for that. 
Just out of curiosity: Is there a known race condition why SLING-4895 was 
necessary? Or is it just, that it is considered bad practice to call OSGi API 
while holding a lock 
(http://njbartlett.name/files/osgibook_preview_20091217.pdf, Chapter 6.4)?

> Allow to enable the usage of regular JCR users for service resolvers
> 
>
> Key: SLING-5006
> URL: https://issues.apache.org/jira/browse/SLING-5006
> Project: Sling
>  Issue Type: Improvement
>  Components: Service User Mapper
>Affects Versions: Service User Mapper 1.2.0, JCR Resource 2.5.6
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Service User Mapper 1.2.2, JCR Resource 2.6.0
>
> Attachments: SLING-5006-serviceusermapper-v01.diff, 
> SLING-5006-uservalidator-v01.diff
>
>
> With SLING-3854 a {{ServiceUserValidator}} interface was introduced. 
> Basically all OSGi services implementing that interface may decide whether 
> certain users can be used as backing user for a call to 
> {{ResourceResolverFactory.getServiceResolver(...)}}. The only implementation 
> of that in Sling is {{JcrSystemUserValidator}} which only allows to use JCR 
> system users.
> The list of all those services is bound in the {{ServiceUserMapperImpl}} 
> dynamically.
> If you for example want to use that service to relax the policy being 
> introduced with SLING-3854 (to e.g. allow all users as service users) you may 
> register your own service just returning {{true}} for all users in the only 
> method {{isValid}}. Unfortunately you don't know when your 
> {{ServiceUserValidator}} service is bound (due to the dynamic restart 
> behaviour of services). Therefore other services cannot rely on the fact that 
> your own {{ServiceUserValidator}} is being available at a certain point in 
> time and therefore their call to 
> {{ResourceResolverFactory.getServiceResolver(...)}} may fail, if they rely on 
> a non-System JCR user. Therefore this mechanism is not suitable to disable 
> the enforcing of JCR system users.
> Instead I would propose the following:
> # allow to configure the {{JcrSystemUserValidator}} via an OSGi property 
> named {{allowOnlySystemUsers}} which by default should be {{true}}.
> # within the method {{JcrSystemUserValidator.isValidUser}} you either allow 
> all users or leave the current logic in place (in case 
> {{allowOnlySystemUsers}} is {{true}}).
> Only that way it would be possible to reliably allow all users as service 
> users which is especially helpful during development of a certain feature 
> (although this is probably not a config you would set on a production 
> instance).



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

[jira] [Commented] (SLING-5006) Allow to enable the usage of regular JCR users for service resolvers

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-5006:


You are right that the {{ServiceUserMapped}} only says that a service mapping 
configuration for a specific user is there. But I would extend its usage so 
that dependent services are also restarted if a change on the validator 
happened. That is useful as a very common pattern is:
1. Have a new service using a service resolver in its {{activate}} method
2. Make that service have a dependency on {{ServiceUserMapped}} for the used 
service user


Now if you would reconfigure the {{JcrSystemUserValidator}} to also allow 
non-system users, all services having a static reference to 
{{ServiceUserMapped}} would be restarted. If you would not do that, the 
{{activate}} method may have thrown an exception due to usage of a non-system 
user. If you would not use the same marker dependency for that purpose, that 
service would not be restarted after that exception (and would therefore not be 
available after a restart of the according bundles).
In theory one could also use that in other {{ServiceUserValidator}} s to 
restart dependent services on configuration updates (as those might have an 
influence on which service users are considered valid).

As those {{ServiceUserValidator}} changes should not happen frequently I think 
restarting all dependent services should be fine from a performance 
perspective. WDYT?

> Allow to enable the usage of regular JCR users for service resolvers
> 
>
> Key: SLING-5006
> URL: https://issues.apache.org/jira/browse/SLING-5006
> Project: Sling
>  Issue Type: Improvement
>  Components: Service User Mapper
>Affects Versions: Service User Mapper 1.2.0, JCR Resource 2.5.6
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Service User Mapper 1.2.2, JCR Resource 2.6.0
>
> Attachments: SLING-5006-serviceusermapper-v01.diff, 
> SLING-5006-uservalidator-v01.diff
>
>
> With SLING-3854 a {{ServiceUserValidator}} interface was introduced. 
> Basically all OSGi services implementing that interface may decide whether 
> certain users can be used as backing user for a call to 
> {{ResourceResolverFactory.getServiceResolver(...)}}. The only implementation 
> of that in Sling is {{JcrSystemUserValidator}} which only allows to use JCR 
> system users.
> The list of all those services is bound in the {{ServiceUserMapperImpl}} 
> dynamically.
> If you for example want to use that service to relax the policy being 
> introduced with SLING-3854 (to e.g. allow all users as service users) you may 
> register your own service just returning {{true}} for all users in the only 
> method {{isValid}}. Unfortunately you don't know when your 
> {{ServiceUserValidator}} service is bound (due to the dynamic restart 
> behaviour of services). Therefore other services cannot rely on the fact that 
> your own {{ServiceUserValidator}} is being available at a certain point in 
> time and therefore their call to 
> {{ResourceResolverFactory.getServiceResolver(...)}} may fail, if they rely on 
> a non-System JCR user. Therefore this mechanism is not suitable to disable 
> the enforcing of JCR system users.
> Instead I would propose the following:
> # allow to configure the {{JcrSystemUserValidator}} via an OSGi property 
> named {{allowOnlySystemUsers}} which by default should be {{true}}.
> # within the method {{JcrSystemUserValidator.isValidUser}} you either allow 
> all users or leave the current logic in place (in case 
> {{allowOnlySystemUsers}} is {{true}}).
> Only that way it would be possible to reliably allow all users as service 
> users which is especially helpful during development of a certain feature 
> (although this is probably not a config you would set on a production 
> instance).



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

[jira] [Issue Comment Deleted] (SLING-5006) Allow to enable the usage of regular JCR users for service resolvers

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-5006:
---
Comment: was deleted

(was: You are right that the {{ServiceUserMapped}} only says that a service 
mapping configuration for a specific user is there. But I would extend its 
usage so that dependent services are also restarted if a change on the 
validator happened. That is useful as a very common pattern is:
1. Have a new service using a service resolver in its {{activate}} method
2. Make that service have a dependency on {{ServiceUserMapped}} for the used 
service user


Now if you would reconfigure the {{JcrSystemUserValidator}} to also allow 
non-system users, all services having a static reference to 
{{ServiceUserMapped}} would be restarted. If you would not do that, the 
{{activate}} method may have thrown an exception due to usage of a non-system 
user. If you would not use the same marker dependency for that purpose, that 
service would not be restarted after that exception (and would therefore not be 
available after a restart of the according bundles).
In theory one could also use that in other {{ServiceUserValidator}} s to 
restart dependent services on configuration updates (as those might have an 
influence on which service users are considered valid).

As those {{ServiceUserValidator}} changes should not happen frequently I think 
restarting all dependent services should be fine from a performance 
perspective. WDYT?)

> Allow to enable the usage of regular JCR users for service resolvers
> 
>
> Key: SLING-5006
> URL: https://issues.apache.org/jira/browse/SLING-5006
> Project: Sling
>  Issue Type: Improvement
>  Components: Service User Mapper
>Affects Versions: Service User Mapper 1.2.0, JCR Resource 2.5.6
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Service User Mapper 1.2.2, JCR Resource 2.6.0
>
> Attachments: SLING-5006-serviceusermapper-v01.diff, 
> SLING-5006-uservalidator-v01.diff
>
>
> With SLING-3854 a {{ServiceUserValidator}} interface was introduced. 
> Basically all OSGi services implementing that interface may decide whether 
> certain users can be used as backing user for a call to 
> {{ResourceResolverFactory.getServiceResolver(...)}}. The only implementation 
> of that in Sling is {{JcrSystemUserValidator}} which only allows to use JCR 
> system users.
> The list of all those services is bound in the {{ServiceUserMapperImpl}} 
> dynamically.
> If you for example want to use that service to relax the policy being 
> introduced with SLING-3854 (to e.g. allow all users as service users) you may 
> register your own service just returning {{true}} for all users in the only 
> method {{isValid}}. Unfortunately you don't know when your 
> {{ServiceUserValidator}} service is bound (due to the dynamic restart 
> behaviour of services). Therefore other services cannot rely on the fact that 
> your own {{ServiceUserValidator}} is being available at a certain point in 
> time and therefore their call to 
> {{ResourceResolverFactory.getServiceResolver(...)}} may fail, if they rely on 
> a non-System JCR user. Therefore this mechanism is not suitable to disable 
> the enforcing of JCR system users.
> Instead I would propose the following:
> # allow to configure the {{JcrSystemUserValidator}} via an OSGi property 
> named {{allowOnlySystemUsers}} which by default should be {{true}}.
> # within the method {{JcrSystemUserValidator.isValidUser}} you either allow 
> all users or leave the current logic in place (in case 
> {{allowOnlySystemUsers}} is {{true}}).
> Only that way it would be possible to reliably allow all users as service 
> users which is especially helpful during development of a certain feature 
> (although this is probably not a config you would set on a production 
> instance).



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

[jira] [Resolved] (SLING-5224) discovery.impl.SingleInstanceTest.testPropertyProviders failed on jenkins

[Stefan Egli (JIRA)]

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

Stefan Egli resolved SLING-5224.

Resolution: Fixed

Increased wait time from 100ms to 1000ms in rev 1711913

> discovery.impl.SingleInstanceTest.testPropertyProviders failed on jenkins
> -
>
> Key: SLING-5224
> URL: https://issues.apache.org/jira/browse/SLING-5224
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Discovery Impl 1.1.8
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Minor
> Fix For: Discovery Impl 1.2.0
>
>
> On jenkins discovery.impl's SingleInstanceTest.testPropertyProviders failed: 
> https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/1907/testReport/junit/org.apache.sling.discovery.impl.cluster/SingleInstanceTest/testPropertyProviders/
> {code}
> Error Message
> no established view at the moment
> Stacktrace
> org.apache.sling.discovery.base.commons.UndefinedClusterViewException: no 
> established view at the moment
>   at 
> org.apache.sling.discovery.impl.cluster.ClusterViewServiceImpl.getLocalClusterView(ClusterViewServiceImpl.java:102)
>   at 
> org.apache.sling.discovery.base.its.AbstractSingleInstanceTest.testPropertyProviders(AbstractSingleInstanceTest.java:143)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:483)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {code}



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

[jira] [Resolved] (SLING-5225) TestOakSyncTokenService.testTwoNodesOneLeaving failed on jenkins

[Stefan Egli (JIRA)]

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

Stefan Egli resolved SLING-5225.

Resolution: Fixed

Increased wait times in rev 1711917

> TestOakSyncTokenService.testTwoNodesOneLeaving failed on jenkins
> 
>
> Key: SLING-5225
> URL: https://issues.apache.org/jira/browse/SLING-5225
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Discovery Commons 1.0.0
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Minor
> Fix For: Discovery Commons 1.0.2
>
>
> TestOakSyncTokenService.testTwoNodesOneLeaving failed on jenkins:
> https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.commons/1914/testReport/junit/org.apache.sling.discovery.commons.providers.spi.base/TestOakSyncTokenService/testTwoNodesOneLeaving/
> {code}
> Stacktrace
> java.lang.AssertionError: 
>   at org.junit.Assert.fail(Assert.java:74)
>   at org.junit.Assert.assertTrue(Assert.java:37)
>   at org.junit.Assert.assertTrue(Assert.java:46)
>   at 
> org.apache.sling.discovery.commons.providers.spi.base.TestOakSyncTokenService.testTwoNodesOneLeaving(TestOakSyncTokenService.java:178)
> {code}



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

[jira] [Issue Comment Deleted] (SLING-5006) Allow to enable the usage of regular JCR users for service resolvers

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-5006:
---
Comment: was deleted

(was: You are right that the {{ServiceUserMapped}} only says that a service 
mapping configuration for a specific user is there. But I would extend its 
usage so that dependent services are also restarted if a change on the 
validator happened. That is useful as a very common pattern is:
1. Have a new service using a service resolver in its {{activate}} method
2. Make that service have a dependency on {{ServiceUserMapped}} for the used 
service user


Now if you would reconfigure the {{JcrSystemUserValidator}} to also allow 
non-system users, all services having a static reference to 
{{ServiceUserMapped}} would be restarted. If you would not do that, the 
{{activate}} method may have thrown an exception due to usage of a non-system 
user. If you would not use the same marker dependency for that purpose, that 
service would not be restarted after that exception (and would therefore not be 
available after a restart of the according bundles).
In theory one could also use that in other {{ServiceUserValidator}} s to 
restart dependent services on configuration updates (as those might have an 
influence on which service users are considered valid).

As those {{ServiceUserValidator}} changes should not happen frequently I think 
restarting all dependent services should be fine from a performance 
perspective. WDYT?)

> Allow to enable the usage of regular JCR users for service resolvers
> 
>
> Key: SLING-5006
> URL: https://issues.apache.org/jira/browse/SLING-5006
> Project: Sling
>  Issue Type: Improvement
>  Components: Service User Mapper
>Affects Versions: Service User Mapper 1.2.0, JCR Resource 2.5.6
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Service User Mapper 1.2.2, JCR Resource 2.6.0
>
> Attachments: SLING-5006-serviceusermapper-v01.diff, 
> SLING-5006-uservalidator-v01.diff
>
>
> With SLING-3854 a {{ServiceUserValidator}} interface was introduced. 
> Basically all OSGi services implementing that interface may decide whether 
> certain users can be used as backing user for a call to 
> {{ResourceResolverFactory.getServiceResolver(...)}}. The only implementation 
> of that in Sling is {{JcrSystemUserValidator}} which only allows to use JCR 
> system users.
> The list of all those services is bound in the {{ServiceUserMapperImpl}} 
> dynamically.
> If you for example want to use that service to relax the policy being 
> introduced with SLING-3854 (to e.g. allow all users as service users) you may 
> register your own service just returning {{true}} for all users in the only 
> method {{isValid}}. Unfortunately you don't know when your 
> {{ServiceUserValidator}} service is bound (due to the dynamic restart 
> behaviour of services). Therefore other services cannot rely on the fact that 
> your own {{ServiceUserValidator}} is being available at a certain point in 
> time and therefore their call to 
> {{ResourceResolverFactory.getServiceResolver(...)}} may fail, if they rely on 
> a non-System JCR user. Therefore this mechanism is not suitable to disable 
> the enforcing of JCR system users.
> Instead I would propose the following:
> # allow to configure the {{JcrSystemUserValidator}} via an OSGi property 
> named {{allowOnlySystemUsers}} which by default should be {{true}}.
> # within the method {{JcrSystemUserValidator.isValidUser}} you either allow 
> all users or leave the current logic in place (in case 
> {{allowOnlySystemUsers}} is {{true}}).
> Only that way it would be possible to reliably allow all users as service 
> users which is especially helpful during development of a certain feature 
> (although this is probably not a config you would set on a production 
> instance).



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

[jira] [Created] (SLING-5224) discovery.impl.SingleInstanceTest.testPropertyProviders failed on jenkins

[Stefan Egli (JIRA)]

Stefan Egli created SLING-5224:
--

 Summary: discovery.impl.SingleInstanceTest.testPropertyProviders 
failed on jenkins
 Key: SLING-5224
 URL: https://issues.apache.org/jira/browse/SLING-5224
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: Discovery Impl 1.1.8
Reporter: Stefan Egli
Assignee: Stefan Egli
Priority: Minor
 Fix For: Discovery Impl 1.2.0


On jenkins discovery.impl's SingleInstanceTest.testPropertyProviders failed: 
https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/1907/testReport/junit/org.apache.sling.discovery.impl.cluster/SingleInstanceTest/testPropertyProviders/
{code}
Error Message

no established view at the moment

Stacktrace

org.apache.sling.discovery.base.commons.UndefinedClusterViewException: no 
established view at the moment
at 
org.apache.sling.discovery.impl.cluster.ClusterViewServiceImpl.getLocalClusterView(ClusterViewServiceImpl.java:102)
at 
org.apache.sling.discovery.base.its.AbstractSingleInstanceTest.testPropertyProviders(AbstractSingleInstanceTest.java:143)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
at 
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
{code}



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

[jira] [Created] (SLING-5225) TestOakSyncTokenService.testTwoNodesOneLeaving failed on jenkins

[Stefan Egli (JIRA)]

Stefan Egli created SLING-5225:
--

 Summary: TestOakSyncTokenService.testTwoNodesOneLeaving failed on 
jenkins
 Key: SLING-5225
 URL: https://issues.apache.org/jira/browse/SLING-5225
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: Discovery Commons 1.0.0
Reporter: Stefan Egli
Assignee: Stefan Egli
Priority: Minor
 Fix For: Discovery Commons 1.0.2


TestOakSyncTokenService.testTwoNodesOneLeaving failed on jenkins:
https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.commons/1914/testReport/junit/org.apache.sling.discovery.commons.providers.spi.base/TestOakSyncTokenService/testTwoNodesOneLeaving/
{code}
Stacktrace

java.lang.AssertionError: 
at org.junit.Assert.fail(Assert.java:74)
at org.junit.Assert.assertTrue(Assert.java:37)
at org.junit.Assert.assertTrue(Assert.java:46)
at 
org.apache.sling.discovery.commons.providers.spi.base.TestOakSyncTokenService.testTwoNodesOneLeaving(TestOakSyncTokenService.java:178)
{code}



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

[jira] [Commented] (SLING-5006) Allow to enable the usage of regular JCR users for service resolvers

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-5006:


You are right that the {{ServiceUserMapped}} only says that a service mapping 
configuration for a specific user is there. But I would extend its usage so 
that dependent services are also restarted if a change on the validator 
happened. That is useful as a very common pattern is:
1. Have a new service using a service resolver in its {{activate}} method
2. Make that service have a dependency on {{ServiceUserMapped}} for the used 
service user


Now if you would reconfigure the {{JcrSystemUserValidator}} to also allow 
non-system users, all services having a static reference to 
{{ServiceUserMapped}} would be restarted. If you would not do that, the 
{{activate}} method may have thrown an exception due to usage of a non-system 
user. If you would not use the same marker dependency for that purpose, that 
service would not be restarted after that exception (and would therefore not be 
available after a restart of the according bundles).
In theory one could also use that in other {{ServiceUserValidator}} s to 
restart dependent services on configuration updates (as those might have an 
influence on which service users are considered valid).

As those {{ServiceUserValidator}} changes should not happen frequently I think 
restarting all dependent services should be fine from a performance 
perspective. WDYT?

> Allow to enable the usage of regular JCR users for service resolvers
> 
>
> Key: SLING-5006
> URL: https://issues.apache.org/jira/browse/SLING-5006
> Project: Sling
>  Issue Type: Improvement
>  Components: Service User Mapper
>Affects Versions: Service User Mapper 1.2.0, JCR Resource 2.5.6
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Service User Mapper 1.2.2, JCR Resource 2.6.0
>
> Attachments: SLING-5006-serviceusermapper-v01.diff, 
> SLING-5006-uservalidator-v01.diff
>
>
> With SLING-3854 a {{ServiceUserValidator}} interface was introduced. 
> Basically all OSGi services implementing that interface may decide whether 
> certain users can be used as backing user for a call to 
> {{ResourceResolverFactory.getServiceResolver(...)}}. The only implementation 
> of that in Sling is {{JcrSystemUserValidator}} which only allows to use JCR 
> system users.
> The list of all those services is bound in the {{ServiceUserMapperImpl}} 
> dynamically.
> If you for example want to use that service to relax the policy being 
> introduced with SLING-3854 (to e.g. allow all users as service users) you may 
> register your own service just returning {{true}} for all users in the only 
> method {{isValid}}. Unfortunately you don't know when your 
> {{ServiceUserValidator}} service is bound (due to the dynamic restart 
> behaviour of services). Therefore other services cannot rely on the fact that 
> your own {{ServiceUserValidator}} is being available at a certain point in 
> time and therefore their call to 
> {{ResourceResolverFactory.getServiceResolver(...)}} may fail, if they rely on 
> a non-System JCR user. Therefore this mechanism is not suitable to disable 
> the enforcing of JCR system users.
> Instead I would propose the following:
> # allow to configure the {{JcrSystemUserValidator}} via an OSGi property 
> named {{allowOnlySystemUsers}} which by default should be {{true}}.
> # within the method {{JcrSystemUserValidator.isValidUser}} you either allow 
> all users or leave the current logic in place (in case 
> {{allowOnlySystemUsers}} is {{true}}).
> Only that way it would be possible to reliably allow all users as service 
> users which is especially helpful during development of a certain feature 
> (although this is probably not a config you would set on a production 
> instance).



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

[jira] [Commented] (SLING-5006) Allow to enable the usage of regular JCR users for service resolvers

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-5006:


You are right that the {{ServiceUserMapped}} only says that a service mapping 
configuration for a specific user is there. But I would extend its usage so 
that dependent services are also restarted if a change on the validator 
happened. That is useful as a very common pattern is:
1. Have a new service using a service resolver in its {{activate}} method
2. Make that service have a dependency on {{ServiceUserMapped}} for the used 
service user


Now if you would reconfigure the {{JcrSystemUserValidator}} to also allow 
non-system users, all services having a static reference to 
{{ServiceUserMapped}} would be restarted. If you would not do that, the 
{{activate}} method may have thrown an exception due to usage of a non-system 
user. If you would not use the same marker dependency for that purpose, that 
service would not be restarted after that exception (and would therefore not be 
available after a restart of the according bundles).
In theory one could also use that in other {{ServiceUserValidator}} s to 
restart dependent services on configuration updates (as those might have an 
influence on which service users are considered valid).

As those {{ServiceUserValidator}} changes should not happen frequently I think 
restarting all dependent services should be fine from a performance 
perspective. WDYT?

> Allow to enable the usage of regular JCR users for service resolvers
> 
>
> Key: SLING-5006
> URL: https://issues.apache.org/jira/browse/SLING-5006
> Project: Sling
>  Issue Type: Improvement
>  Components: Service User Mapper
>Affects Versions: Service User Mapper 1.2.0, JCR Resource 2.5.6
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Service User Mapper 1.2.2, JCR Resource 2.6.0
>
> Attachments: SLING-5006-serviceusermapper-v01.diff, 
> SLING-5006-uservalidator-v01.diff
>
>
> With SLING-3854 a {{ServiceUserValidator}} interface was introduced. 
> Basically all OSGi services implementing that interface may decide whether 
> certain users can be used as backing user for a call to 
> {{ResourceResolverFactory.getServiceResolver(...)}}. The only implementation 
> of that in Sling is {{JcrSystemUserValidator}} which only allows to use JCR 
> system users.
> The list of all those services is bound in the {{ServiceUserMapperImpl}} 
> dynamically.
> If you for example want to use that service to relax the policy being 
> introduced with SLING-3854 (to e.g. allow all users as service users) you may 
> register your own service just returning {{true}} for all users in the only 
> method {{isValid}}. Unfortunately you don't know when your 
> {{ServiceUserValidator}} service is bound (due to the dynamic restart 
> behaviour of services). Therefore other services cannot rely on the fact that 
> your own {{ServiceUserValidator}} is being available at a certain point in 
> time and therefore their call to 
> {{ResourceResolverFactory.getServiceResolver(...)}} may fail, if they rely on 
> a non-System JCR user. Therefore this mechanism is not suitable to disable 
> the enforcing of JCR system users.
> Instead I would propose the following:
> # allow to configure the {{JcrSystemUserValidator}} via an OSGi property 
> named {{allowOnlySystemUsers}} which by default should be {{true}}.
> # within the method {{JcrSystemUserValidator.isValidUser}} you either allow 
> all users or leave the current logic in place (in case 
> {{allowOnlySystemUsers}} is {{true}}).
> Only that way it would be possible to reliably allow all users as service 
> users which is especially helpful during development of a certain feature 
> (although this is probably not a config you would set on a production 
> instance).



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

[jira] [Issue Comment Deleted] (SLING-5006) Allow to enable the usage of regular JCR users for service resolvers

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-5006:
---
Comment: was deleted

(was: You are right that the {{ServiceUserMapped}} only says that a service 
mapping configuration for a specific user is there. But I would extend its 
usage so that dependent services are also restarted if a change on the 
validator happened. That is useful as a very common pattern is:
1. Have a new service using a service resolver in its {{activate}} method
2. Make that service have a dependency on {{ServiceUserMapped}} for the used 
service user


Now if you would reconfigure the {{JcrSystemUserValidator}} to also allow 
non-system users, all services having a static reference to 
{{ServiceUserMapped}} would be restarted. If you would not do that, the 
{{activate}} method may have thrown an exception due to usage of a non-system 
user. If you would not use the same marker dependency for that purpose, that 
service would not be restarted after that exception (and would therefore not be 
available after a restart of the according bundles).
In theory one could also use that in other {{ServiceUserValidator}} s to 
restart dependent services on configuration updates (as those might have an 
influence on which service users are considered valid).

As those {{ServiceUserValidator}} changes should not happen frequently I think 
restarting all dependent services should be fine from a performance 
perspective. WDYT?)

> Allow to enable the usage of regular JCR users for service resolvers
> 
>
> Key: SLING-5006
> URL: https://issues.apache.org/jira/browse/SLING-5006
> Project: Sling
>  Issue Type: Improvement
>  Components: Service User Mapper
>Affects Versions: Service User Mapper 1.2.0, JCR Resource 2.5.6
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Service User Mapper 1.2.2, JCR Resource 2.6.0
>
> Attachments: SLING-5006-serviceusermapper-v01.diff, 
> SLING-5006-uservalidator-v01.diff
>
>
> With SLING-3854 a {{ServiceUserValidator}} interface was introduced. 
> Basically all OSGi services implementing that interface may decide whether 
> certain users can be used as backing user for a call to 
> {{ResourceResolverFactory.getServiceResolver(...)}}. The only implementation 
> of that in Sling is {{JcrSystemUserValidator}} which only allows to use JCR 
> system users.
> The list of all those services is bound in the {{ServiceUserMapperImpl}} 
> dynamically.
> If you for example want to use that service to relax the policy being 
> introduced with SLING-3854 (to e.g. allow all users as service users) you may 
> register your own service just returning {{true}} for all users in the only 
> method {{isValid}}. Unfortunately you don't know when your 
> {{ServiceUserValidator}} service is bound (due to the dynamic restart 
> behaviour of services). Therefore other services cannot rely on the fact that 
> your own {{ServiceUserValidator}} is being available at a certain point in 
> time and therefore their call to 
> {{ResourceResolverFactory.getServiceResolver(...)}} may fail, if they rely on 
> a non-System JCR user. Therefore this mechanism is not suitable to disable 
> the enforcing of JCR system users.
> Instead I would propose the following:
> # allow to configure the {{JcrSystemUserValidator}} via an OSGi property 
> named {{allowOnlySystemUsers}} which by default should be {{true}}.
> # within the method {{JcrSystemUserValidator.isValidUser}} you either allow 
> all users or leave the current logic in place (in case 
> {{allowOnlySystemUsers}} is {{true}}).
> Only that way it would be possible to reliably allow all users as service 
> users which is especially helpful during development of a certain feature 
> (although this is probably not a config you would set on a production 
> instance).



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

[jira] [Commented] (SLING-5051) RequestDispatcher forward breaks i18n

[Julian Sedding (JIRA)]

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

Julian Sedding commented on SLING-5051:
---

This is likely a symptom of SLING-5071, i.e. a problem with filter ordering. 
Your filter has {{service.ranking=0}} while the I18nFilter before SLING-5071 
has {{service.ranking=-700}}. Provided the unfortunate change in SLING-2920 
reversed the filter ordering (now in descending order), {{0}} now comes before 
{{-700}} and thus I18N is not yet initialized in your filter.

You can update the I18N Bundle to  version 2.4.6 to restore a proper ordering 
(note in AEM 6.1 the {{service.ranking}} of the I18nFilter is configured to 
-1 in {{/libs/sling/config}}), so take that into account. Please close this 
issue as duplicate of SLING-5071 if this solves your problem.

> RequestDispatcher forward breaks i18n
> -
>
> Key: SLING-5051
> URL: https://issues.apache.org/jira/browse/SLING-5051
> Project: Sling
>  Issue Type: Bug
>  Components: General
> Environment: Adobe Experience Manager 6.1
>Reporter: Sothea Nim
>
> I just noticed that on AEM 6, in my Filter, when I call RequestDispatcher 
> forward, i.e. request.getRequestDispatcher(...).forward(req, res);, it cause 
> i18n to break. Here's a snippet of my codes:
> ...
> boolean filtered = false;
> SlingHttpServletRequest request = req instanceof SlingHttpServletRequest ? 
> (SlingHttpServletRequest) req : null;
> SlingHttpServletResponse response = res instanceof SlingHttpServletResponse ? 
> (SlingHttpServletResponse) res : null;
> 
> if (request != null && response != null) {
> 
> // block of codes to resolve the request uri and get the new desired URI 
> 
> if (this.resolvedUriResource != null) {
> String uri = this.resolvedUriResource.getPath() + ".html";
> RequestDispatcherOptions options = new RequestDispatcherOptions();
> options.setAddSelectors(uriSelectors);
> 
> this.filterConfig.getServletContext().getRequestDispatcher(uri).forward(req, 
> res); // OR
> //request.getRequestDispatcher(this.resolvedUriResource, 
> options).forward(req, res);
> filtered = true;
> }
> }
> if (!filtered) {
> chain.doFilter(req, res);
> }
> ...
> Obtain the package contained detailed codes here: 
> http://www.sotheanim.com/images/www.sotheanim.com/blog/aem61-i18n-issue-samplepackage.zip
>  
> (/sixd/bundle/src/main/java/com/sixd/i18nissue/filter/PathResolutionFilter.java)



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

[jira] [Resolved] (SLING-5216) Concurrent creation of voting can lead to continuous re-voting

[Stefan Egli (JIRA)]

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

Stefan Egli resolved SLING-5216.

Resolution: Fixed

considering done as more testing didn't unveil a bug at this stage.

> Concurrent creation of voting can lead to continuous re-voting
> --
>
> Key: SLING-5216
> URL: https://issues.apache.org/jira/browse/SLING-5216
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Discovery Impl 1.0.2
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Blocker
> Fix For: Discovery Impl 1.2.0
>
>
> This is a regression of SLING-3195:
> With SLING-3195 the cluster view id was redefined from being a unique 
> per-voting/per view-incarnation id to being a stable, persisted, permanent 
> cluster Id (see [in 
> View.java|https://github.com/apache/sling/blob/bac2a2bf4c3ccdf6fa13866ffe6930c20b0230d6/bundles/extensions/discovery/impl/src/main/java/org/apache/sling/discovery/impl/common/View.java#L96]).
>  This was achieving the goal of exposing a stable view id for users of the 
> discovery API. 
> However, it introduced a regression in that this same {{getViewId()}} was 
> also used during voting when multiple votings happened simultaneously, to 
> agree on the lowest such 'view incarnation id'. With the change to making 
> this viewId the stable one though, and not adjusting its usage in this 
> multiple-votings-sorting, this sorting became broken. Basically now when 
> multiple votings happen simultaneously, then it can be that the participating 
> instances sort differently and don't agree on one vote. Resulting in the 
> {{HeartbeatHandler}} to come to the conclusion that there is no winner (as 
> there should only be 1), and start a fresh vote. Resulting in repeated new 
> votings being created.



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

[jira] [Created] (SLING-5226) Remove loginAdministrative() usage from org.apache.sling.servlets.post

[Antonio Sanso (JIRA)]

Antonio Sanso created SLING-5226:


 Summary: Remove loginAdministrative() usage from 
org.apache.sling.servlets.post 
 Key: SLING-5226
 URL: https://issues.apache.org/jira/browse/SLING-5226
 Project: Sling
  Issue Type: Improvement
  Components: Servlets
Reporter: Antonio Sanso


Counted 1 occurence



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

[jira] [Updated] (SLING-5227) Remove loginAdministrative() usage from org.apache.sling.bgservlets

[Antonio Sanso (JIRA)]

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

Antonio Sanso updated SLING-5227:
-
Summary: Remove loginAdministrative() usage from 
org.apache.sling.bgservlets  (was: Remove loginAdministrative() usage from 
org.apache.sling.bgservlet)

> Remove loginAdministrative() usage from org.apache.sling.bgservlets
> ---
>
> Key: SLING-5227
> URL: https://issues.apache.org/jira/browse/SLING-5227
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Antonio Sanso
>
> Counted 1 occurence



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

[jira] [Created] (SLING-5227) Remove loginAdministrative() usage from org.apache.sling.bgservlet

[Antonio Sanso (JIRA)]

Antonio Sanso created SLING-5227:


 Summary: Remove loginAdministrative() usage from 
org.apache.sling.bgservlet
 Key: SLING-5227
 URL: https://issues.apache.org/jira/browse/SLING-5227
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Antonio Sanso


Counted 1 occurence



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

[jira] [Created] (SLING-5230) Remove loginAdministrative() usage from org.apache.sling.event.dea

[Antonio Sanso (JIRA)]

Antonio Sanso created SLING-5230:


 Summary: Remove loginAdministrative() usage from 
org.apache.sling.event.dea
 Key: SLING-5230
 URL: https://issues.apache.org/jira/browse/SLING-5230
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Antonio Sanso


Counted 4 occurrences



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

[jira] [Updated] (SLING-5227) Remove loginAdministrative() usage from org.apache.sling.bgservlets

[Antonio Sanso (JIRA)]

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

Antonio Sanso updated SLING-5227:
-
Description: Counted 1 occurrence  (was: Counted 1 occurence)

> Remove loginAdministrative() usage from org.apache.sling.bgservlets
> ---
>
> Key: SLING-5227
> URL: https://issues.apache.org/jira/browse/SLING-5227
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Antonio Sanso
>
> Counted 1 occurrence



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

[jira] [Updated] (SLING-5226) Remove loginAdministrative() usage from org.apache.sling.servlets.post

[Antonio Sanso (JIRA)]

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

Antonio Sanso updated SLING-5226:
-
Description: Counted 1 occurrence  (was: Counted 1 occurence)

> Remove loginAdministrative() usage from org.apache.sling.servlets.post 
> ---
>
> Key: SLING-5226
> URL: https://issues.apache.org/jira/browse/SLING-5226
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Antonio Sanso
>
> Counted 1 occurrence



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

[jira] [Created] (SLING-5231) Remove getAdministrativeResourceResolver() usage from Discovery components

[Antonio Sanso (JIRA)]

Antonio Sanso created SLING-5231:


 Summary: Remove getAdministrativeResourceResolver() usage from 
Discovery components
 Key: SLING-5231
 URL: https://issues.apache.org/jira/browse/SLING-5231
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Antonio Sanso


* {{org.apache.sling.discovery.base}}: 6
* {{org.apache.sling.discovery.commons}}: 3
* {{org.apache.sling.discovery.oak}}: 4

total of 13 occurrences 



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

[jira] [Created] (SLING-5233) Remove loginAdministrative() usage from org.apache.sling.i18n

[Antonio Sanso (JIRA)]

Antonio Sanso created SLING-5233:


 Summary: Remove loginAdministrative() usage from 
org.apache.sling.i18n
 Key: SLING-5233
 URL: https://issues.apache.org/jira/browse/SLING-5233
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Antonio Sanso


counted 1 occurrence




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

[jira] [Created] (SLING-5235) Remove loginAdministrative() usage from org.apache.sling.resourceresolver

[Antonio Sanso (JIRA)]

Antonio Sanso created SLING-5235:


 Summary: Remove loginAdministrative() usage from 
org.apache.sling.resourceresolver
 Key: SLING-5235
 URL: https://issues.apache.org/jira/browse/SLING-5235
 Project: Sling
  Issue Type: Improvement
  Components: ResourceResolver
Reporter: Antonio Sanso


counted 6 occurrences




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

[jira] [Created] (SLING-5239) Remove loginAdministrative() usage from org.apache.sling.rewriter

[Antonio Sanso (JIRA)]

Antonio Sanso created SLING-5239:


 Summary: Remove loginAdministrative() usage from 
org.apache.sling.rewriter
 Key: SLING-5239
 URL: https://issues.apache.org/jira/browse/SLING-5239
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Antonio Sanso


Counted 1 occurrence 



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

[jira] [Updated] (SLING-5237) Remove loginAdministrative() usage from org.apache.sling.servlets.resolver

[Antonio Sanso (JIRA)]

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

Antonio Sanso updated SLING-5237:
-
Description: Counted 2 occurrences  (was: Counted 2 occurences)

> Remove loginAdministrative() usage from org.apache.sling.servlets.resolver
> --
>
> Key: SLING-5237
> URL: https://issues.apache.org/jira/browse/SLING-5237
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Antonio Sanso
>
> Counted 2 occurrences



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

[jira] [Created] (SLING-5228) Remove loginAdministrative() usage from org.apache.sling.installer.provider.jcr

[Antonio Sanso (JIRA)]

Antonio Sanso created SLING-5228:


 Summary: Remove loginAdministrative() usage from 
org.apache.sling.installer.provider.jcr
 Key: SLING-5228
 URL: https://issues.apache.org/jira/browse/SLING-5228
 Project: Sling
  Issue Type: Improvement
  Components: Installer
Reporter: Antonio Sanso


Counted 4 occuerences



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

[jira] [Created] (SLING-5229) Remove getAdministrativeResourceResolver() and loginAdministrative() usage from JCR components

[Antonio Sanso (JIRA)]

Antonio Sanso created SLING-5229:


 Summary: Remove getAdministrativeResourceResolver() and 
loginAdministrative() usage from JCR components
 Key: SLING-5229
 URL: https://issues.apache.org/jira/browse/SLING-5229
 Project: Sling
  Issue Type: Improvement
  Components: JCR
Reporter: Antonio Sanso


* {{org.apache.sling.jcr.compiler}} : 1
* {{org.apache.sling.installer.provider.jcr}}: 4
* {{org.apache.sling.jcr.base}}: 2
* {{org.apache.sling.jcr.contentloader}}: 2
* {{org.apache.sling.jcr.davex}}: 1
* {{org.apache.sling.jcr.resource}}: 5

total of 15 occurences




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

[jira] [Updated] (SLING-5228) Remove loginAdministrative() usage from org.apache.sling.installer.provider.jcr

[Antonio Sanso (JIRA)]

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

Antonio Sanso updated SLING-5228:
-
Description: Counted 4 occurrences  (was: Counted 4 occuerences)

> Remove loginAdministrative() usage from 
> org.apache.sling.installer.provider.jcr
> ---
>
> Key: SLING-5228
> URL: https://issues.apache.org/jira/browse/SLING-5228
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer
>Reporter: Antonio Sanso
>
> Counted 4 occurrences



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

[jira] [Updated] (SLING-5230) Remove getAdministrativeResourceResolver() usage from org.apache.sling.event.dea

[Antonio Sanso (JIRA)]

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

Antonio Sanso updated SLING-5230:
-
Summary: Remove getAdministrativeResourceResolver() usage from 
org.apache.sling.event.dea  (was: Remove loginAdministrative() usage from 
org.apache.sling.event.dea)

> Remove getAdministrativeResourceResolver() usage from 
> org.apache.sling.event.dea
> 
>
> Key: SLING-5230
> URL: https://issues.apache.org/jira/browse/SLING-5230
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Antonio Sanso
>
> Counted 4 occurrences



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

[jira] [Created] (SLING-5232) Remove loginAdministrative() usage from org.apache.sling.event

[Antonio Sanso (JIRA)]

Antonio Sanso created SLING-5232:


 Summary: Remove loginAdministrative() usage from 
org.apache.sling.event
 Key: SLING-5232
 URL: https://issues.apache.org/jira/browse/SLING-5232
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Antonio Sanso


counted 1 occurrence



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

[jira] [Created] (SLING-5234) Remove loginAdministrative() usage from org.apache.sling.xss

[Antonio Sanso (JIRA)]

Antonio Sanso created SLING-5234:


 Summary: Remove loginAdministrative() usage from 
org.apache.sling.xss
 Key: SLING-5234
 URL: https://issues.apache.org/jira/browse/SLING-5234
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Antonio Sanso


counted 1 occurrence



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

[jira] [Created] (SLING-5236) Remove loginAdministrative() usage from sightly Compontents

[Antonio Sanso (JIRA)]

Antonio Sanso created SLING-5236:


 Summary: Remove loginAdministrative() usage from sightly 
Compontents
 Key: SLING-5236
 URL: https://issues.apache.org/jira/browse/SLING-5236
 Project: Sling
  Issue Type: Improvement
  Components: Scripting
Reporter: Antonio Sanso


* {{org.apache.sling.scripting.core}}: 2
* {{org.apache.sling.scripting.sightly}}: 3
* {{org.apache.sling.scripting.sightly.js.provider}}: 2

total of 7 occurrences



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

[jira] [Created] (SLING-5237) Remove loginAdministrative() usage from org.apache.sling.servlets.resolver

[Antonio Sanso (JIRA)]

Antonio Sanso created SLING-5237:


 Summary: Remove loginAdministrative() usage from 
org.apache.sling.servlets.resolver
 Key: SLING-5237
 URL: https://issues.apache.org/jira/browse/SLING-5237
 Project: Sling
  Issue Type: Improvement
  Components: Servlets
Reporter: Antonio Sanso


Counted 2 occurences



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

[jira] [Created] (SLING-5238) Remove loginAdministrative() usage from org.apache.sling.resource.inventory

[Antonio Sanso (JIRA)]

Antonio Sanso created SLING-5238:


 Summary: Remove loginAdministrative() usage from 
org.apache.sling.resource.inventory
 Key: SLING-5238
 URL: https://issues.apache.org/jira/browse/SLING-5238
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Antonio Sanso


Counted 1 occurrence 



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