Re: SLING-1437 as a part of Google Summer of Code 2015

[Petr Shypila]

Hello Bertrand,

Just want to notify that I have updated my previous report. First for all I
have attached a new patch with new unit tests(But I think you should apply
previous one as well).
You can find an updated patch file on JIRA ticket and wiki page.
Last changes are also on my GitHub repo:
https://github.com/PetrShypila/sling
Should I create a new pull request with these changes?
As I wrote in my PPP report I'm going start to write new tests for
commons.threads module.
What do you think about that?

Best regards,
Petr


2015-05-24 22:02 GMT+03:00 Petr Shypila :

> Hello Bertrand,
>
> At this time I have improved module code coverage up to 50%. Unfortunately
> it looks like sometimes I need more time to understand what the code does
> than to write tests for it.
> I started from pretty simple classes. Most of tests for them just are just
> testing references to objects after they were passed into methods(Does it
> make sense to spend a time on simple tests like these or it's redundant?).
> I have created a JIRA issue for this module: SLING-4735.
> And I also have updated a Confluence page. Please also take a look.
>
> Best regards,
> -Petr
>
> 2015-05-18 14:59 GMT+03:00 Bertrand Delacretaz :
>
>> On Mon, May 18, 2015 at 1:55 PM, Petr Shypila 
>> wrote:
>> > ...I'm going start to code today. So at the end of the week I will show
>> you
>> > some completed work...
>>
>> Ok great! Release early, release often, it doesn't have to be finished
>> before you show it to us!
>>
>> -Bertrand
>>
>
>

[jira] [Updated] (SLING-4735) New tests for commons.scheduler module

[Petr Shypila (JIRA)]

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

Petr Shypila updated SLING-4735:

Attachment: week0-ver2.patch

New patch version with new tests and code quality improvements has been 
attached.

> New tests for commons.scheduler module
> --
>
> Key: SLING-4735
> URL: https://issues.apache.org/jira/browse/SLING-4735
> Project: Sling
>  Issue Type: Test
>  Components: Commons
>Reporter: Petr Shypila
>Priority: Minor
>  Labels: gsoc2015
> Attachments: week0-commons-scheduler-tests.patch, week0-ver2.patch
>
>
> In scope of this issue I should cover commons.scheduler module with unit and 
> integration tests.



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

Jenkins build became unstable: sling-trunk-1.8 #1149

[Apache Jenkins Server]

See 

Jenkins build is still unstable: sling-contrib-1.7 #124

[Apache Jenkins Server]

See 

Build failed in Jenkins: sling-trunk-1.7 #1858

[Apache Jenkins Server]

See 

Changes:

[rombert] SLING-4605 - Add support for an Oak resource resolver type mock 

Indicate that the MemoryNodeStore is used for the Oak resource resolver
adapter

[bdelacretaz] SLING-4694 - pom cleanup

[bdelacretaz] SLING-4694 - remove files which are not needed

[bdelacretaz] SLING-4694 - new contentdetection module, contributed by Satya 
Deep Maheshwari, thanks!

--
[...truncated 54495 lines...]
[INFO] Apache Sling Compat Servlets .. SUCCESS [4.704s]
[INFO] Apache Sling Scripting Implementation API . SUCCESS [5.235s]
[INFO] Apache Sling Scripting Core implementation  SUCCESS [21.968s]
[INFO] Apache Sling Scripting JavaScript Support . SUCCESS [13.931s]
[INFO] Apache Sling Scripting JSP Support  SUCCESS [9.216s]
[INFO] Apache Sling JSP Tag Library .. SUCCESS [14.598s]
[INFO] Apache Sling JSP Standard Tag Library . SUCCESS [6.247s]
[INFO] Apache Sling Scripting Sightly Engine . SUCCESS [17.073s]
[INFO] Apache Sling Scripting Sightly JavaScript Use Provider  SUCCESS [12.340s]
[INFO] Apache Sling Scripting Sightly Read-Eval-Print Loop Environment  SUCCESS 
[5.876s]
[INFO] Apache Sling Scripting Sightly Integration Tests Content  SUCCESS 
[7.943s]
[INFO] Apache Sling Launchpad Base ... SUCCESS [23.464s]
[INFO] Apache Sling Adapter Manager Implementation ... SUCCESS [8.000s]
[INFO] Apache Sling Internationalization Support . SUCCESS [35.874s]
[INFO] Apache Sling XSS Protection Bundle  SUCCESS [15.391s]
[INFO] Apache Sling Validation Framework API . SUCCESS [5.511s]
[INFO] Apache Sling Models API ... SUCCESS [6.037s]
[INFO] Apache Sling Models Implementation  SUCCESS [7.490s]
[INFO] Apache Sling Launchpad Application Builder  SUCCESS [53.765s]
[INFO] Apache Sling Scripting Sightly Integration Tests .. SUCCESS [2:51.745s]
[INFO] Apache Sling Scripting Sightly Models Use Provider  SUCCESS [5.329s]
[INFO] Apache Sling Scripting Sightly Reactor  SUCCESS [2.049s]
[INFO] Apache Sling Bundle Resource Provider . SUCCESS [6.113s]
[INFO] Apache Sling Distributed Event Admin .. SUCCESS [7.245s]
[INFO] Apache Sling Discovery API  SUCCESS [6.650s]
[INFO] Apache Sling Discovery Commons Bundle . SUCCESS [4.073s]
[INFO] Apache Sling Resource-Based Discovery Service . SUCCESS [4:40.148s]
[INFO] Apache Sling Discovery Support Bundle . SUCCESS [4.281s]
[INFO] Apache Sling Discovery Standalone Implementation .. SUCCESS [3.624s]
[INFO] Apache Sling Event Support  SUCCESS [11:28.860s]
[INFO] Apache Sling Feature Flags  SUCCESS [5.505s]
[INFO] Apache Sling Filesystem Resource Provider . SUCCESS [4.133s]
[INFO] Apache Sling javax.activation bundle .. SUCCESS [5.855s]
[INFO] Apache Sling Service User Mapper .. SUCCESS [9.895s]
[INFO] Apache Sling Settings . SUCCESS [7.224s]
[INFO] Apache Sling Web Console Branding . SUCCESS [6.292s]
[INFO] Apache Sling Web Console Security Provider  SUCCESS [13.011s]
[INFO] Apache Sling Explorer . SUCCESS [12.565s]
[INFO] Apache Sling Health Check Core  SUCCESS [15.262s]
[INFO] Apache Sling Health Check Annotations . SUCCESS [9.210s]
[INFO] Apache Sling Health Check Samples . SUCCESS [15.805s]
[INFO] Apache Sling Health Check Support Components .. SUCCESS [14.882s]
[INFO] Apache Sling Health Check Webconsole Plugin ... SUCCESS [6.339s]
[INFO] Apache Sling Health Check JUnit Bridge  SUCCESS [9.714s]
[INFO] Apache Sling Health Check Integration Tests ... SUCCESS [34.505s]
[INFO] Apache Sling Health Check Reactor POM . SUCCESS [2.360s]
[INFO] Apache Sling Resource Access Security . SUCCESS [5.655s]
[INFO] Apache Sling Resource Access Security Integration Tests  SUCCESS 
[31.752s]
[INFO] Apache Sling Validation Framework Core Implementation  SUCCESS [14.239s]
[INFO] Apache Sling Validation Framework Testing Services  SUCCESS [5.121s]
[INFO] Apache Sling Validation Framework Integration Tests  SUCCESS [24.387s]
[INFO] Apache Sling Validation Framework Examples  SUCCESS [4.968s]
[INFO] Apache Sling Validation Framework Builder . SUCCESS [2.088s]
[INFO] Apache Sling Models Integration Tests . SUCCESS [32.551s]
[INFO] Apache Sling Test Tools ... FAILURE [0.201s]
[INFO] Apache Sling JUnit Core ... SKIPPED
[INFO] Apache Sling JUnit Scriptable Tests Provider .. SKIPPED
[INFO] Apache Sling JUnit Health Checks .. SKIPPED
[INFO] Apache Sling JUnit Remote Tests Run

Jenkins build is back to stable : sling-trunk-1.7 #1857

[Apache Jenkins Server]

See 

[jira] [Commented] (SLING-4605) Add support for an Oak resource resolver type mock

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-4605:


Minor documentation cleanups applied, resolving.

> Add support for an Oak resource resolver type mock
> --
>
> Key: SLING-4605
> URL: https://issues.apache.org/jira/browse/SLING-4605
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Testing Sling Mock Oak 0.1.0
>
>
> As we have Oak support in the launchpad now and there are some internal 
> differences between Oak and Jackrabbit it would be good to be able to test 
> against an Oak repository instance.



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

[jira] [Resolved] (SLING-4605) Add support for an Oak resource resolver type mock

[Robert Munteanu (JIRA)]

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

Robert Munteanu resolved SLING-4605.

Resolution: Fixed

> Add support for an Oak resource resolver type mock
> --
>
> Key: SLING-4605
> URL: https://issues.apache.org/jira/browse/SLING-4605
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Testing Sling Mock Oak 0.1.0
>
>
> As we have Oak support in the launchpad now and there are some internal 
> differences between Oak and Jackrabbit it would be good to be able to test 
> against an Oak repository instance.



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

[jira] [Commented] (SLING-4756) ServiceListener notifications are not filtered

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-4756:


Another option is to rebase the OSGi mocks on top of [Apache Felix 
Connect|https://svn.apache.org/repos/asf/felix/trunk/connect/] ( formerly 
[PojoSR|https://code.google.com/p/pojosr/] ) , but I'm not sure if that will 
what we want and keep the project lightweight.

> ServiceListener notifications are not filtered
> --
>
> Key: SLING-4756
> URL: https://issues.apache.org/jira/browse/SLING-4756
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: Testing OSGi Mock 1.3.0
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Testing OSGi Mock 1.3.2
>
>
> While working on SLING-4605 I noticed many ClassCastExceptions filling the 
> logs ( see below ). Similar exceptions are also present for the 
> mock-jackrabbit module, only less verbose ( not stack traces )
> {noformat}
> 5432 [oak-executor-1] WARN 
> org.apache.jackrabbit.oak.jcr.observation.ChangeProcessor - Error while 
> dispatching observation events for 
> ///*[1b]@org.apache.sling.jcr.resource.internal.JcrResourceListener
> java.lang.ClassCastException: 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider cannot 
> be cast to org.osgi.service.event.EventAdmin
> at 
> org.apache.sling.jcr.resource.internal.JcrResourceListener.onEvent(JcrResourceListener.java:173)
> at 
> org.apache.jackrabbit.commons.observation.ListenerTracker$1.onEvent(ListenerTracker.java:164)
> at 
> org.apache.jackrabbit.oak.jcr.observation.ChangeProcessor.contentChanged(ChangeProcessor.java:302)
> at 
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:125)
> at 
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:119)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745){noformat}
> The root cause is that when registering a {{ServiceTracker}} for a given 
> class name the service tracker receives all registered services after it has 
> been instantiated. The fix is the following
> - when registering a service the mandatory {{objectClass}} property must be 
> set for the {{ServiceReference}}'s properties
> - implement simple filtering based on the {{objectClass}} parameter in 
> {{MockBundleContext}}
> - notify only interested {{ServiceListener}} instances based on the filter 
> they are registered with



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

