planning release of org.apache.sling.nosql.*

[Stefan Seifert]

during the last months i implemented a new generic support for NoSQL resource 
providers in Sling and implemented two specific adapters for MongoDB and 
Couchbase. with this new approach it's quite easy to add support for additional 
NoSQL document stores because the major complexities of resource interaction 
and mapping to documents are implemented once in a generic way.

a documentation page can be found at [1]
source code of the nosql-related projects is at [2]

if no one objects i will prepare votes for 1.0.0 releases for the four major 
bundles this week:
- generic
- mongodb-resourceprovider
- couchbase-client
- couchbase-resourceprovider

stefan

p.s. the "NoSQL MongoDB resource provider" is an alternative implementation to 
the "MongoDB resource provider" from 2012 that exists at [3]. although i took 
some inspiration from it, the new implementation is quite different and 
supports more features and has a good test coverage. on the long term the 
former should probably replace the latter.


[1] http://sling.apache.org/documentation/bundles/nosql-resource-providers.html
[2] https://svn.apache.org/repos/asf/sling/trunk/contrib/nosql

[3] https://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/mongodb

[jira] [Comment Edited] (SLING-4801) Add support for Nashorn in the JavaScript Scripting Engine

[Radu Cotescu (JIRA)]

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

Radu Cotescu edited comment on SLING-4801 at 9/15/15 10:02 PM:
---

While researching how to implement this I've also worked on a Sightly 
JavaScript Use Provider using the Nashorn implementation. The Sightly 
performance tests only showed a 25% performance increase of running the same 
JavaScript code on Nashorn instead of Rhino.

However my opinion is that we should instead try to optimise the Rhino 
implementation (see SLING-913 and SLING-915) due to the multiple environment 
restrictions that Nashorn currently imposes:

* run Sling on JRE > =1.8.0_45 (Nashorn had performance problems before)
* there's no way to currently provide the same JS implementation of the 
Resource API
* Nashorn has to be configured specifically for Sling's use case so that all 
its caching strategies are turned on; for Sling's use case - running multiple 
small JavaScript scripts repeatedly - Nashorn is not necessarily the best 
option due to its relatively slow warmup

For further reference I've attached a patch ([^SLING-4801.patch]) that provides 
the following features:
* a new {{org.apache.sling.scripting.javascript.nashorn}} bundle that only runs 
on JRE >= 1.8
* a new {{org.apache.sling.scripting.sightly.js.provider.nashorn}} bundle that 
takes advantage of the Nashorn features
* it exposes the {{jdk.nashorn.api.scripting;version="0.0.0.1_008_JavaSE"}} 
package for JRE 1.8
* it provides a way to test the performance improvements through the Sightly 
performance tests, which is currently the most important consumer for the 
JavaScript scripting engine




was (Author: radu.cotescu):
While researching how to implement this I've also worked on a Sightly 
JavaScript Use Provider using the Nashorn implementation. The Sightly 
performance tests only showed a 25% performance increase of running the same 
JavaScript code on Nashorn instead of Rhino.

However my opinion is that we should instead try to optimise the Rhino 
implementation (see SLING-913 and SLING-915) due the multiple environment 
restrictions that Nashorn currently imposes:

* run Sling on JRE > =1.8.0_45 (Nashorn had performance problems before)
* there's no way to currently provide the same JS implementation of the 
Resource API
* Nashorn has to be configured specifically for Sling's use case so that all 
its caching strategies are turned on; for Sling's use case - running multiple 
small JavaScript scripts repeatedly - Nashorn is not necessarily the best 
option due to its relatively slow warmup

For further reference I've attached a patch ([^SLING-4801.patch]) that provides 
the following features:
* a new {{org.apache.sling.scripting.javascript.nashorn}} bundle that only runs 
on JRE >= 1.8
* a new {{org.apache.sling.scripting.sightly.js.provider.nashorn}} bundle that 
takes advantage of the Nashorn features
* it exposes the {{jdk.nashorn.api.scripting;version="0.0.0.1_008_JavaSE"}} 
package for JRE 1.8
* it provides a way to test the performance improvements through the Sightly 
performance tests, which is currently the most important consumer for the 
JavaScript scripting engine



> Add support for Nashorn in the JavaScript Scripting Engine
> --
>
> Key: SLING-4801
> URL: https://issues.apache.org/jira/browse/SLING-4801
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Affects Versions: Scripting JavaScript 2.0.16
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Attachments: SLING-4801.patch
>
>
> The {{org.apache.sling.scripting.javascript}} bundle should attempt to use 
> Nashorn, if available on the user's platform, for running JS code. 
> Alternatively it should switch to Rhino if the JRE is < 1.8.
> Requirements:
> * need to expose the 
> {{jdk.nashorn.api.scripting;version="0.0.0.1_008_JavaSE"}} package on JRE >= 
> 1.8 in Sling's {{launchpad/base/src/main/resources/jre-1.8.properties}} 
> properties files
> * the Rhino and Nashorn implementations need to co-exist, so that customers 
> still running on Java < 8 can use the Rhino implementation; the switch from 
> Rhino to Nashorn should happen automatically but should also be made 
> configurable in case customers really want to use a specific implementation; 
> while the Nashorn implementation requires Java 8 (and this can easily be 
> handled through the {{Require-Capability}} \[0\] and 
> {{Bundle-RequiredExecutionEnvironment}} \[1\] manifest headers) and the 
> bundle implementing Nashorn support won't start if the detected Java version 
> is < 8, a non-sticky run mode / configuration should handle the switch if 
> customers would still like to use the Rhino implementation on Java >= 8
> * need to find a way to 

Re: ResourceResolverFactory restart behaviour

[Konrad Windszus]

Yes, SLING-4360 added a check if the RRF is live to the method 
ResourceResolver.isLive(). The problem is that you have to call that method 
explicitly.
For me the use case is rather to detect programming mistakes like not listening 
for ResourceResolverFactory restarts. 
What about implicitly calling RR.isLive for every other method?
Actually the Javadoc for all RR methods already states it will throw an 
IllegalArgumentException if the RR has been closed already. I would expect the 
same exception in case the resource resolver factory has been closed (maybe 
with a different, more explicit error message).
What was the reason why only the RR.isLive method was modified with SLING-4360?
Konrad