[jira] [Commented] (SLING-4694) Add ability to identify mime type based on file content

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-4694:


Thanks very much for your contribution, I have committed the new content 
detection module in http://svn.apache.org/r1682035

There's still some minor cleanup left that I'll do until tomorrow hopefully, 
but the module can be used for your webdav servlet enhancements already.

> Add ability to identify mime type based on file content
> ---
>
> Key: SLING-4694
> URL: https://issues.apache.org/jira/browse/SLING-4694
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Affects Versions: JCR Webdav 2.2.2
>Reporter: Satya Deep Maheshwari
> Attachments: SLING-4694.patch
>
>
> *Problem description:* I am facing a problem with the mime type detection of 
> a file. While debugging, I see that SlingTikaDetector.detect method is used 
> for detecting the mime type of my file. See [1]. This method just seems to 
> rely on the name of the file for detecting its mime type. Even though its 
> passed an inputstream of the file, it does not seem to use it for mime type 
> detection. So if my file name is something like xyz.tmp, it detects its mime 
> type as application/octet-stream (the default) while it may actually be a png 
> file. This is a common scenario with webdav clients wherein temporary files 
> get created with such names while being edited.
> *Suggested Solution:* 
> Quoting [~rombert]
> {quote}
> Following the discussions at SLING-1059 [1] and SLING-255 [2] I can
> infer that we more or less opted out of the 'heavy-weight' approach of
> actually parsing the input stream. Not sure if we want to revisit that
> TBH. At any rate, our MimeTypeService does not have an API for getting
> the file content based on the input stream.
> I think though there's a way around it, but only at the code level.
> The org.apache.sling.jcr.webdav.impl.helper.SlingResourceConfig class
> hardcodes the Detector implementation to be a SlingTikaDetector.
> I think it is worthwile to raise a Jira issue for this and it would
> definitely expedite the fix if you're willing to submit a patch / pull
> request. I think it can be as simple as adding a @Reference to a Tika
> Detector to the SlingWebDavServlet and then passing that to the
> SlingServletConfig.
> Cheers,
> Robert
> [1]: https://issues.apache.org/jira/browse/SLING-1059
> [2]: https://issues.apache.org/jira/browse/SLING-255
> {quote}
> Related mailing-list thread on this: 
> http://apache-sling.73963.n3.nabble.com/mime-type-detection-td4050586.html



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

Re: [VOTE] Release Apache Sling Background Servlets Engine 1.0.0

[Robert Munteanu]

+1

Robert

On Wed, May 27, 2015 at 3:39 PM, Daniel Klco  wrote:
> +1
>
> On Wed, May 27, 2015 at 6:33 AM, Bertrand Delacretaz > wrote:
>
>> Hi,
>>
>> This is the (long overdue) first release of this module.
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachesling-1253/
>>
>> 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 1253 /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.
>>
>> Here's my +1.
>>
>> -Bertrand
>>

[jira] [Commented] (SLING-4756) ServiceListener notifications are not filtered

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-4756:


The Apache Directory implementation will drag in loads of dependencies ( see 
https://github.com/apache/directory-shared/blob/trunk/ldap/model/pom.xml ) , 
while the openDS artifact on Maven central is old ( 2007 ) and has 6.3 MB. I'd 
rather not pull in that many dependencies.

> ServiceListener notifications are not filtered
> --
>
> Key: SLING-4756
> URL: https://issues.apache.org/jira/browse/SLING-4756
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: Testing OSGi Mock 1.3.0
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Testing OSGi Mock 1.3.2
>
>
> While working on SLING-4605 I noticed many ClassCastExceptions filling the 
> logs ( see below ). Similar exceptions are also present for the 
> mock-jackrabbit module, only less verbose ( not stack traces )
> {noformat}
> 5432 [oak-executor-1] WARN 
> org.apache.jackrabbit.oak.jcr.observation.ChangeProcessor - Error while 
> dispatching observation events for 
> ///*[1b]@org.apache.sling.jcr.resource.internal.JcrResourceListener
> java.lang.ClassCastException: 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider cannot 
> be cast to org.osgi.service.event.EventAdmin
> at 
> org.apache.sling.jcr.resource.internal.JcrResourceListener.onEvent(JcrResourceListener.java:173)
> at 
> org.apache.jackrabbit.commons.observation.ListenerTracker$1.onEvent(ListenerTracker.java:164)
> at 
> org.apache.jackrabbit.oak.jcr.observation.ChangeProcessor.contentChanged(ChangeProcessor.java:302)
> at 
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:125)
> at 
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:119)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745){noformat}
> The root cause is that when registering a {{ServiceTracker}} for a given 
> class name the service tracker receives all registered services after it has 
> been instantiated. The fix is the following
> - when registering a service the mandatory {{objectClass}} property must be 
> set for the {{ServiceReference}}'s properties
> - implement simple filtering based on the {{objectClass}} parameter in 
> {{MockBundleContext}}
> - notify only interested {{ServiceListener}} instances based on the filter 
> they are registered with



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

Jenkins build became unstable: sling-trunk-1.7 #1856

[Apache Jenkins Server]

See 

[jira] [Commented] (SLING-4756) ServiceListener notifications are not filtered

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-4756:


{quote}filter support is missing currently completely in osgi-mock, main reason 
is i avoided up to now to implement a parser for the ldap-style query syntax. 
perhaps there is a library to integrate in the mocks?{quote}

Sorry, missed your comment. There seem to be a number of alternatives listed at 
[1] . We can even consider reusing/embedding 
{{org.apache.felix.framework.FilterImpl}}.

[1]: 
http://stackoverflow.com/questions/1027307/is-there-a-standalone-java-library-which-provides-ldap-style-parsing

> ServiceListener notifications are not filtered
> --
>
> Key: SLING-4756
> URL: https://issues.apache.org/jira/browse/SLING-4756
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: Testing OSGi Mock 1.3.0
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Testing OSGi Mock 1.3.2
>
>
> While working on SLING-4605 I noticed many ClassCastExceptions filling the 
> logs ( see below ). Similar exceptions are also present for the 
> mock-jackrabbit module, only less verbose ( not stack traces )
> {noformat}
> 5432 [oak-executor-1] WARN 
> org.apache.jackrabbit.oak.jcr.observation.ChangeProcessor - Error while 
> dispatching observation events for 
> ///*[1b]@org.apache.sling.jcr.resource.internal.JcrResourceListener
> java.lang.ClassCastException: 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider cannot 
> be cast to org.osgi.service.event.EventAdmin
> at 
> org.apache.sling.jcr.resource.internal.JcrResourceListener.onEvent(JcrResourceListener.java:173)
> at 
> org.apache.jackrabbit.commons.observation.ListenerTracker$1.onEvent(ListenerTracker.java:164)
> at 
> org.apache.jackrabbit.oak.jcr.observation.ChangeProcessor.contentChanged(ChangeProcessor.java:302)
> at 
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:125)
> at 
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:119)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745){noformat}
> The root cause is that when registering a {{ServiceTracker}} for a given 
> class name the service tracker receives all registered services after it has 
> been instantiated. The fix is the following
> - when registering a service the mandatory {{objectClass}} property must be 
> set for the {{ServiceReference}}'s properties
> - implement simple filtering based on the {{objectClass}} parameter in 
> {{MockBundleContext}}
> - notify only interested {{ServiceListener}} instances based on the filter 
> they are registered with



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

[jira] [Commented] (SLING-4756) ServiceListener notifications are not filtered

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-4756:
---

filter support is missing currently completely in osgi-mock, main reason is i 
avoided up to now to implement a parser for the ldap-style query syntax. 
perhaps there is a library to integrate in the mocks?

> ServiceListener notifications are not filtered
> --
>
> Key: SLING-4756
> URL: https://issues.apache.org/jira/browse/SLING-4756
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: Testing OSGi Mock 1.3.0
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Testing OSGi Mock 1.3.2
>
>
> While working on SLING-4605 I noticed many ClassCastExceptions filling the 
> logs ( see below ). Similar exceptions are also present for the 
> mock-jackrabbit module, only less verbose ( not stack traces )
> {noformat}
> 5432 [oak-executor-1] WARN 
> org.apache.jackrabbit.oak.jcr.observation.ChangeProcessor - Error while 
> dispatching observation events for 
> ///*[1b]@org.apache.sling.jcr.resource.internal.JcrResourceListener
> java.lang.ClassCastException: 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider cannot 
> be cast to org.osgi.service.event.EventAdmin
> at 
> org.apache.sling.jcr.resource.internal.JcrResourceListener.onEvent(JcrResourceListener.java:173)
> at 
> org.apache.jackrabbit.commons.observation.ListenerTracker$1.onEvent(ListenerTracker.java:164)
> at 
> org.apache.jackrabbit.oak.jcr.observation.ChangeProcessor.contentChanged(ChangeProcessor.java:302)
> at 
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:125)
> at 
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:119)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745){noformat}
> The root cause is that when registering a {{ServiceTracker}} for a given 
> class name the service tracker receives all registered services after it has 
> been instantiated. The fix is the following
> - when registering a service the mandatory {{objectClass}} property must be 
> set for the {{ServiceReference}}'s properties
> - implement simple filtering based on the {{objectClass}} parameter in 
> {{MockBundleContext}}
> - notify only interested {{ServiceListener}} instances based on the filter 
> they are registered with



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

Jenkins build is still unstable: sling-contrib-1.7 #123

[Apache Jenkins Server]

See 

[jira] [Resolved] (SLING-4756) ServiceListener notifications are not filtered

[Robert Munteanu (JIRA)]

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

Robert Munteanu resolved SLING-4756.

Resolution: Fixed