> On 14 Sep 2015, at 20:57, Carsten Ziegeler  wrote:
> 
> Am 14.09.15 um 18:04 schrieb Konrad Windszus:
>> Thanks Carsten, indeed I am hitting SLING-4974.
>> Could you point me to the commit which closes the resource resolvers after 
>> the restart of the factory (or after some required providers become 
>> unavailable)?
>> I couldn’t find any related commit in 
>> https://github.com/apache/sling/commits/trunk/bundles/resourceresolver/src/main/java/org/apache/sling/resourceresolver/impl
>>  
>> .
>> In which version of the resource resolver bundle is that implemented?
>> At least with resource resolver 1.2.4 this is not the case.
> 
> Then we might have a bug still in there, it's SLING-4360 which is
> version 1.1.12. Afaik, we did some tests back then and it seemed to
> work, but maybe it's not handling all cases properly?
> 
> Regards
> Carsten
> 
>> Thanks,
>> Konrad
>> 
>>> On 14 Sep 2015, at 17:55, Carsten Ziegeler  wrote:
>>> 
>>> Am 14.09.15 um 17:51 schrieb Konrad Windszus:
 Currently if the resource resolver factory is restarted (e.g. because the 
 configuration has been changed) all resource resolvers which were being 
 requested beforehand become almost useless, because they have no longer 
 any providers being bound! This means those resolvers can only be used to 
 retrieve the entry points below “/“ but nothing beyond that.
 Therefore if you forget to refresh a resource resolver after the resource 
 resolver factory has been restarted you get very weird results. One 
 example of this behaviour is being described in 
 https://issues.apache.org/jira/browse/SLING-5023.
 What about marking those resource resolvers as invalid (because they do no 
 longer have the required resource providers being bound) and let all 
 methods being called on those resource resolvers fail with an 
 IllegalStateException?
 That way those kind of programming mistakes would be more obvious!
 Thanks for your opinions on that.
 Konrad
 
 
>>> Hi
>>> 
>>> I think you're hitting a dub of SLING-4974 and afaik with the latest
>>> resource resolver impl we mark the resolvers as closed :)
>>> 
>>> Carsten
>>> 
>>> -- 
>>> Carsten Ziegeler
>>> Adobe Research Switzerland
>>> cziege...@apache.org
>> 
>> 
> 
> 
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

[jira] [Closed] (SLING-4825) Add ability to handle webdav based DELETE requests

[Satya Deep Maheshwari (JIRA)]

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

Satya Deep Maheshwari closed SLING-4825.


> Add ability to handle webdav based DELETE requests
> --
>
> Key: SLING-4825
> URL: https://issues.apache.org/jira/browse/SLING-4825
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Reporter: Satya Deep Maheshwari
>Assignee: Bertrand Delacretaz
> Fix For: JCR Webdav 2.3.2, Launchpad Builder 8
>
> Attachments: SLING-4825.patch
>
>
> Recently 'delete handler' was added in jackrabbit. This provides the ability 
> to add handlers for handling webdav based 'delete' requests. See JCR-3884 
> containing details on this feature. Earlier this ability was just available 
> for other webdav operations like to copy/move etc. but was missing for 
> 'delete'  . 
> Sling has written its own managers to keep track of these handlers. See [1] 
> which has pre-existing handler managers like  SlingCopyMoveManager. 
> The intent of this jira issue is to add a delete handler manager so that the 
> delete handler functionality can now be leveraged in Sling.
> [1] - 
> https://github.com/apache/sling/tree/trunk/bundles/jcr/webdav/src/main/java/org/apache/sling/jcr/webdav/impl/handler



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

[jira] [Commented] (SLING-4825) Add ability to handle webdav based DELETE requests

[Satya Deep Maheshwari (JIRA)]

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

Satya Deep Maheshwari commented on SLING-4825:
--

Thanks.

> Add ability to handle webdav based DELETE requests
> --
>
> Key: SLING-4825
> URL: https://issues.apache.org/jira/browse/SLING-4825
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Reporter: Satya Deep Maheshwari
>Assignee: Bertrand Delacretaz
> Fix For: JCR Webdav 2.3.2, Launchpad Builder 8
>
> Attachments: SLING-4825.patch
>
>
> Recently 'delete handler' was added in jackrabbit. This provides the ability 
> to add handlers for handling webdav based 'delete' requests. See JCR-3884 
> containing details on this feature. Earlier this ability was just available 
> for other webdav operations like to copy/move etc. but was missing for 
> 'delete'  . 
> Sling has written its own managers to keep track of these handlers. See [1] 
> which has pre-existing handler managers like  SlingCopyMoveManager. 
> The intent of this jira issue is to add a delete handler manager so that the 
> delete handler functionality can now be leveraged in Sling.
> [1] - 
> https://github.com/apache/sling/tree/trunk/bundles/jcr/webdav/src/main/java/org/apache/sling/jcr/webdav/impl/handler



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

[jira] [Created] (SLING-5025) Make ResourceResolver methods throw ISE in case the according factory is unregistered

[Konrad Windszus (JIRA)]

Konrad Windszus created SLING-5025:
--

 Summary: Make ResourceResolver methods throw ISE in case the 
according factory is unregistered
 Key: SLING-5025
 URL: https://issues.apache.org/jira/browse/SLING-5025
 Project: Sling
  Issue Type: Improvement
  Components: ResourceResolver
Affects Versions: Resource Resolver 1.2.6
Reporter: Konrad Windszus


In SLING-4360 the {{ResourceResolver.isLive()}} method was extended to check if 
the {{ResourceResolverFactory}} has been unregistered in the mean time. That 
check should be done in addition for every method on the resource resolver and 
should throw an ISE in case the factory is no longer registered.

See also the discussion at 
http://www.mail-archive.com/dev@sling.apache.org/msg49364.html.



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

Re: ResourceResolverFactory restart behaviour

[Konrad Windszus]

Ok, thanks for the confirmation. I created issue 
https://issues.apache.org/jira/browse/SLING-5025 for that.
The only question is, whether the check for context.isLive() should also be 
done within the checkClosed()?

In theory I guess one could still use a resource resolver if one of the used 
providers is gone. Of course this is not the case for the JcrResourceProvider 
but since this is a required provider it would lead to an unregistration of the 
whole RRF.