This is now fixed based on the issue description. This might not be 100% 
backwards compatible with how the OSGi mocks behaved since ServiceListeners 
registered with a filter which were previously (incorrectly) invoked are no 
longer invoked, but the behavior should be correct.

Maybe it's worth discussing if when encountering an unsupported filter 
specification we should simply fail hard with an exception instead of ignoring 
it, like it does now.

> ServiceListener notifications are not filtered
> --
>
> Key: SLING-4756
> URL: https://issues.apache.org/jira/browse/SLING-4756
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: Testing OSGi Mock 1.3.0
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Testing OSGi Mock 1.3.2
>
>
> While working on SLING-4605 I noticed many ClassCastExceptions filling the 
> logs ( see below ). Similar exceptions are also present for the 
> mock-jackrabbit module, only less verbose ( not stack traces )
> {noformat}
> 5432 [oak-executor-1] WARN 
> org.apache.jackrabbit.oak.jcr.observation.ChangeProcessor - Error while 
> dispatching observation events for 
> ///*[1b]@org.apache.sling.jcr.resource.internal.JcrResourceListener
> java.lang.ClassCastException: 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider cannot 
> be cast to org.osgi.service.event.EventAdmin
> at 
> org.apache.sling.jcr.resource.internal.JcrResourceListener.onEvent(JcrResourceListener.java:173)
> at 
> org.apache.jackrabbit.commons.observation.ListenerTracker$1.onEvent(ListenerTracker.java:164)
> at 
> org.apache.jackrabbit.oak.jcr.observation.ChangeProcessor.contentChanged(ChangeProcessor.java:302)
> at 
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:125)
> at 
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:119)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745){noformat}
> The root cause is that when registering a {{ServiceTracker}} for a given 
> class name the service tracker receives all registered services after it has 
> been instantiated. The fix is the following
> - when registering a service the mandatory {{objectClass}} property must be 
> set for the {{ServiceReference}}'s properties
> - implement simple filtering based on the {{objectClass}} parameter in 
> {{MockBundleContext}}
> - notify only interested {{ServiceListener}} instances based on the filter 
> they are registered with



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

[jira] [Updated] (SLING-4756) ServiceListener notifications are not filtered

[Robert Munteanu (JIRA)]

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

Robert Munteanu updated SLING-4756:
---
Description: 
While working on SLING-4605 I noticed many ClassCastExceptions filling the logs 
( see below ). Similar exceptions are also present for the mock-jackrabbit 
module, only less verbose ( not stack traces )
{noformat}
5432 [oak-executor-1] WARN 
org.apache.jackrabbit.oak.jcr.observation.ChangeProcessor - Error while 
dispatching observation events for 
///*[1b]@org.apache.sling.jcr.resource.internal.JcrResourceListener
java.lang.ClassCastException: 
org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider cannot be 
cast to org.osgi.service.event.EventAdmin
at 
org.apache.sling.jcr.resource.internal.JcrResourceListener.onEvent(JcrResourceListener.java:173)
at 
org.apache.jackrabbit.commons.observation.ListenerTracker$1.onEvent(ListenerTracker.java:164)
at 
org.apache.jackrabbit.oak.jcr.observation.ChangeProcessor.contentChanged(ChangeProcessor.java:302)
at 
org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:125)
at 
org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:119)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745){noformat}

The root cause is that when registering a {{ServiceTracker}} for a given class 
name the service tracker receives all registered services after it has been 
instantiated. The fix is the following

- when registering a service the mandatory {{objectClass}} property must be set 
for the {{ServiceReference}}'s properties
- implement simple filtering based on the {{objectClass}} parameter in 
{{MockBundleContext}}
- notify only interested {{ServiceListener}} instances based on the filter they 
are registered with

  was:When registering a service the mandatory {{objectClass}} property must be 
set for the {{ServiceReference}}'s properties.


> ServiceListener notifications are not filtered
> --
>
> Key: SLING-4756
> URL: https://issues.apache.org/jira/browse/SLING-4756
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: Testing OSGi Mock 1.3.0
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Testing OSGi Mock 1.3.2
>
>
> While working on SLING-4605 I noticed many ClassCastExceptions filling the 
> logs ( see below ). Similar exceptions are also present for the 
> mock-jackrabbit module, only less verbose ( not stack traces )
> {noformat}
> 5432 [oak-executor-1] WARN 
> org.apache.jackrabbit.oak.jcr.observation.ChangeProcessor - Error while 
> dispatching observation events for 
> ///*[1b]@org.apache.sling.jcr.resource.internal.JcrResourceListener
> java.lang.ClassCastException: 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider cannot 
> be cast to org.osgi.service.event.EventAdmin
> at 
> org.apache.sling.jcr.resource.internal.JcrResourceListener.onEvent(JcrResourceListener.java:173)
> at 
> org.apache.jackrabbit.commons.observation.ListenerTracker$1.onEvent(ListenerTracker.java:164)
> at 
> org.apache.jackrabbit.oak.jcr.observation.ChangeProcessor.contentChanged(ChangeProcessor.java:302)
> at 
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:125)
> at 
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:119)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745){noformat}
> The root cause is that when registering a {{ServiceTracker}} for a given 
> class name the service tracker receives all registered services after it has 
> been instantiated. The fix is the following
> - when registering a service the mandatory {{objectClass}} property must be 
> set for the {{ServiceReference}}'s properties
> - implement simple filtering based on the {{objectClass}} parameter in 
> {{MockBundleContext}}
> - notify only interested {{ServiceListener}} instances based on the filter 
> they are registered with



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

[jira] [Updated] (SLING-4756) ServiceListener notifications are not filtered

[Robert Munteanu (JIRA)]

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

Robert Munteanu updated SLING-4756:
---
Summary: ServiceListener notifications are not filtered  (was: Service 
registration does not set the mandatory objectClass property)

> ServiceListener notifications are not filtered
> --
>
> Key: SLING-4756
> URL: https://issues.apache.org/jira/browse/SLING-4756
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: Testing OSGi Mock 1.3.0
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Testing OSGi Mock 1.3.2
>
>
> When registering a service the mandatory {{objectClass}} property must be set 
> for the {{ServiceReference}}'s properties.



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

[jira] [Commented] (SLING-4751) New Observation Support

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-4751:
-

Deal, thanks, I've updated the description.

> New Observation Support
> ---
>
> Key: SLING-4751
> URL: https://issues.apache.org/jira/browse/SLING-4751
> Project: Sling
>  Issue Type: Improvement
>  Components: API, JCR, ResourceResolver
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: API 2.10.0, Resource Resolver 1.2.6
>
>
> Mail thread:
> http://mail-archives.apache.org/mod_mbox/sling-dev/201505.mbox/%3C555983F2.20402%40apache.org%3E
> Starting mail
> Right now, resources changes are propagated through event admin - which
> at the time sounded like a good idea. Over time, this has shown to be a
> bottle neck.
> Basically there are at least three problems:
> - the sender of the resource events does not know whether there is a
> receiver, therefore events for each and every change need to be sent
> - event objects are immutable and therefore all relevant data needs to
> be calculated upfront, even if it's not used. For example a resource
> event contains the resource type which needs to be fetched from the
> repository, even if no one is interested in it.
> - receivers of the events can't easily act on behalf of the user who
> initiated the change.
> I created a new listener api at [1] which defines a ResourceListener
> interface and some ways how to specify the events one is interested in.
> The user aware resource listener allows to act on behalf of the user (if
> that information is available).
> On the other side, a new service, the ObservationReporter [2] is
> defined. Resource providers report changes through this interface. The
> payload of such an event is an interface which allows for lazy retrieval
> of the information.
> We can also use this mechanism for compatibility and an implementation
> of the observation reporter might sent all events via the event admin.
> [1]
> https://svn.apache.org/repos/asf/sling/whiteboard/cziegeler/api-v3/src/main/java/org/apache/sling/api/resource/observation/
> [2]
> https://svn.apache.org/repos/asf/sling/whiteboard/cziegeler



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

[jira] [Commented] (SLING-4751) New Observation Support

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-4751:


bq. I think the serviceuser property is currently better described...

Still, I had to reread that description several times to understand it ;-)

How about "Required property containing the service user name to use for the 
ResourceResolver passed to onChange, if the change event does not provide the 
actual user" ?


> New Observation Support
> ---
>
> Key: SLING-4751
> URL: https://issues.apache.org/jira/browse/SLING-4751
> Project: Sling
>  Issue Type: Improvement
>  Components: API, JCR, ResourceResolver
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: API 2.10.0, Resource Resolver 1.2.6
>
>
> Mail thread:
> http://mail-archives.apache.org/mod_mbox/sling-dev/201505.mbox/%3C555983F2.20402%40apache.org%3E
> Starting mail
> Right now, resources changes are propagated through event admin - which
> at the time sounded like a good idea. Over time, this has shown to be a
> bottle neck.
> Basically there are at least three problems:
> - the sender of the resource events does not know whether there is a
> receiver, therefore events for each and every change need to be sent
> - event objects are immutable and therefore all relevant data needs to
> be calculated upfront, even if it's not used. For example a resource
> event contains the resource type which needs to be fetched from the
> repository, even if no one is interested in it.
> - receivers of the events can't easily act on behalf of the user who
> initiated the change.
> I created a new listener api at [1] which defines a ResourceListener
> interface and some ways how to specify the events one is interested in.
> The user aware resource listener allows to act on behalf of the user (if
> that information is available).
> On the other side, a new service, the ObservationReporter [2] is
> defined. Resource providers report changes through this interface. The
> payload of such an event is an interface which allows for lazy retrieval
> of the information.
> We can also use this mechanism for compatibility and an implementation
> of the observation reporter might sent all events via the event admin.
> [1]
> https://svn.apache.org/repos/asf/sling/whiteboard/cziegeler/api-v3/src/main/java/org/apache/sling/api/resource/observation/
> [2]
> https://svn.apache.org/repos/asf/sling/whiteboard/cziegeler



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

[jira] [Commented] (SLING-4750) New Resource Provider API

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-4750:


Ok, I have changed the javadoc about ResourceAccessSecurity in revision 1682001.

And ok about keeping revert as we are already using it.

> New Resource Provider API
> -
>
> Key: SLING-4750
> URL: https://issues.apache.org/jira/browse/SLING-4750
> Project: Sling
>  Issue Type: Improvement
>  Components: API, JCR, ResourceResolver
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: API 2.10.0, Resource Resolver 1.2.6
>
>
> Mail thread from the mailing list:
> http://mail-archives.apache.org/mod_mbox/sling-dev/201505.mbox/%3C555983ED.1080800%40apache.org%3E
> Starting mail:
> The resource provider API has grown a lot over time and when we started
> with it we didn't really think about potential extensions of the api.
> Today, each time we add a new feature, we come up with a new marker
> interface. There is also the distinction between a resource provider
> (singleton/stateless) and the factory (creating stateful providers).
> Although the api is not intended to be used by the average resource api
> user (it's an extension), we put it in the same package. And there are
> more minor things.
> Therefore I think it's time to start a new API that is more future proof
> and solves the known problems. I've created a draft prototype at [1].
> During the performance analysis by Joel he found out that getParent
> calls to a resource a pretty expensive as in the end these are string
> based. Therefore, e.g. the JCR implementation can't simply call
> getParent on a node and wrap it in a resource. Therefore I think we
> should add a getParent(Resource) method to the resource resolver and
> have a better way to handle this in a resource provider.
> Instead of having a resource provider and a resource provider factory,
> we define a single ResourceProvider which is a singleton. If this
> provider needs authentication and/or needs to keep state per user, the
> PROPERTY_AUTHENTICATE needs to be set to true and in this case the
> authenticate method is called. This one returns a data object which is
> passed in to each and every method. If auth is not required, the method
> is not called and null is passed in as the data object.
> For authentication, providers do not support login administrative
> anymore, just users and service users.
> A provider is mounted at a single root - no more support for mounting it
> at different path at the same time; and a provider always owns the root.
> So if a provider does not return a resource for a given path, no other
> provider is asked. This allows for improved implementations and resource
> resolving. If we decided that we need this for compatibility we can
> solve it differently.
> Instead of using marker interface, we define the ResourceProvider as an
> abstract class. This allows us to add new methods without breaking
> existing providers.
> Each method gets a ResolveContext, containing the resource resolver,
> the previously mentioned state data object and other things, e.g. the
> parameter support recently added to the resource resolving. In the
> future we can pass in additional data without breaking the interface.
> Apart from that the resource provider is similar to the aggregation of
> the already existing marker interfaces. There are two exceptions,
> observation and query which I'll handle in different emails.
> [1]
> https://svn.apache.org/repos/asf/sling/whiteboard/cziegeler/api-v3/src/main/java/org/apache/sling/api/resource/provider/



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

Re: [VOTE] Release Apache Sling Background Servlets Engine 1.0.0

[Daniel Klco]

+1

On Wed, May 27, 2015 at 6:33 AM, Bertrand Delacretaz  wrote:

> Hi,
>
> This is the (long overdue) first release of this module.
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1253/
>
> 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 1253 /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.
>
> Here's my +1.
>
> -Bertrand
>

[jira] [Commented] (SLING-4751) New Observation Support

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-4751:
-

For the reporting we can call the event admin through the reporter 
implementation. So providers just need to report it through the new api

I've changed the CHANGES property as suggested

I think the serviceuser property is currently better described, because the 
resolver will either have the privileges of the user who changed the content 
(if the info is available) or the privileges of the service user

> New Observation Support
> ---
>
> Key: SLING-4751
> URL: https://issues.apache.org/jira/browse/SLING-4751
> Project: Sling
>  Issue Type: Improvement
>  Components: API, JCR, ResourceResolver
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: API 2.10.0, Resource Resolver 1.2.6
>
>
> Mail thread:
> http://mail-archives.apache.org/mod_mbox/sling-dev/201505.mbox/%3C555983F2.20402%40apache.org%3E
> Starting mail
> Right now, resources changes are propagated through event admin - which
> at the time sounded like a good idea. Over time, this has shown to be a
> bottle neck.
> Basically there are at least three problems:
> - the sender of the resource events does not know whether there is a
> receiver, therefore events for each and every change need to be sent
> - event objects are immutable and therefore all relevant data needs to
> be calculated upfront, even if it's not used. For example a resource
> event contains the resource type which needs to be fetched from the
> repository, even if no one is interested in it.
> - receivers of the events can't easily act on behalf of the user who
> initiated the change.
> I created a new listener api at [1] which defines a ResourceListener
> interface and some ways how to specify the events one is interested in.
> The user aware resource listener allows to act on behalf of the user (if
> that information is available).
> On the other side, a new service, the ObservationReporter [2] is
> defined. Resource providers report changes through this interface. The
> payload of such an event is an interface which allows for lazy retrieval
> of the information.
> We can also use this mechanism for compatibility and an implementation
> of the observation reporter might sent all events via the event admin.
> [1]
> https://svn.apache.org/repos/asf/sling/whiteboard/cziegeler/api-v3/src/main/java/org/apache/sling/api/resource/observation/
> [2]
> https://svn.apache.org/repos/asf/sling/whiteboard/cziegeler



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

[jira] [Commented] (SLING-4750) New Resource Provider API

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-4750:
-

Yes, we can easily provide a bridge for the existing api. And users of the 
resource api are not affected

provider.useResourceAccessSecurity: the javadoc is taken from the existing 
ResourceProvider Feel free to change that to any text you want.
ResolveContext.getResolveParameters() is the support currently done through 
ParameteriableResourceProder

We already use revert() in the existing api, and I don't want to use a new term 
just in one place

> New Resource Provider API
> -
>
> Key: SLING-4750
> URL: https://issues.apache.org/jira/browse/SLING-4750
> Project: Sling
>  Issue Type: Improvement
>  Components: API, JCR, ResourceResolver
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: API 2.10.0, Resource Resolver 1.2.6
>
>
> Mail thread from the mailing list:
> http://mail-archives.apache.org/mod_mbox/sling-dev/201505.mbox/%3C555983ED.1080800%40apache.org%3E
> Starting mail:
> The resource provider API has grown a lot over time and when we started
> with it we didn't really think about potential extensions of the api.
> Today, each time we add a new feature, we come up with a new marker
> interface. There is also the distinction between a resource provider
> (singleton/stateless) and the factory (creating stateful providers).
> Although the api is not intended to be used by the average resource api
> user (it's an extension), we put it in the same package. And there are
> more minor things.
> Therefore I think it's time to start a new API that is more future proof
> and solves the known problems. I've created a draft prototype at [1].
> During the performance analysis by Joel he found out that getParent
> calls to a resource a pretty expensive as in the end these are string
> based. Therefore, e.g. the JCR implementation can't simply call
> getParent on a node and wrap it in a resource. Therefore I think we
> should add a getParent(Resource) method to the resource resolver and
> have a better way to handle this in a resource provider.
> Instead of having a resource provider and a resource provider factory,
> we define a single ResourceProvider which is a singleton. If this
> provider needs authentication and/or needs to keep state per user, the
> PROPERTY_AUTHENTICATE needs to be set to true and in this case the
> authenticate method is called. This one returns a data object which is
> passed in to each and every method. If auth is not required, the method
> is not called and null is passed in as the data object.
> For authentication, providers do not support login administrative
> anymore, just users and service users.
> A provider is mounted at a single root - no more support for mounting it
> at different path at the same time; and a provider always owns the root.
> So if a provider does not return a resource for a given path, no other
> provider is asked. This allows for improved implementations and resource
> resolving. If we decided that we need this for compatibility we can
> solve it differently.
> Instead of using marker interface, we define the ResourceProvider as an
> abstract class. This allows us to add new methods without breaking
> existing providers.
> Each method gets a ResolveContext, containing the resource resolver,
> the previously mentioned state data object and other things, e.g. the
> parameter support recently added to the resource resolving. In the
> future we can pass in additional data without breaking the interface.
> Apart from that the resource provider is similar to the aggregation of
> the already existing marker interfaces. There are two exceptions,
> observation and query which I'll handle in different emails.
> [1]
> https://svn.apache.org/repos/asf/sling/whiteboard/cziegeler/api-v3/src/main/java/org/apache/sling/api/resource/provider/



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

[jira] [Created] (SLING-4756) Service registration does not set the mandatory objectClass property

[Robert Munteanu (JIRA)]

Robert Munteanu created SLING-4756:
--

 Summary: Service registration does not set the mandatory 
objectClass property
 Key: SLING-4756
 URL: https://issues.apache.org/jira/browse/SLING-4756
 Project: Sling
  Issue Type: Bug
  Components: Testing
Affects Versions: Testing OSGi Mock 1.3.0
Reporter: Robert Munteanu
Assignee: Robert Munteanu
 Fix For: Testing OSGi Mock 1.3.2


When registering a service the mandatory {{objectClass}} property must be set 
for the {{ServiceReference}}'s properties.



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

Re: [RT] New resource query API

[Carsten Ziegeler]

Am 27.05.15 um 10:35 schrieb Bertrand Delacretaz:
> Hi,
> 
> On Mon, May 18, 2015 at 8:17 AM, Carsten Ziegeler  
> wrote:
>> The current resource query api has several problems:
>> - it's using the JCR spec to define a query..
> 
> Why is that a problem?
> Creating a good query API is hard work, so I'd be much more in favor
> of reusing an existing query API than inventing our own.
> 
> AFAIK Oak parses queries to the internal JCR query object model, so
> translating that to a subset that random ResourceProviders can
> implement should be possible.

The goal of this api is to do what I call technical queries, so queries
we do in our code. Its not necessarily be used for user facing queries.
Instead of using a subset of an api that doesn't look too appealing to
me I would rather stay within the resource api.

> 
>> ...Obviously this is a reduced set compared to the full fledged jcr search
>> api, however it should be suitable for the majority of use cases...
> 
> IMO it's impossible to validate such a query API in the abstract,
> without having examples of how queries look, based on a set of
> realistic use cases.

We have queries in Sling, we have already people contributing within
this thread, so I guess this works out fine.
> 
> I'm happy to collaborate on creating these examples (which can simply
> be unit tests for a relevant ResourceProvider) but before that I'd
> like to discuss what the alternatives are, before we invent YAQA (*).
> 
Make a proposal and we can discuss it

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

[jira] [Updated] (SLING-4640) Possibility of duplicate leaders w/discovery.impl on eventually consistent repo

[Stefan Egli (JIRA)]

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

Stefan Egli updated SLING-4640:
---
Fix Version/s: Discovery Impl 1.1.4

> Possibility of duplicate leaders w/discovery.impl on eventually consistent 
> repo
> ---
>
> Key: SLING-4640
> URL: https://issues.apache.org/jira/browse/SLING-4640
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Discovery Impl 1.1.0
>Reporter: Stefan Egli
> Fix For: Discovery Impl 1.1.4
>
>
> Note: This is a fork of SLING-3432 based on a 
> [comment|https://issues.apache.org/jira/browse/SLING-3432?focusedCommentId=14495936&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14495936].
>  So here is that comment again:
> Note that [the 
> above|https://issues.apache.org/jira/browse/SLING-3432?focusedCommentId=14492494&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14492494]
>  does not solve the problem where the underlying repository is eventually 
> consistent and the heartbeat configured is too low to catch all possible 
> delays (that such an eventually consistent repository might produce under 
> load). Consider the following:
> # a cluster consisting of 3 nodes: A, B and C, A is the leader
> # writes from B and C are fast - and can be read by all 3 nodes fast
> # writes from A though are slow (ie A behaves asymmetric: slow writes but 
> fast reads)
> # at some point writes from A are slower than the configured heartbeat 
> timeout: at this point B and C find out about this and vote on a new 
> clusterView consisting only of B and C and (let's say) B becomes leader.
> #* meanwhile at A however: A is still happy: it sees the heartbeats of B and 
> C in time and would not start a new voting.
> # at some later point (with a *certain read delay*) A sees that B and C have 
> declared a new {{/establishedViews}} - at this point it would (according to 
> the new rule above) immediately send a TOPOLOGY_CHANGING and things would be 
> 'ok' again. 
> #* *but* until it does send this event - *between 4. and 5. - we have two 
> leaders: A and B*! -> thus could see issues reported here in SLING-3432 still 
> during that small timeframe (which is basically the amount of time it takes 
> for the new established view declared by B and C to be read by A).
> #* at a later time, when eg the delays in the repository have come down, A 
> would rejoin the cluster - but would have to *not become leader* again, as 
> the leader is B and must stay stable.
> This IMHO highlights the problem that using an eventually consistent 
> repository (that has no max guaranteed delay) is *not* 
> pseudo-network-partition/duplicate-leader free under load.
> Note that what is described here is not fixed by SLING-4627.



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

[jira] [Updated] (SLING-4755) DiscoveryService isn't shutdown aware

[Stefan Egli (JIRA)]

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

Stefan Egli updated SLING-4755:
---
Fix Version/s: Discovery Impl 1.1.4

> DiscoveryService isn't shutdown aware
> -
>
> Key: SLING-4755
> URL: https://issues.apache.org/jira/browse/SLING-4755
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Discovery Impl 1.0.10
> Environment: AEM 6 SP2
>Reporter: Ilyas Türkben
> Fix For: Discovery Impl 1.1.4
>
>
> DiscoveryServiceImpl seems to perform write operations and require repository 
> reference during a shutdown and it blocks the shutdown for a unpredictable 
> time(here, almost 26 minutes).
> *Error log*
> {code:java}
> 26.05.2015 16:54:19.249 *INFO* [Thread-60] org.apache.sling.discovery.impl 
> Service [org.apache.sling.discovery.impl.DiscoveryServiceImpl,4131] 
> ServiceEvent UNREGISTERING
> 26.05.2015 16:55:20.756 *INFO* [pool-6-thread-1] com.adobe.granite.repository 
> Service [5185] ServiceEvent REGISTERED
> 26.05.2015 17:21:40.298 *INFO* [FelixStartLevel] com.adobe.granite.repository 
> Service [5185] ServiceEvent UNREGISTERING
> {code}
> *Thread dump for Thread-60"*
> {code:java}
> Thread-60" daemon prio=10 tid=0x7f773c5b8000 nid=0x26e1 runnable 
> [0x7f783b0ea000]
>java.lang.Thread.State: RUNNABLE
>   at java.net.SocketOutputStream.socketWrite0(Native Method)
>   at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:113)
>   at java.net.SocketOutputStream.write(SocketOutputStream.java:159)
>   at org.bson.io.PoolOutputBuffer.pipe(PoolOutputBuffer.java:153)
>   at com.mongodb.OutMessage.pipe(OutMessage.java:236)
>   at com.mongodb.DBPort$1.execute(DBPort.java:140)
>   at com.mongodb.DBPort$1.execute(DBPort.java:135)
>   at com.mongodb.DBPort.doOperation(DBPort.java:164)
>   - locked <0x00050a8eee30> (a com.mongodb.DBPort)
>   at com.mongodb.DBPort.call(DBPort.java:135)
>   at com.mongodb.DBTCPConnector.innerCall(DBTCPConnector.java:292)
>   at com.mongodb.DBTCPConnector.call(DBTCPConnector.java:271)
>   at com.mongodb.DBCollectionImpl.find(DBCollectionImpl.java:84)
>   at com.mongodb.DBCollectionImpl.find(DBCollectionImpl.java:66)
>   at com.mongodb.DBCursor._check(DBCursor.java:458)
>   at com.mongodb.DBCursor._hasNext(DBCursor.java:546)
>   at com.mongodb.DBCursor.hasNext(DBCursor.java:571)
>   at 
> org.apache.jackrabbit.oak.plugins.document.mongo.MongoDocumentStore.query(MongoDocumentStore.java:500)
>   at 
> org.apache.jackrabbit.oak.plugins.document.mongo.MongoDocumentStore.query(MongoDocumentStore.java:437)
>   at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.readChildDocs(DocumentNodeStore.java:906)
>   at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.readChildren(DocumentNodeStore.java:843)
>   at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore$4.call(DocumentNodeStore.java:799)
>   at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore$4.call(DocumentNodeStore.java:796)
>   at 
> com.google.common.cache.LocalCache$LocalManualCache$1.load(LocalCache.java:4724)
>   at 
> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3522)
>   at 
> com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2315)
>   at 
> com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2278)
>   - locked <0x000768234398> (a 
> com.google.common.cache.LocalCache$StrongAccessEntry)
>   at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2193)
>   at com.google.common.cache.LocalCache.get(LocalCache.java:3932)
>   at 
> com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4721)
>   at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.getChildren(DocumentNodeStore.java:796)
>   at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeState.getChildNodeCount(DocumentNodeState.java:183)
>   at 
> org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.getChildNodeCount(ModifiedNodeState.java:198)
>   at 
> org.apache.jackrabbit.oak.plugins.memory.MutableNodeState.getChildNodeCount(MutableNodeState.java:265)
>   at 
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.getChildNodeCount(MemoryNodeBuilder.java:293)
>   at 
> org.apache.jackrabbit.oak.plugins.index.property.strategy.ContentMirrorStoreStrategy.prune(ContentMirrorStoreStrategy.java:464)
>   at 
> org.apache.jackrabbit.oak.plugins.index.property.strategy.ContentMirrorStoreStrategy.remove(ContentMirrorStoreStrategy.java:110)
>   at 
> org.apache.jackrabbit.oak.plugins.index.property.strategy.ContentMirrorStoreStrategy.update(C

[jira] [Updated] (SLING-4755) DiscoveryService isn't shutdown aware

[Stefan Egli (JIRA)]

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

Stefan Egli updated SLING-4755:
---
Component/s: (was: Engine)
 Extensions

> DiscoveryService isn't shutdown aware
> -
>
> Key: SLING-4755
> URL: https://issues.apache.org/jira/browse/SLING-4755
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Discovery Impl 1.0.10
> Environment: AEM 6 SP2
>Reporter: Ilyas Türkben
>
> DiscoveryServiceImpl seems to perform write operations and require repository 
> reference during a shutdown and it blocks the shutdown for a unpredictable 
> time(here, almost 26 minutes).
> *Error log*
> {code:java}
> 26.05.2015 16:54:19.249 *INFO* [Thread-60] org.apache.sling.discovery.impl 
> Service [org.apache.sling.discovery.impl.DiscoveryServiceImpl,4131] 
> ServiceEvent UNREGISTERING
> 26.05.2015 16:55:20.756 *INFO* [pool-6-thread-1] com.adobe.granite.repository 
> Service [5185] ServiceEvent REGISTERED
> 26.05.2015 17:21:40.298 *INFO* [FelixStartLevel] com.adobe.granite.repository 
> Service [5185] ServiceEvent UNREGISTERING
> {code}
> *Thread dump for Thread-60"*
> {code:java}
> Thread-60" daemon prio=10 tid=0x7f773c5b8000 nid=0x26e1 runnable 
> [0x7f783b0ea000]
>java.lang.Thread.State: RUNNABLE
>   at java.net.SocketOutputStream.socketWrite0(Native Method)
>   at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:113)
>   at java.net.SocketOutputStream.write(SocketOutputStream.java:159)
>   at org.bson.io.PoolOutputBuffer.pipe(PoolOutputBuffer.java:153)
>   at com.mongodb.OutMessage.pipe(OutMessage.java:236)
>   at com.mongodb.DBPort$1.execute(DBPort.java:140)
>   at com.mongodb.DBPort$1.execute(DBPort.java:135)
>   at com.mongodb.DBPort.doOperation(DBPort.java:164)
>   - locked <0x00050a8eee30> (a com.mongodb.DBPort)
>   at com.mongodb.DBPort.call(DBPort.java:135)
>   at com.mongodb.DBTCPConnector.innerCall(DBTCPConnector.java:292)
>   at com.mongodb.DBTCPConnector.call(DBTCPConnector.java:271)
>   at com.mongodb.DBCollectionImpl.find(DBCollectionImpl.java:84)
>   at com.mongodb.DBCollectionImpl.find(DBCollectionImpl.java:66)
>   at com.mongodb.DBCursor._check(DBCursor.java:458)
>   at com.mongodb.DBCursor._hasNext(DBCursor.java:546)
>   at com.mongodb.DBCursor.hasNext(DBCursor.java:571)
>   at 
> org.apache.jackrabbit.oak.plugins.document.mongo.MongoDocumentStore.query(MongoDocumentStore.java:500)
>   at 
> org.apache.jackrabbit.oak.plugins.document.mongo.MongoDocumentStore.query(MongoDocumentStore.java:437)
>   at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.readChildDocs(DocumentNodeStore.java:906)
>   at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.readChildren(DocumentNodeStore.java:843)
>   at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore$4.call(DocumentNodeStore.java:799)
>   at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore$4.call(DocumentNodeStore.java:796)
>   at 
> com.google.common.cache.LocalCache$LocalManualCache$1.load(LocalCache.java:4724)
>   at 
> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3522)
>   at 
> com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2315)
>   at 
> com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2278)
>   - locked <0x000768234398> (a 
> com.google.common.cache.LocalCache$StrongAccessEntry)
>   at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2193)
>   at com.google.common.cache.LocalCache.get(LocalCache.java:3932)
>   at 
> com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4721)
>   at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.getChildren(DocumentNodeStore.java:796)
>   at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeState.getChildNodeCount(DocumentNodeState.java:183)
>   at 
> org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.getChildNodeCount(ModifiedNodeState.java:198)
>   at 
> org.apache.jackrabbit.oak.plugins.memory.MutableNodeState.getChildNodeCount(MutableNodeState.java:265)
>   at 
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.getChildNodeCount(MemoryNodeBuilder.java:293)
>   at 
> org.apache.jackrabbit.oak.plugins.index.property.strategy.ContentMirrorStoreStrategy.prune(ContentMirrorStoreStrategy.java:464)
>   at 
> org.apache.jackrabbit.oak.plugins.index.property.strategy.ContentMirrorStoreStrategy.remove(ContentMirrorStoreStrategy.java:110)
>   at 
> org.apache.jackrabbit.oak.plugins.index.property.strategy.ContentMirrorStoreStrategy.update(ContentMirrorStoreStrate

Jenkins build is back to stable : sling-trunk-1.7 #1855

[Apache Jenkins Server]

See 

[jira] [Commented] (SLING-4605) Add support for an Oak resource resolver type mock

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-4605:


Added a sling-mock-oak module in https://svn.apache.org/r1681992 . Leaving the 
task open for any needed refinements

> Add support for an Oak resource resolver type mock
> --
>
> Key: SLING-4605
> URL: https://issues.apache.org/jira/browse/SLING-4605
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Testing Sling Mock Oak 0.1.0
>
>
> As we have Oak support in the launchpad now and there are some internal 
> differences between Oak and Jackrabbit it would be good to be able to test 
> against an Oak repository instance.



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

[jira] [Comment Edited] (SLING-4605) Add support for an Oak resource resolver type mock

[Robert Munteanu (JIRA)]

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

Robert Munteanu edited comment on SLING-4605 at 5/27/15 11:44 AM:
--

Added a sling-mock-oak module in https://svn.apache.org/r1681992 . Leaving the 
task open for any needed refinements. 

Note that the backing Oak instance uses a {{MemoryNodeStore}} . I see no need 
(for now) to make the NodeStore configurable or use something more heavyweight 
like a {{SegmentNodeStore}}.


was (Author: rombert):
Added a sling-mock-oak module in https://svn.apache.org/r1681992 . Leaving the 
task open for any needed refinements

> Add support for an Oak resource resolver type mock
> --
>
> Key: SLING-4605
> URL: https://issues.apache.org/jira/browse/SLING-4605
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Testing Sling Mock Oak 0.1.0
>
>
> As we have Oak support in the launchpad now and there are some internal 
> differences between Oak and Jackrabbit it would be good to be able to test 
> against an Oak repository instance.



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

[jira] [Updated] (SLING-4605) Add support for an Oak resource resolver type mock

[Robert Munteanu (JIRA)]

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

Robert Munteanu updated SLING-4605:
---
Affects Version/s: (was: Testing Sling Mock Jackrabbit 0.1.2)
Fix Version/s: (was: Testing Sling Mock Jackrabbit 0.1.4)
   Testing Sling Mock Oak 0.1.0

> Add support for an Oak resource resolver type mock
> --
>
> Key: SLING-4605
> URL: https://issues.apache.org/jira/browse/SLING-4605
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Testing Sling Mock Oak 0.1.0
>
>
> As we have Oak support in the launchpad now and there are some internal 
> differences between Oak and Jackrabbit it would be good to be able to test 
> against an Oak repository instance.



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

[jira] [Assigned] (SLING-4605) Add support for an Oak resource resolver type mock

[Robert Munteanu (JIRA)]

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

Robert Munteanu reassigned SLING-4605:
--

Assignee: Robert Munteanu

> Add support for an Oak resource resolver type mock
> --
>
> Key: SLING-4605
> URL: https://issues.apache.org/jira/browse/SLING-4605
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: Testing Sling Mock Jackrabbit 0.1.2
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Testing Sling Mock Jackrabbit 0.1.4
>
>
> As we have Oak support in the launchpad now and there are some internal 
> differences between Oak and Jackrabbit it would be good to be able to test 
> against an Oak repository instance.



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

Jenkins build is still unstable: sling-contrib-1.7 #122

[Apache Jenkins Server]

See 

Jenkins build is back to stable : sling-trunk-1.8 #1146

[Apache Jenkins Server]

See 

Jenkins build is still unstable: sling-trunk-1.7 #1854

[Apache Jenkins Server]

See 

[VOTE] Release Apache Sling Background Servlets Engine 1.0.0

[Bertrand Delacretaz]

Hi,

This is the (long overdue) first release of this module.

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

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

Here's my +1.

-Bertrand

Jenkins build is still unstable: sling-trunk-1.8 #1145

[Apache Jenkins Server]

See 

Jenkins build is still unstable: sling-contrib-1.7 #121

[Apache Jenkins Server]

See 

[jira] [Updated] (SLING-4755) DiscoveryService isn't shutdown aware

[JIRA]

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

Ilyas Türkben updated SLING-4755:
-
Description: 
DiscoveryServiceImpl seems to perform write operations and require repository 
reference during a shutdown and it blocks the shutdown for a unpredictable 
time(here, almost 26 minutes).

*Error log*
{code:java}
26.05.2015 16:54:19.249 *INFO* [Thread-60] org.apache.sling.discovery.impl 
Service [org.apache.sling.discovery.impl.DiscoveryServiceImpl,4131] 
ServiceEvent UNREGISTERING
26.05.2015 16:55:20.756 *INFO* [pool-6-thread-1] com.adobe.granite.repository 
Service [5185] ServiceEvent REGISTERED
26.05.2015 17:21:40.298 *INFO* [FelixStartLevel] com.adobe.granite.repository 
Service [5185] ServiceEvent UNREGISTERING
{code}


*Thread dump for Thread-60"*
{code:java}
Thread-60" daemon prio=10 tid=0x7f773c5b8000 nid=0x26e1 runnable 
[0x7f783b0ea000]
   java.lang.Thread.State: RUNNABLE
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:113)
at java.net.SocketOutputStream.write(SocketOutputStream.java:159)
at org.bson.io.PoolOutputBuffer.pipe(PoolOutputBuffer.java:153)
at com.mongodb.OutMessage.pipe(OutMessage.java:236)
at com.mongodb.DBPort$1.execute(DBPort.java:140)
at com.mongodb.DBPort$1.execute(DBPort.java:135)
at com.mongodb.DBPort.doOperation(DBPort.java:164)
- locked <0x00050a8eee30> (a com.mongodb.DBPort)
at com.mongodb.DBPort.call(DBPort.java:135)
at com.mongodb.DBTCPConnector.innerCall(DBTCPConnector.java:292)
at com.mongodb.DBTCPConnector.call(DBTCPConnector.java:271)
at com.mongodb.DBCollectionImpl.find(DBCollectionImpl.java:84)
at com.mongodb.DBCollectionImpl.find(DBCollectionImpl.java:66)
at com.mongodb.DBCursor._check(DBCursor.java:458)
at com.mongodb.DBCursor._hasNext(DBCursor.java:546)
at com.mongodb.DBCursor.hasNext(DBCursor.java:571)
at 
org.apache.jackrabbit.oak.plugins.document.mongo.MongoDocumentStore.query(MongoDocumentStore.java:500)
at 
org.apache.jackrabbit.oak.plugins.document.mongo.MongoDocumentStore.query(MongoDocumentStore.java:437)
at 
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.readChildDocs(DocumentNodeStore.java:906)
at 
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.readChildren(DocumentNodeStore.java:843)
at 
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore$4.call(DocumentNodeStore.java:799)
at 
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore$4.call(DocumentNodeStore.java:796)
at 
com.google.common.cache.LocalCache$LocalManualCache$1.load(LocalCache.java:4724)
at 
com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3522)
at 
com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2315)
at 
com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2278)
- locked <0x000768234398> (a 
com.google.common.cache.LocalCache$StrongAccessEntry)
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2193)
at com.google.common.cache.LocalCache.get(LocalCache.java:3932)
at 
com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4721)
at 
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.getChildren(DocumentNodeStore.java:796)
at 
org.apache.jackrabbit.oak.plugins.document.DocumentNodeState.getChildNodeCount(DocumentNodeState.java:183)
at 
org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.getChildNodeCount(ModifiedNodeState.java:198)
at 
org.apache.jackrabbit.oak.plugins.memory.MutableNodeState.getChildNodeCount(MutableNodeState.java:265)
at 
org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.getChildNodeCount(MemoryNodeBuilder.java:293)
at 
org.apache.jackrabbit.oak.plugins.index.property.strategy.ContentMirrorStoreStrategy.prune(ContentMirrorStoreStrategy.java:464)
at 
org.apache.jackrabbit.oak.plugins.index.property.strategy.ContentMirrorStoreStrategy.remove(ContentMirrorStoreStrategy.java:110)
at 
org.apache.jackrabbit.oak.plugins.index.property.strategy.ContentMirrorStoreStrategy.update(ContentMirrorStoreStrategy.java:84)
at 
org.apache.jackrabbit.oak.plugins.index.property.PropertyIndexEditor.leave(PropertyIndexEditor.java:261)
at 
org.apache.jackrabbit.oak.spi.commit.CompositeEditor.leave(CompositeEditor.java:74)
at 
org.apache.jackrabbit.oak.spi.commit.VisibleEditor.leave(VisibleEditor.java:63)
at 
org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeDeleted(EditorDiff.java:176)
at 
org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.compareAgainstBaseState(

[jira] [Commented] (SLING-4753) Commit the Resource Resolver before passing it to Tenant Customizers for setting up their own customizations

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> Commit the Resource Resolver before passing it to Tenant Customizers for 
> setting up their own customizations
> 
>
> Key: SLING-4753
> URL: https://issues.apache.org/jira/browse/SLING-4753
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Tenant 1.0.4
>Reporter: Agraj Mangal
>
> We should commit the Resource Resolver after creating the Tenant Resource and 
> before passing it on to the Tenant Customizers. 
> One possible issue is that one of the Tenant Customizers calls some APIs like 
> PageManager##createPage that does a session.refresh() and rollbacks all the 
> un-committed changes on the resolver so far. That could also include the 
> tenant resource itself. 
> Ideally the TenantCustomizers should not call commit on the resolver and let 
> TenantProvider commit the changes, but it would be a good protection against 
> all such cases where we could prevent the tenant resource from getting 
> modified if the TenantCustomizer failed and tried to refresh the session.
> We are experiencing this issue in 
> https://jira.corp.adobe.com/browse/MAC-25410 



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

[GitHub] sling pull request: SLING-4753 - Commit the Resource Resolver befo...

[asfgit]

Github user asfgit closed the pull request at:

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


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

[jira] [Created] (SLING-4755) DiscoveryService isn't shutdown aware

[JIRA]

Ilyas Türkben created SLING-4755:


 Summary: DiscoveryService isn't shutdown aware
 Key: SLING-4755
 URL: https://issues.apache.org/jira/browse/SLING-4755
 Project: Sling
  Issue Type: Bug
  Components: Engine
Affects Versions: Discovery Impl 1.0.10
 Environment: AEM 6 SP2
Reporter: Ilyas Türkben


DiscoveryServiceImpl seems to perform write operation and require repository 
reference during a shutdown and it blocks the shutdown for a unpredictable 
time(here, almost 26 minutes).

*Error log*
{code:java}
26.05.2015 16:54:19.249 *INFO* [Thread-60] org.apache.sling.discovery.impl 
Service [org.apache.sling.discovery.impl.DiscoveryServiceImpl,4131] 
ServiceEvent UNREGISTERING
26.05.2015 16:55:20.756 *INFO* [pool-6-thread-1] com.adobe.granite.repository 
Service [5185] ServiceEvent REGISTERED
26.05.2015 17:21:40.298 *INFO* [FelixStartLevel] com.adobe.granite.repository 
Service [5185] ServiceEvent UNREGISTERING
{code}


*Thread dump for Thread-60"*
{code:java}
Thread-60" daemon prio=10 tid=0x7f773c5b8000 nid=0x26e1 runnable 
[0x7f783b0ea000]
   java.lang.Thread.State: RUNNABLE
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:113)
at java.net.SocketOutputStream.write(SocketOutputStream.java:159)
at org.bson.io.PoolOutputBuffer.pipe(PoolOutputBuffer.java:153)
at com.mongodb.OutMessage.pipe(OutMessage.java:236)
at com.mongodb.DBPort$1.execute(DBPort.java:140)
at com.mongodb.DBPort$1.execute(DBPort.java:135)
at com.mongodb.DBPort.doOperation(DBPort.java:164)
- locked <0x00050a8eee30> (a com.mongodb.DBPort)
at com.mongodb.DBPort.call(DBPort.java:135)
at com.mongodb.DBTCPConnector.innerCall(DBTCPConnector.java:292)
at com.mongodb.DBTCPConnector.call(DBTCPConnector.java:271)
at com.mongodb.DBCollectionImpl.find(DBCollectionImpl.java:84)
at com.mongodb.DBCollectionImpl.find(DBCollectionImpl.java:66)
at com.mongodb.DBCursor._check(DBCursor.java:458)
at com.mongodb.DBCursor._hasNext(DBCursor.java:546)
at com.mongodb.DBCursor.hasNext(DBCursor.java:571)
at 
org.apache.jackrabbit.oak.plugins.document.mongo.MongoDocumentStore.query(MongoDocumentStore.java:500)
at 
org.apache.jackrabbit.oak.plugins.document.mongo.MongoDocumentStore.query(MongoDocumentStore.java:437)
at 
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.readChildDocs(DocumentNodeStore.java:906)
at 
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.readChildren(DocumentNodeStore.java:843)
at 
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore$4.call(DocumentNodeStore.java:799)
at 
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore$4.call(DocumentNodeStore.java:796)
at 
com.google.common.cache.LocalCache$LocalManualCache$1.load(LocalCache.java:4724)
at 
com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3522)
at 
com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2315)
at 
com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2278)
- locked <0x000768234398> (a 
com.google.common.cache.LocalCache$StrongAccessEntry)
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2193)
at com.google.common.cache.LocalCache.get(LocalCache.java:3932)
at 
com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4721)
at 
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.getChildren(DocumentNodeStore.java:796)
at 
org.apache.jackrabbit.oak.plugins.document.DocumentNodeState.getChildNodeCount(DocumentNodeState.java:183)
at 
org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.getChildNodeCount(ModifiedNodeState.java:198)
at 
org.apache.jackrabbit.oak.plugins.memory.MutableNodeState.getChildNodeCount(MutableNodeState.java:265)
at 
org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.getChildNodeCount(MemoryNodeBuilder.java:293)
at 
org.apache.jackrabbit.oak.plugins.index.property.strategy.ContentMirrorStoreStrategy.prune(ContentMirrorStoreStrategy.java:464)
at 
org.apache.jackrabbit.oak.plugins.index.property.strategy.ContentMirrorStoreStrategy.remove(ContentMirrorStoreStrategy.java:110)
at 
org.apache.jackrabbit.oak.plugins.index.property.strategy.ContentMirrorStoreStrategy.update(ContentMirrorStoreStrategy.java:84)
at 
org.apache.jackrabbit.oak.plugins.index.property.PropertyIndexEditor.leave(PropertyIndexEditor.java:261)
at 
org.apache.jackrabbit.oak.spi.commit.CompositeEditor.leave(CompositeEditor.java:74)
at 
org.apache.jackrabbit.oak.spi.commit.VisibleEditor.leav