> On 15 Sep 2015, at 09:35, Carsten Ziegeler  wrote:
> 
> Am 15.09.15 um 08:37 schrieb Konrad Windszus:
>> Yes, SLING-4360 added a check if the RRF is live to the method 
>> ResourceResolver.isLive(). The problem is that you have to call that method 
>> explicitly.
>> For me the use case is rather to detect programming mistakes like not 
>> listening for ResourceResolverFactory restarts. 
>> What about implicitly calling RR.isLive for every other method?
> 
> Oh, I see, every method calls checkClosed() which doesn't check the
> active flag. I think we should add this there as well.
> 
>> Actually the Javadoc for all RR methods already states it will throw an 
>> IllegalArgumentException if the RR has been closed already. I would expect 
>> the same exception in case the resource resolver factory has been closed 
>> (maybe with a different, more explicit error message).
>> What was the reason why only the RR.isLive method was modified with 
>> SLING-4360?
> 
> Good question :) I guess, it's just an oversight (aka bug) :)
> 
> Carsten
> 
>> Konrad
>> 
>> 
>>> On 14 Sep 2015, at 20:57, Carsten Ziegeler  wrote:
>>> 
>>> Am 14.09.15 um 18:04 schrieb Konrad Windszus:
 Thanks Carsten, indeed I am hitting SLING-4974.
 Could you point me to the commit which closes the resource resolvers after 
 the restart of the factory (or after some required providers become 
 unavailable)?
 I couldn’t find any related commit in 
 https://github.com/apache/sling/commits/trunk/bundles/resourceresolver/src/main/java/org/apache/sling/resourceresolver/impl
  
 .
 In which version of the resource resolver bundle is that implemented?
 At least with resource resolver 1.2.4 this is not the case.
>>> 
>>> Then we might have a bug still in there, it's SLING-4360 which is
>>> version 1.1.12. Afaik, we did some tests back then and it seemed to
>>> work, but maybe it's not handling all cases properly?
>>> 
>>> Regards
>>> Carsten
>>> 
 Thanks,
 Konrad
 
> On 14 Sep 2015, at 17:55, Carsten Ziegeler  wrote:
> 
> Am 14.09.15 um 17:51 schrieb Konrad Windszus:
>> Currently if the resource resolver factory is restarted (e.g. because 
>> the configuration has been changed) all resource resolvers which were 
>> being requested beforehand become almost useless, because they have no 
>> longer any providers being bound! This means those resolvers can only be 
>> used to retrieve the entry points below “/“ but nothing beyond that.
>> Therefore if you forget to refresh a resource resolver after the 
>> resource resolver factory has been restarted you get very weird results. 
>> One example of this behaviour is being described in 
>> https://issues.apache.org/jira/browse/SLING-5023.
>> What about marking those resource resolvers as invalid (because they do 
>> no longer have the required resource providers being bound) and let all 
>> methods being called on those resource resolvers fail with an 
>> IllegalStateException?
>> That way those kind of programming mistakes would be more obvious!
>> Thanks for your opinions on that.
>> Konrad
>> 
>> 
> Hi
> 
> I think you're hitting a dub of SLING-4974 and afaik with the latest
> resource resolver impl we mark the resolvers as closed :)
> 
> Carsten
> 
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
 
 
>>> 
>>> 
>>> -- 
>>> Carsten Ziegeler
>>> Adobe Research Switzerland
>>> cziege...@apache.org
>> 
>> 
> 
> 
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Compatibility of Sling with Oak 1.2

[Konrad Windszus]

I just ran into the problem that the package version of 
org/apache/jackrabbit/oak/plugins/observation changed from 1.0 (in Oak prior 
1.3) to 2.0  (since Oak 1.3).
This is a major version change not compatible with any version ranges being 
generated by the maven-bundle-plugin.

Due to this fact the dependency to Oak Core was raised to 1.3 in the JCR 
Resource bundle (in https://issues.apache.org/jira/browse/SLING-4820 
).
This leads to the fact, that now the JCR Resource bundle is no longer 
compatible with older versions of Oak (at least the OakResourceListener isn’t)
Since Oak 1.2 is considered the stable release branch it would be beneficial if 
Sling could support this version.

What is the policy of supporting Oak 1.2 in Sling?
Thanks for your input,
Konrad

Re: ResourceResolverFactory restart behaviour

[Carsten Ziegeler]

Am 15.09.15 um 08:37 schrieb Konrad Windszus:
> Yes, SLING-4360 added a check if the RRF is live to the method 
> ResourceResolver.isLive(). The problem is that you have to call that method 
> explicitly.
> For me the use case is rather to detect programming mistakes like not 
> listening for ResourceResolverFactory restarts. 
> What about implicitly calling RR.isLive for every other method?

Oh, I see, every method calls checkClosed() which doesn't check the
active flag. I think we should add this there as well.

> Actually the Javadoc for all RR methods already states it will throw an 
> IllegalArgumentException if the RR has been closed already. I would expect 
> the same exception in case the resource resolver factory has been closed 
> (maybe with a different, more explicit error message).
> What was the reason why only the RR.isLive method was modified with 
> SLING-4360?

Good question :) I guess, it's just an oversight (aka bug) :)

Carsten

> Konrad
> 
> 
>> On 14 Sep 2015, at 20:57, Carsten Ziegeler  wrote:
>>
>> Am 14.09.15 um 18:04 schrieb Konrad Windszus:
>>> Thanks Carsten, indeed I am hitting SLING-4974.
>>> Could you point me to the commit which closes the resource resolvers after 
>>> the restart of the factory (or after some required providers become 
>>> unavailable)?
>>> I couldn’t find any related commit in 
>>> https://github.com/apache/sling/commits/trunk/bundles/resourceresolver/src/main/java/org/apache/sling/resourceresolver/impl
>>>  
>>> .
>>> In which version of the resource resolver bundle is that implemented?
>>> At least with resource resolver 1.2.4 this is not the case.
>>
>> Then we might have a bug still in there, it's SLING-4360 which is
>> version 1.1.12. Afaik, we did some tests back then and it seemed to
>> work, but maybe it's not handling all cases properly?
>>
>> Regards
>> Carsten
>>
>>> Thanks,
>>> Konrad
>>>
 On 14 Sep 2015, at 17:55, Carsten Ziegeler  wrote:

 Am 14.09.15 um 17:51 schrieb Konrad Windszus:
> Currently if the resource resolver factory is restarted (e.g. because the 
> configuration has been changed) all resource resolvers which were being 
> requested beforehand become almost useless, because they have no longer 
> any providers being bound! This means those resolvers can only be used to 
> retrieve the entry points below “/“ but nothing beyond that.
> Therefore if you forget to refresh a resource resolver after the resource 
> resolver factory has been restarted you get very weird results. One 
> example of this behaviour is being described in 
> https://issues.apache.org/jira/browse/SLING-5023.
> What about marking those resource resolvers as invalid (because they do 
> no longer have the required resource providers being bound) and let all 
> methods being called on those resource resolvers fail with an 
> IllegalStateException?
> That way those kind of programming mistakes would be more obvious!
> Thanks for your opinions on that.
> Konrad
>
>
 Hi

 I think you're hitting a dub of SLING-4974 and afaik with the latest
 resource resolver impl we mark the resolvers as closed :)

 Carsten

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


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

Re: Compatibility of Sling with Oak 1.2

[Bertrand Delacretaz]

Hi,

On Tue, Sep 15, 2015 at 9:26 AM, Konrad Windszus  wrote:
> ...What is the policy of supporting Oak 1.2 in Sling?...

I don't think we have a defined policy so far - in general I like our
tests to run against the latest Oak to stay on top of things, but
you're right that it makes sense to also support the latest stable
version.

Do you know what changes are needed for that?

-Bertrand

Re: [VOTE] Release Apache Sling Testing ResourceResolver Mock 1.1.10

[Stefan Egli]

+1

Cheers,
Stefan

On 11/09/15 00:16, "Stefan Seifert"  wrote:

>Hi,
>
>We solved 1 issues in this release:
>https://issues.apache.org/jira/browse/SLING/fixforversion/12333290
>
>Staging repository:
>https://repository.apache.org/content/repositories/orgapachesling-1330/
>
>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 1330 /tmp/sling-staging
>
>Please vote to approve this release:
>
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
>
>This majority vote is open for at least 72 hours.
>
>
>stefan

Re: [RESULT] [VOTE] Release Apache Sling Testing JCR Mock 1.1.10, Sling Mock 1.5.0

[Robert Munteanu]

On Mon, 2015-09-14 at 18:55 +0200, Stefan Seifert wrote:
> @any PMC member: please  copy this release to the Sling dist
> directory.
> 
> stefan

Done in r10515 and r10516 .

Robert



> 
> 
> > -Original Message-
> > From: Stefan Seifert [mailto:sseif...@pro-vision.de]
> > Sent: Thursday, September 10, 2015 11:11 PM
> > To: dev@sling.apache.org
> > Subject: [RESULT] [VOTE] Release Apache Sling Testing JCR Mock
> > 1.1.10, Sling
> > Mock 1.5.0
> > 
> > Hi,
> > 
> > The vote has passed with the following result :
> > 
> > +1 (binding): Robert Munteanu, Carsten Ziegeler, Stefan Egli
> > 
> > 
> > I will promote the artifacts to the central Maven repository and
> > update the
> > maven site.
> > 
> > @any PMC member: please  copy this release to the Sling dist
> > directory.
> > 
> > 
> > stefan

[jira] [Updated] (SLING-5025) Make ResourceResolver methods throw ISE in case the according factory is unregistered

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-5025:
---
Attachment: SLING-5025-api.v01.diff
SLING-5025-resourceresolver.v01.diff

Attached are two patches which
# extend the javadoc for the ResourceResolver to make clear when an ISE can be 
expected
# throw the ISE on all RR methods in case the factory is no longer active

[~cziegeler] Can you have a look?

> Make ResourceResolver methods throw ISE in case the according factory is 
> unregistered
> -
>
> Key: SLING-5025
> URL: https://issues.apache.org/jira/browse/SLING-5025
> Project: Sling
>  Issue Type: Improvement
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.2.6
>Reporter: Konrad Windszus
> Attachments: SLING-5025-api.v01.diff, 
> SLING-5025-resourceresolver.v01.diff
>
>
> In SLING-4360 the {{ResourceResolver.isLive()}} method was extended to check 
> if the {{ResourceResolverFactory}} has been unregistered in the mean time. 
> That check should be done in addition for every method on the resource 
> resolver and should throw an ISE in case the factory is no longer registered.
> See also the discussion at 
> http://www.mail-archive.com/dev@sling.apache.org/msg49364.html.



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

Re: [VOTE] Release Apache Sling Models API 1.2.2, Models Impl 1.2.2

[Stefan Egli]

+1

Cheers,
Stefan

On 11/09/15 00:05, "Stefan Seifert"  wrote:

>Hi,
>
>Sling Models API 1.2.2 (2 issues)
>https://issues.apache.org/jira/browse/SLING/fixforversion/12332841
>
>Sling Models Impl 1.2.2 (2 issues)
>https://issues.apache.org/jira/browse/SLING/fixforversion/12332842
>
>
>Staging repository:
>https://repository.apache.org/content/repositories/orgapachesling-1329/
>
>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 1329 /tmp/sling-staging
>
>Please vote to approve this release:
>
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
>
>This majority vote is open for at least 72 hours.
>
>
>stefan
>

Re: ResourceResolverFactory restart behaviour

[Carsten Ziegeler]

Am 15.09.15 um 09:50 schrieb Konrad Windszus:
> Ok, thanks for the confirmation. I created issue 
> https://issues.apache.org/jira/browse/SLING-5025 for that.
> The only question is, whether the check for context.isLive() should also be 
> done within the checkClosed()?
> 
Yes, I think checkClosed should check the same stuff as RR.isLive is
currently doing.

Carsten


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

[jira] [Created] (SLING-5026) Allow to set multiple validation error messages in one Validator

[Konrad Windszus (JIRA)]

Konrad Windszus created SLING-5026:
--

 Summary: Allow to set multiple validation error messages in one 
Validator
 Key: SLING-5026
 URL: https://issues.apache.org/jira/browse/SLING-5026
 Project: Sling
  Issue Type: Improvement