[jira] [Updated] (SLING-4754) Sightly: Improve error message if referenced resource type is not available

[JIRA]

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

Jörg Hoh updated SLING-4754:

Attachment: sightly-improve-template-not-found-exception.patch

> Sightly: Improve error message if referenced resource type is not available
> ---
>
> Key: SLING-4754
> URL: https://issues.apache.org/jira/browse/SLING-4754
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Affects Versions: Scripting Sightly Engine 1.0.2
>Reporter: Jörg Hoh
>Priority: Minor
> Attachments: sightly-improve-template-not-found-exception.patch
>
>
> When content references a sightly component, which is not available, it 
> throws a SightlyException with the message "Unable to generate Java class for 
> template /apps/.../foobar.html".
> Which is correct, but in case the referenced component is just not there, the 
> error handling could be improved to something like "Unable to resolve 
> template %s in the repository".  
> It took me a look in the sourcecode to find the actual root cause, when I got 
> a stacktrace of the generic SightlyException in UnitLoader.java, line 151.



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

[jira] [Created] (SLING-4754) Improve error message if referenced resource type is not available

[JIRA]

Jörg Hoh created SLING-4754:
---

 Summary: Improve error message if referenced resource type is not 
available
 Key: SLING-4754
 URL: https://issues.apache.org/jira/browse/SLING-4754
 Project: Sling
  Issue Type: Improvement
  Components: Scripting
Affects Versions: Scripting Sightly Engine 1.0.2
Reporter: Jörg Hoh
Priority: Minor


When content references a sightly component, which is not available, it throws 
a SightlyException with the message "Unable to generate Java class for template 
/apps/.../foobar.html".

Which is correct, but in case the referenced component is just not there, the 
error handling could be improved to something like "Unable to resolve template 
%s in the repository".  

It took me a look in the sourcecode to find the actual root cause, when I got a 
stacktrace of the generic SightlyException in UnitLoader.java, line 151.





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

[jira] [Updated] (SLING-4754) Sightly: Improve error message if referenced resource type is not available

[JIRA]

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

Jörg Hoh updated SLING-4754:

Summary: Sightly: Improve error message if referenced resource type is not 
available  (was: Improve error message if referenced resource type is not 
available)

> Sightly: Improve error message if referenced resource type is not available
> ---
>
> Key: SLING-4754
> URL: https://issues.apache.org/jira/browse/SLING-4754
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Affects Versions: Scripting Sightly Engine 1.0.2
>Reporter: Jörg Hoh
>Priority: Minor
>
> When content references a sightly component, which is not available, it 
> throws a SightlyException with the message "Unable to generate Java class for 
> template /apps/.../foobar.html".
> Which is correct, but in case the referenced component is just not there, the 
> error handling could be improved to something like "Unable to resolve 
> template %s in the repository".  
> It took me a look in the sourcecode to find the actual root cause, when I got 
> a stacktrace of the generic SightlyException in UnitLoader.java, line 151.



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