Affects Versions: Validation 1.0.0
Reporter: Konrad Windszus
Assignee: Konrad Windszus
 Fix For: Validation 1.0.0


Currently each {{Validator}} can only set one error message through the String 
return value (SLING-4010). It should be possible for one {{Validator.validate}} 
call to set multiple validation messages at once.
May the solution [~radu.cotescu] proposed in 
https://issues.apache.org/jira/browse/SLING-4027?focusedCommentId=14219170=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14219170
 can be used here to just pass the ValidationResult around.



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

Re: Compatibility of Sling with Oak 1.2

[Konrad Windszus]

In the case of https://issues.apache.org/jira/browse/SLING-4820 
 there is no simple solution 
to support both Oak 1.2 and 1.3.
Since Oak incremented the major version of the package (although at first 
glance the used interfaces from 
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/observation/NodeObserver.java
 

 look like they haven’t been changed), the only solution would be to increase 
the version range of the Import-Package statement within the JCR Resource 
bundle manually to cover both 1.0 and 2.0. But this looks really like a hack 
and is IMHO too dangerous, as it may lead to not-running bundles although all 
dependencies could be resolved.
This is exactly what we want to prevent with semantic versioning.
Konrad

> On 15 Sep 2015, at 11:22, Bertrand Delacretaz  wrote:
> 
> Hi,
> 
> On Tue, Sep 15, 2015 at 9:26 AM, Konrad Windszus  wrote:
>> ...What is the policy of supporting Oak 1.2 in Sling?...
> 
> I don't think we have a defined policy so far - in general I like our
> tests to run against the latest Oak to stay on top of things, but
> you're right that it makes sense to also support the latest stable
> version.
> 
> Do you know what changes are needed for that?
> 
> -Bertrand

Re: [VOTE] Release Apache Sling Testing ResourceResolver Mock 1.1.10

[Robert Munteanu]

On Fri, 2015-09-11 at 00:16 +0200, Stefan Seifert wrote:
> Please vote to approve this release:

+1

Robert

[jira] [Commented] (SLING-5025) Make ResourceResolver methods throw ISE in case the according factory is unregistered

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-5025:
-

For 2. : I think you want to check if it's not live and then throw :)
For 1. : I think we should change the description of when the RR is considered 
closed: it's either closed if done by calling the method or if the factory gets 
inactive etc. This saves us from having the rather longthy description on each 
method. WDYT?

> Make ResourceResolver methods throw ISE in case the according factory is 
> unregistered
> -
>
> Key: SLING-5025
> URL: https://issues.apache.org/jira/browse/SLING-5025
> Project: Sling
>  Issue Type: Improvement
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.2.6
>Reporter: Konrad Windszus
> Attachments: SLING-5025-api.v01.diff, 
> SLING-5025-resourceresolver.v01.diff
>
>
> In SLING-4360 the {{ResourceResolver.isLive()}} method was extended to check 
> if the {{ResourceResolverFactory}} has been unregistered in the mean time. 
> That check should be done in addition for every method on the resource 
> resolver and should throw an ISE in case the factory is no longer registered.
> See also the discussion at 
> http://www.mail-archive.com/dev@sling.apache.org/msg49364.html.



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

[jira] [Updated] (SLING-5025) Make ResourceResolver methods throw ISE in case the according factory is unregistered

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-5025:
---
Attachment: SLING-5025.v02.diff

Attached is a second patch incorporating [~cziegeler]s feedback. 
I am still not sure about the {{context.isLive()}} check 
(http://www.mail-archive.com/dev@sling.apache.org/msg49389.html).
I included that also in the {{checkClosed}} method as suggested, but as far as 
I can see, even if that returns {{false}}, the ResourceResolver will not be 
automatically closed, therefore the javadoc might not fit 100% in that case.
[~cziegeler] Do you have a suggestion on how to state that correctly in the 
javadoc of ResourceResolver?

> Make ResourceResolver methods throw ISE in case the according factory is 
> unregistered
> -
>
> Key: SLING-5025
> URL: https://issues.apache.org/jira/browse/SLING-5025
> Project: Sling
>  Issue Type: Improvement
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.2.6
>Reporter: Konrad Windszus
> Attachments: SLING-5025-api.v01.diff, 
> SLING-5025-resourceresolver.v01.diff, SLING-5025.v02.diff
>
>
> In SLING-4360 the {{ResourceResolver.isLive()}} method was extended to check 
> if the {{ResourceResolverFactory}} has been unregistered in the mean time. 
> That check should be done in addition for every method on the resource 
> resolver and should throw an ISE in case the factory is no longer registered.
> See also the discussion at 
> http://www.mail-archive.com/dev@sling.apache.org/msg49364.html.



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

[jira] [Commented] (SLING-5025) Make ResourceResolver methods throw ISE in case the according factory is unregistered

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-5025:
-

Thanks, the changes  look basically good - except for the duplicate !isLive 
check :)
However, after looking at context.isLive()  again, I think we shouldn't check 
it for is closed.

> Make ResourceResolver methods throw ISE in case the according factory is 
> unregistered
> -
>
> Key: SLING-5025
> URL: https://issues.apache.org/jira/browse/SLING-5025
> Project: Sling
>  Issue Type: Improvement
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.2.6
>Reporter: Konrad Windszus
> Attachments: SLING-5025-api.v01.diff, 
> SLING-5025-resourceresolver.v01.diff, SLING-5025.v02.diff
>
>
> In SLING-4360 the {{ResourceResolver.isLive()}} method was extended to check 
> if the {{ResourceResolverFactory}} has been unregistered in the mean time. 
> That check should be done in addition for every method on the resource 
> resolver and should throw an ISE in case the factory is no longer registered.
> See also the discussion at 
> http://www.mail-archive.com/dev@sling.apache.org/msg49364.html.



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

[RESULT] [VOTE] Release Apache Sling Rewriter 1.1.0

[Stefan Seifert]

Hi,

The vote has passed with the following result :

+1 (binding): Daniel Klco, Carsten Ziegeler, Antonio Sanso

I will promote the artifacts to the central Maven repository and update the 
sling site.

@any PMC member: please copy this release to the Sling dist directory.


stefan

[jira] [Commented] (SLING-5025) Make ResourceResolver methods throw ISE in case the according factory is unregistered

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-5025:


I committed the fix without the check for context.isLive in 
http://svn.apache.org/r1703188.

> Make ResourceResolver methods throw ISE in case the according factory is 
> unregistered
> -
>
> Key: SLING-5025
> URL: https://issues.apache.org/jira/browse/SLING-5025
> Project: Sling
>  Issue Type: Improvement
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.2.6
>Reporter: Konrad Windszus
> Fix For: API 2.10.0, Resource Resolver 1.2.8
>
> Attachments: SLING-5025-api.v01.diff, 
> SLING-5025-resourceresolver.v01.diff, SLING-5025.v02.diff
>
>
> In SLING-4360 the {{ResourceResolver.isLive()}} method was extended to check 
> if the {{ResourceResolverFactory}} has been unregistered in the mean time. 
> That check should be done in addition for every method on the resource 
> resolver and should throw an ISE in case the factory is no longer registered.
> See also the discussion at 
> http://www.mail-archive.com/dev@sling.apache.org/msg49364.html.



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

[jira] [Resolved] (SLING-5025) Make ResourceResolver methods throw ISE in case the according factory is unregistered

[Konrad Windszus (JIRA)]

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

Konrad Windszus resolved SLING-5025.

   Resolution: Fixed
Fix Version/s: Resource Resolver 1.2.8
   API 2.10.0

> Make ResourceResolver methods throw ISE in case the according factory is 
> unregistered
> -
>
> Key: SLING-5025
> URL: https://issues.apache.org/jira/browse/SLING-5025
> Project: Sling
>  Issue Type: Improvement
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.2.6
>Reporter: Konrad Windszus
> Fix For: API 2.10.0, Resource Resolver 1.2.8
>
> Attachments: SLING-5025-api.v01.diff, 
> SLING-5025-resourceresolver.v01.diff, SLING-5025.v02.diff
>
>
> In SLING-4360 the {{ResourceResolver.isLive()}} method was extended to check 
> if the {{ResourceResolverFactory}} has been unregistered in the mean time. 
> That check should be done in addition for every method on the resource 
> resolver and should throw an ISE in case the factory is no longer registered.
> See also the discussion at 
> http://www.mail-archive.com/dev@sling.apache.org/msg49364.html.



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

[jira] [Commented] (SLING-4849) Create Metrics instumentation bundle using ASM.

[Ian Boston (JIRA)]

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

Ian Boston commented on SLING-4849:
---

The intention was that it should be available by default with a standard config 
suitable for Sling launchpad (probably basic probes, exposed in JMX) so that 
writing custom JMX metrics beans becomes largely unnecessary, and every Sling 
instance gets metrics. It could be moved to /contrib, although nothing in the 
code base makes it specific to Sling.

> Create Metrics instumentation bundle using ASM.
> ---
>
> Key: SLING-4849
> URL: https://issues.apache.org/jira/browse/SLING-4849
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Ian Boston
>Assignee: Ian Boston
> Attachments: Screen Shot 2015-07-02 at 12.24.01.png, Screen Shot 
> 2015-07-02 at 12.24.18.png, Screen Shot 2015-07-02 at 12.24.27.png
>
>
> Aim: To enable metrics for any method call in a Sling JVM without requiring 
> any code changes to existing bundles.
> Method: OSGi 4.3 has a WeavingHook which is allows a byte code generator to 
> get in between the classloader and classloading. Using ASM it should be 
> possible to write code that enhances the byte code of any class to wrap 
> method calls in calls to the Dropwizard Metrics library. This should work 
> without any changes to the startup. The only requirement is the bundle is 
> loaded before the classloader loads the classes that need to be instrumented. 
> Quick tests indicate the method works and adds no more than 10 byte code 
> instructions to a method. It may be possible to reduce that further. 
> Instrumentation will be controlled by configuration, so classes that are not 
> instrumented are not modified at all when loading.
> The metrics once available can be pushed into Graphite, Kibana or some other 
> collection service. Dumped to a file periodically or exposed in JMX as 
> counters.
> Will work in a branch on github initially.



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

[jira] [Closed] (SLING-5013) Sling Models API: Add @ProviderType/@ConsumerType annotations

[Stefan Seifert (JIRA)]

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

Stefan Seifert closed SLING-5013.
-

> Sling Models API: Add @ProviderType/@ConsumerType annotations
> -
>
> Key: SLING-5013
> URL: https://issues.apache.org/jira/browse/SLING-5013
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Sling Models API 1.2.0
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Minor
>  Labels: models
> Fix For: Sling Models API 1.2.2
>
>
> to get better support from the bundle baseline check we should mark all API 
> interfaces/classes with @ProviderType/@ConsumerType annotations.



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

[jira] [Closed] (SLING-5012) Sling Rewriter: Check unwrapped resources as well for resource type matching

[Stefan Seifert (JIRA)]

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

Stefan Seifert closed SLING-5012.
-

> Sling Rewriter: Check unwrapped resources as well for resource type matching
> 
>
> Key: SLING-5012
> URL: https://issues.apache.org/jira/browse/SLING-5012
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: Extensions Rewriter 1.0.4
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: rewriter
> Fix For: Extensions Rewriter 1.1.0
>
>
> Currently resource type matching for a resource type in rewriter 
> configuration fails if during the rendering the resource type was overwritten 
> using a ResourceWrapper with an alternate type.
> We should add a new configuration property that enabled checking the resource 
> types of the unwrapped resources as well.



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

[jira] [Closed] (SLING-5007) resourceresolver-mock: listChildren broken for root path "/"

[Stefan Seifert (JIRA)]

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

Stefan Seifert closed SLING-5007.
-

> resourceresolver-mock: listChildren broken for root path "/"
> 
>
> Key: SLING-5007
> URL: https://issues.apache.org/jira/browse/SLING-5007
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: Testing ResourceResolver Mock 1.1.8
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Critical
>  Labels: mocks
> Fix For: Testing ResourceResolver Mock 1.1.10
>
>
> listChildren("/") is broken and returns no result.



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

[jira] [Closed] (SLING-5011) Sling Rewriter: Update Sling API Dependency to 2.4.0

[Stefan Seifert (JIRA)]

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

Stefan Seifert closed SLING-5011.
-