Re: [RT] New resource query API

[Bertrand Delacretaz]

Hi,

On Mon, May 18, 2015 at 8:17 AM, Carsten Ziegeler  wrote:
> The current resource query api has several problems:
> - it's using the JCR spec to define a query..

Why is that a problem?
Creating a good query API is hard work, so I'd be much more in favor
of reusing an existing query API than inventing our own.

AFAIK Oak parses queries to the internal JCR query object model, so
translating that to a subset that random ResourceProviders can
implement should be possible.

> - it's not clear which queries are supported by providers..

Agreed, that's a difficult one to solve, especially with a query that
spans multiple providers.

> ...Obviously this is a reduced set compared to the full fledged jcr search
> api, however it should be suitable for the majority of use cases...

IMO it's impossible to validate such a query API in the abstract,
without having examples of how queries look, based on a set of
realistic use cases.

I'm happy to collaborate on creating these examples (which can simply
be unit tests for a relevant ResourceProvider) but before that I'd
like to discuss what the alternatives are, before we invent YAQA (*).

-Bertrand

(*) Yet Another Query API ;-)

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

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-4752:


I'm quite skeptical about creating Yet Another Query API, will discuss on our 
dev list for now.

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



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

[jira] [Commented] (SLING-4750) New Resource Provider API

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-4750:


Thanks for this! Note that in the meantime this moved to 
https://svn.apache.org/repos/asf/sling/whiteboard/cziegeler/api-v3/src/main/java/org/apache/sling/spi/resource/provider/

Comments/questions about ResourceProvider and ResolveContext (QueryProvider is 
discussed in SLING-4752):

How to you see the transition from the existing APIs? Provide a bridge from the 
current APIs to the new ones?

In the comment of the provider.useResourceAccessSecurity, instead of 
"ResourceProvider implements are encouraged..." can we instead say 
"ResourceAccessSecurity should only be used when the underlying storage does 
not provide access control" ?

What's the use case for ResolveContext.getResolveParameters() ?

"rollback" would sound more natural to me than "revert" for that method's name.





> New Resource Provider API
> -
>
> Key: SLING-4750
> URL: https://issues.apache.org/jira/browse/SLING-4750
> Project: Sling
>  Issue Type: Improvement
>  Components: API, JCR, ResourceResolver
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: API 2.10.0, Resource Resolver 1.2.6
>
>
> Mail thread from the mailing list:
> http://mail-archives.apache.org/mod_mbox/sling-dev/201505.mbox/%3C555983ED.1080800%40apache.org%3E
> Starting mail:
> The resource provider API has grown a lot over time and when we started
> with it we didn't really think about potential extensions of the api.
> Today, each time we add a new feature, we come up with a new marker
> interface. There is also the distinction between a resource provider
> (singleton/stateless) and the factory (creating stateful providers).
> Although the api is not intended to be used by the average resource api
> user (it's an extension), we put it in the same package. And there are
> more minor things.
> Therefore I think it's time to start a new API that is more future proof
> and solves the known problems. I've created a draft prototype at [1].
> During the performance analysis by Joel he found out that getParent
> calls to a resource a pretty expensive as in the end these are string
> based. Therefore, e.g. the JCR implementation can't simply call
> getParent on a node and wrap it in a resource. Therefore I think we
> should add a getParent(Resource) method to the resource resolver and
> have a better way to handle this in a resource provider.
> Instead of having a resource provider and a resource provider factory,
> we define a single ResourceProvider which is a singleton. If this
> provider needs authentication and/or needs to keep state per user, the
> PROPERTY_AUTHENTICATE needs to be set to true and in this case the
> authenticate method is called. This one returns a data object which is
> passed in to each and every method. If auth is not required, the method
> is not called and null is passed in as the data object.
> For authentication, providers do not support login administrative
> anymore, just users and service users.
> A provider is mounted at a single root - no more support for mounting it
> at different path at the same time; and a provider always owns the root.
> So if a provider does not return a resource for a given path, no other
> provider is asked. This allows for improved implementations and resource
> resolving. If we decided that we need this for compatibility we can
> solve it differently.
> Instead of using marker interface, we define the ResourceProvider as an
> abstract class. This allows us to add new methods without breaking
> existing providers.
> Each method gets a ResolveContext, containing the resource resolver,
> the previously mentioned state data object and other things, e.g. the
> parameter support recently added to the resource resolving. In the
> future we can pass in additional data without breaking the interface.
> Apart from that the resource provider is similar to the aggregation of
> the already existing marker interfaces. There are two exceptions,
> observation and query which I'll handle in different emails.
> [1]
> https://svn.apache.org/repos/asf/sling/whiteboard/cziegeler/api-v3/src/main/java/org/apache/sling/api/resource/provider/



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

[jira] [Commented] (SLING-4751) New Observation Support

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-4751:


Looks good to me, thanks! 

How do you see the transition from the current mechanism based on OSGi events? 
I suppose resource providers will need to report to both, or a bridge needs to 
be implemented?

A few minor suggestions:

In ResourceListener and UserAwareResourceListener the changes property name 
should be "resource.change.types"

In UserAwareResourceListener the resource.serviceuser comment can be improved 
as follows:

"The name of the service user to use for the ResourceResolver passed to 
onChange, if that resolver is not bound to the user who initiated the changes".

> New Observation Support
> ---
>
> Key: SLING-4751
> URL: https://issues.apache.org/jira/browse/SLING-4751
> Project: Sling
>  Issue Type: Improvement
>  Components: API, JCR, ResourceResolver
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: API 2.10.0, Resource Resolver 1.2.6
>
>
> Mail thread:
> http://mail-archives.apache.org/mod_mbox/sling-dev/201505.mbox/%3C555983F2.20402%40apache.org%3E
> Starting mail
> Right now, resources changes are propagated through event admin - which
> at the time sounded like a good idea. Over time, this has shown to be a
> bottle neck.
> Basically there are at least three problems:
> - the sender of the resource events does not know whether there is a
> receiver, therefore events for each and every change need to be sent
> - event objects are immutable and therefore all relevant data needs to
> be calculated upfront, even if it's not used. For example a resource
> event contains the resource type which needs to be fetched from the
> repository, even if no one is interested in it.
> - receivers of the events can't easily act on behalf of the user who
> initiated the change.
> I created a new listener api at [1] which defines a ResourceListener
> interface and some ways how to specify the events one is interested in.
> The user aware resource listener allows to act on behalf of the user (if
> that information is available).
> On the other side, a new service, the ObservationReporter [2] is
> defined. Resource providers report changes through this interface. The
> payload of such an event is an interface which allows for lazy retrieval
> of the information.
> We can also use this mechanism for compatibility and an implementation
> of the observation reporter might sent all events via the event admin.
> [1]
> https://svn.apache.org/repos/asf/sling/whiteboard/cziegeler/api-v3/src/main/java/org/apache/sling/api/resource/observation/
> [2]
> https://svn.apache.org/repos/asf/sling/whiteboard/cziegeler



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

[jira] [Commented] (SLING-4753) Commit the Resource Resolver before passing it to Tenant Customizers for setting up their own customizations

[ASF GitHub Bot (JIRA)]

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

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

GitHub user agrajm opened a pull request:

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

SLING-4753 - Commit the Resource Resolver before passing it to 
TenantCustomizers for setting up their own customizations

Persisting the Tenant Resource by calling commit before setting up the 
Tenant Customizers and passing the resolver to them, which potentially have the 
ability to undo all the un-committed changes on the Resolver ( including the 
Tenant Resource itself ) leading to all kind of weird errors like 
InvalidItemStateException , StaleItemStateException etc.

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

$ git pull https://github.com/agrajm/sling trunk

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

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

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

This closes #92


commit 2979825d40644e0c51c0e10c47b3139d181a7c19
Author: Agraj Mangal 
Date:   2015-05-27T07:42:04Z

SLING-4753 - Commit the Resource Resolver before passing it to Tenant 
Customizers for setting up their own customizations

commit 375f29b74a3ca5b3ba718a9899b902863660cc7a
Author: Agraj Mangal 
Date:   2015-05-27T07:53:23Z

Revert "SLING-4753 - Commit the Resource Resolver before passing it to 
Tenant Customizers for setting up their own customizations"

This reverts commit 2979825d40644e0c51c0e10c47b3139d181a7c19.

commit fe537e9fed86fb022110f72982938ce8f7c7de75
Author: Agraj Mangal 
Date:   2015-05-27T07:54:23Z

SLING-4753 - Commit the Resource Resolver before passing it to Tenant 
Customizers for setting up their own customizations




> Commit the Resource Resolver before passing it to Tenant Customizers for 
> setting up their own customizations
> 
>
> Key: SLING-4753
> URL: https://issues.apache.org/jira/browse/SLING-4753
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Tenant 1.0.4
>Reporter: Agraj Mangal
>
> We should commit the Resource Resolver after creating the Tenant Resource and 
> before passing it on to the Tenant Customizers. 
> One possible issue is that one of the Tenant Customizers calls some APIs like 
> PageManager##createPage that does a session.refresh() and rollbacks all the 
> un-committed changes on the resolver so far. That could also include the 
> tenant resource itself. 
> Ideally the TenantCustomizers should not call commit on the resolver and let 
> TenantProvider commit the changes, but it would be a good protection against 
> all such cases where we could prevent the tenant resource from getting 
> modified if the TenantCustomizer failed and tried to refresh the session.
> We are experiencing this issue in 
> https://jira.corp.adobe.com/browse/MAC-25410 



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

[GitHub] sling pull request: SLING-4753 - Commit the Resource Resolver befo...

[agrajm]

GitHub user agrajm opened a pull request:

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

SLING-4753 - Commit the Resource Resolver before passing it to 
TenantCustomizers for setting up their own customizations

Persisting the Tenant Resource by calling commit before setting up the 
Tenant Customizers and passing the resolver to them, which potentially have the 
ability to undo all the un-committed changes on the Resolver ( including the 
Tenant Resource itself ) leading to all kind of weird errors like 
InvalidItemStateException , StaleItemStateException etc.

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

$ git pull https://github.com/agrajm/sling trunk

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

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

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

This closes #92


commit 2979825d40644e0c51c0e10c47b3139d181a7c19
Author: Agraj Mangal 
Date:   2015-05-27T07:42:04Z

SLING-4753 - Commit the Resource Resolver before passing it to Tenant 
Customizers for setting up their own customizations

commit 375f29b74a3ca5b3ba718a9899b902863660cc7a
Author: Agraj Mangal 
Date:   2015-05-27T07:53:23Z

Revert "SLING-4753 - Commit the Resource Resolver before passing it to 
Tenant Customizers for setting up their own customizations"

This reverts commit 2979825d40644e0c51c0e10c47b3139d181a7c19.

commit fe537e9fed86fb022110f72982938ce8f7c7de75
Author: Agraj Mangal 
Date:   2015-05-27T07:54:23Z

SLING-4753 - Commit the Resource Resolver before passing it to Tenant 
Customizers for setting up their own customizations




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

Re: [RESULT] [VOTE] Release Apache Sling Commons OSGi 2.3.0

[Robert Munteanu]

On Tue, 2015-05-26 at 21:19 +0200, Stefan Seifert wrote:
> 
> @any PMC member: please copy this release to the Sling dist 
> directory.

Done in r9144.

Robert

Re: [RESULT] [VOTE] Release Apache Sling Testing OSGi Mock 1.3.0, JCR Mock 1.1.6, ResourceResolver Mock 1.1.6, Sling Mock 1.3.0, Logging Mock 1.0.0

[Robert Munteanu]

On Tue, 2015-05-26 at 21:19 +0200, Stefan Seifert wrote:
> 
> @any PMC member: please copy this release to the Sling dist 
> directory.

Done in r9143.

Robert

[jira] [Created] (SLING-4753) Commit the Resource Resolver before passing it to Tenant Customizers for setting up their own customizations

[Agraj Mangal (JIRA)]

Agraj Mangal created SLING-4753:
---

 Summary: Commit the Resource Resolver before passing it to Tenant 
Customizers for setting up their own customizations
 Key: SLING-4753
 URL: https://issues.apache.org/jira/browse/SLING-4753
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: Tenant 1.0.4
Reporter: Agraj Mangal


We should commit the Resource Resolver after creating the Tenant Resource and 
before passing it on to the Tenant Customizers. 

One possible issue is that one of the Tenant Customizers calls some APIs like 
PageManager##createPage that does a session.refresh() and rollbacks all the 
un-committed changes on the resolver so far. That could also include the tenant 
resource itself. 

Ideally the TenantCustomizers should not call commit on the resolver and let 
TenantProvider commit the changes, but it would be a good protection against 
all such cases where we could prevent the tenant resource from getting modified 
if the TenantCustomizer failed and tried to refresh the session.

We are experiencing this issue in https://jira.corp.adobe.com/browse/MAC-25410 



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