> Sling Rewriter: Update Sling API Dependency to 2.4.0
> 
>
> Key: SLING-5011
> URL: https://issues.apache.org/jira/browse/SLING-5011
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Extensions Rewriter 1.0.4
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: rewriter
> Fix For: Extensions Rewriter 1.1.0
>
>
> Currently the Sling Rewriter depends on Sling API 2.1.0.
> We want to update it to 2.4.0 (which is still quite old), it's the minimal 
> version supported by Sling Mocks.
> The existing unit test (its only one class testing the matching) should be 
> rewritten to sling mocks to be easier maintainable.



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

[jira] [Closed] (SLING-4997) Inconsistency in ModelFactory.isModelClass()

[Stefan Seifert (JIRA)]

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

Stefan Seifert closed SLING-4997.
-

> Inconsistency in ModelFactory.isModelClass()
> 
>
> Key: SLING-4997
> URL: https://issues.apache.org/jira/browse/SLING-4997
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Sling Models API 1.2.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Sling Models API 1.2.2, Sling Models Impl 1.2.2
>
>
> With the changes in SLING-4056 there was a change on a method in the 
> {{ModelFactory}}:
> {{public boolean isModelClass(Class modelClass)}} became
> {{public boolean isModelClass(Object adaptable, Class type)}}
> The adaptable parameter was necessary because of the alternate adapter 
> classes defined in 
> https://sling.apache.org/documentation/bundles/models.html#specifying-an-alternate-adapter-class-since-sling-models-110.
> If you now have a Model defined like this
> {code}
> @Model(adaptables = Resource.class)
> public class MyModel
> {code}
> a call of {{ModelFactory.isModelClass(, 
> MyModel.class)}} returns {{true}}, although the model class is only defined 
> on the adaptable {{Resource}}. 
> On the other hand if you define a model like this
> {code}
> @Model(adapters=MyModel, adaptables = Resource.class)
> public class MyModelImpl implements MyModel
> {code}
> a call of {{ModelFactory.isModelClass(, 
> MyModel.class)}} returns {{false}}.



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

[jira] [Closed] (SLING-5010) Sling Models: Stale StaticInjectionAnnotationProcesssorFactory list depending on bundle startup order

[Stefan Seifert (JIRA)]

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

Stefan Seifert closed SLING-5010.
-

> Sling Models: Stale StaticInjectionAnnotationProcesssorFactory list depending 
> on bundle startup order
> -
>
> Key: SLING-5010
> URL: https://issues.apache.org/jira/browse/SLING-5010
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Sling Models Impl 1.2.0
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Critical
>  Labels: models
> Fix For: Sling Models Impl 1.2.2
>
>
> scenario:
> * sling models impl 1.2.0
> * another bundle providing custom sling model annotations with a custom 
> StaticInjectAnnotationProcessorFactory implementation
> * a sling model annotated with this custom annotation that has an flag 
> optional = true
> depending on startup order the optional flag is evaluated as true or false. 
> if one of the bundles is restarted the flag is evaluated correctly.
> reason: depending on startup order the model may get added to the 
> modeladapterfactory before the StaticInjectAnnotationProcessorFactory is 
> registered. than the optional flag is not evaluated correctly. if the 
> StaticInjectAnnotationProcessorFactory is registered a few moments later the 
> (wrong) result is still cached in the ModelClass instance.



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

[jira] [Closed] (SLING-3003) Add XML serializer

[Stefan Seifert (JIRA)]

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

Stefan Seifert closed SLING-3003.
-

> Add XML serializer
> --
>
> Key: SLING-3003
> URL: https://issues.apache.org/jira/browse/SLING-3003
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Extensions Rewriter 1.1.0
>
>
> We should add an xml serializer to get xml output from the pipeline



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

[RESULT] [VOTE] Release Apache Sling Testing ResourceResolver Mock 1.1.10

[Stefan Seifert]

Hi,

The vote has passed with the following result :

+1 (binding): Carsten Ziegeler, Stefan Egli, Robert Munteanu

I will promote the artifacts to the central Maven repository and update the 
sling site.

@any PMC member: please copy this release to the Sling dist directory.


stefan

[RESULT] [VOTE] Release Apache Sling Models API 1.2.2, Models Impl 1.2.2

[Stefan Seifert]

Hi,

The vote has passed with the following result :

+1 (binding): Carsten Ziegeler, Daniel Klco, Stefan Egli

I will promote the artifacts to the central Maven repository and update the 
sling site.

@any PMC member: please copy this release to the Sling dist directory.


stefan

[jira] [Created] (SLING-5027) vote loop until vote is promoted

[Stefan Egli (JIRA)]

Stefan Egli created SLING-5027:
--

 Summary: vote loop until vote is promoted
 Key: SLING-5027
 URL: https://issues.apache.org/jira/browse/SLING-5027
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: Discovery Impl 1.1.0
Reporter: Stefan Egli
Assignee: Stefan Egli
 Fix For: Discovery Impl 1.1.8


{{VotingHandler.analyzeVotings}} has the risk of running into a busy vote loop 
during the duration of an {{/ongoingVotings}}:
* {{analyzeVotings}} is invoked either when something changes in 
{{/var/discovery/impl/ongoingVotings}} or as part of a heartbeat
* as part of this, it figures out the ongoingVotings, decides on which it has 
to vote (should there be more than 1, and it doesn't vote if it was the 
initiator) then potentially does a {{vote(,true)}} on it
* in {{vote()}} it not only sets the {{vote}} property accordingly (true or 
false) - it additionally, since 
[SLING-3434|https://issues.apache.org/jira/browse/SLING-3434?focusedCommentId=14297078=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14297078],
 also sets the {{votedAt}} property (timestamp)
* since the above is a change in {{/ongoingVotings}}, this will trigger an 
observation event - which again triggers the {{analyzeVotings}} to be called, 
which will again find an ongoing vote, vote upon, trigger an observation event 
etc. Resulting in an endless loop that involves repository and an observation 
handler
* now the above loop only occurs since the introduction of the {{votedAt}} 
property - as that is changing on each iteration. Without that, voting again 
with the same boolean would not result in an observation event and the loop 
would not happen at all.
* in any case, the loop lasts at maximum until the initiator finally got all 
the votes and can promote the vote to an {{/establishedView}}. This should 
typically be a fast operation - but if the cluster is under heavy load and 
experiences delays for some reason, this busy loop can last a little while.

So this loop is a regression introduced with SLING-3434.



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

[jira] [Commented] (SLING-5027) vote loop until vote is promoted

[Stefan Egli (JIRA)]

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

Stefan Egli commented on SLING-5027:


Marked as a regression of SLING-3434

> vote loop until vote is promoted
> 
>
> Key: SLING-5027
> URL: https://issues.apache.org/jira/browse/SLING-5027
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Discovery Impl 1.1.0
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Discovery Impl 1.1.8
>
>
> {{VotingHandler.analyzeVotings}} has the risk of running into a busy vote 
> loop during the duration of an {{/ongoingVotings}}:
> * {{analyzeVotings}} is invoked either when something changes in 
> {{/var/discovery/impl/ongoingVotings}} or as part of a heartbeat
> * as part of this, it figures out the ongoingVotings, decides on which it has 
> to vote (should there be more than 1, and it doesn't vote if it was the 
> initiator) then potentially does a {{vote(,true)}} on it
> * in {{vote()}} it not only sets the {{vote}} property accordingly (true or 
> false) - it additionally, since 
> [SLING-3434|https://issues.apache.org/jira/browse/SLING-3434?focusedCommentId=14297078=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14297078],
>  also sets the {{votedAt}} property (timestamp)
> * since the above is a change in {{/ongoingVotings}}, this will trigger an 
> observation event - which again triggers the {{analyzeVotings}} to be called, 
> which will again find an ongoing vote, vote upon, trigger an observation 
> event etc. Resulting in an endless loop that involves repository and an 
> observation handler
> * now the above loop only occurs since the introduction of the {{votedAt}} 
> property - as that is changing on each iteration. Without that, voting again 
> with the same boolean would not result in an observation event and the loop 
> would not happen at all.
> * in any case, the loop lasts at maximum until the initiator finally got all 
> the votes and can promote the vote to an {{/establishedView}}. This should 
> typically be a fast operation - but if the cluster is under heavy load and 
> experiences delays for some reason, this busy loop can last a little while.
> So this loop is a regression introduced with SLING-3434.



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

[jira] [Commented] (SLING-5027) vote loop until vote is promoted

[Stefan Egli (JIRA)]

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

Stefan Egli commented on SLING-5027:


Note that this loop - besides being an additional resource-load while it lasts 
(typically only a few seconds though, but as mentioned this can be longer 
should the cluster experience delays and cause the vote in the first place, eg 
due to a heartbeat timeout..) - also has a higher risk of running into a 
conflict that would otherwise (without the votedAt guy) not occur. Here's an 
example of the conflict when running on oak:
{code}
Caused by: org.apache.jackrabbit.oak.api.CommitFailedException: OakState0001: 
Unresolved conflicts in /var/discovery/impl/ongoingVotings
at 
org.apache.jackrabbit.oak.plugins.commit.ConflictValidator.failOnMergeConflict(ConflictValidator.java:115)
at 
org.apache.jackrabbit.oak.plugins.commit.ConflictValidator.propertyAdded(ConflictValidator.java:84)
at 
org.apache.jackrabbit.oak.spi.commit.CompositeEditor.propertyAdded(CompositeEditor.java:83)
at 
org.apache.jackrabbit.oak.spi.commit.EditorDiff.propertyAdded(EditorDiff.java:82)
at 
org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.compareAgainstBaseState(ModifiedNodeState.java:375)
at 
org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:148)
at 
org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.compareAgainstBaseState(ModifiedNodeState.java:396)
at 
org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:148)
at 
org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.compareAgainstBaseState(ModifiedNodeState.java:396)
at 
org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:148)
at 
org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.compareAgainstBaseState(ModifiedNodeState.java:396)
at 
org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:148)
at 
org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.compareAgainstBaseState(ModifiedNodeState.java:396)
at 
org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:52)
at 
org.apache.jackrabbit.oak.spi.commit.EditorHook.processCommit(EditorHook.java:54)
at 
org.apache.jackrabbit.oak.spi.commit.CompositeHook.processCommit(CompositeHook.java:60)
at 
org.apache.jackrabbit.oak.spi.commit.CompositeHook.processCommit(CompositeHook.java:60)
at 
org.apache.jackrabbit.oak.spi.state.AbstractNodeStoreBranch$InMemory.merge(AbstractNodeStoreBranch.java:557)
at 
org.apache.jackrabbit.oak.spi.state.AbstractNodeStoreBranch.merge0(AbstractNodeStoreBranch.java:329)
at 
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge(DocumentNodeStoreBranch.java:148)
at 
org.apache.jackrabbit.oak.plugins.document.DocumentRootBuilder.merge(DocumentRootBuilder.java:159)
at 
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.merge(DocumentNodeStore.java:1473)
at 
org.apache.jackrabbit.oak.core.MutableRoot.commit(MutableRoot.java:247)
at 
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.commit(SessionDelegate.java:391)
at 
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.save(SessionDelegate.java:537)
{code}

> vote loop until vote is promoted
> 
>
> Key: SLING-5027
> URL: https://issues.apache.org/jira/browse/SLING-5027
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Discovery Impl 1.1.0
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Discovery Impl 1.1.8
>
>
> {{VotingHandler.analyzeVotings}} has the risk of running into a busy vote 
> loop during the duration of an {{/ongoingVotings}}:
> * {{analyzeVotings}} is invoked either when something changes in 
> {{/var/discovery/impl/ongoingVotings}} or as part of a heartbeat
> * as part of this, it figures out the ongoingVotings, decides on which it has 
> to vote (should there be more than 1, and it doesn't vote if it was the 
> initiator) then potentially does a {{vote(,true)}} on it
> * in {{vote()}} it not only sets the {{vote}} property accordingly (true or 
> false) - it additionally, since 
> [SLING-3434|https://issues.apache.org/jira/browse/SLING-3434?focusedCommentId=14297078=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14297078],
>  also sets the {{votedAt}} property (timestamp)
> * since the above is a change in {{/ongoingVotings}}, this will trigger an 
> observation event - which again triggers the {{analyzeVotings}} to be called, 
> which will again find an ongoing vote, vote upon, trigger an observation 
> event etc. Resulting in