[jira] [Updated] (SLING-5991) [SCD] Evaluate avoiding to buffer the whole packages before streaming

[Timothee Maret (JIRA)]

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

Timothee Maret updated SLING-5991:
--
Attachment: SLING-5991.patch

Attaching patch that uses Piped streams when exporting packages.

> [SCD] Evaluate avoiding to buffer the whole packages before streaming
> -
>
> Key: SLING-5991
> URL: https://issues.apache.org/jira/browse/SLING-5991
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Affects Versions: Content Distribution 0.2.0
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: Content Distribution 0.2.0
>
> Attachments: SLING-5991.patch
>
>
> As described in SLING-5990, It seems streaming only starts when the whole 
> binary is completely buffered (in memory and/or file). The buffering time 
> implies a latency which which could be avoided by streaming directly.



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

[jira] [Commented] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-6187:
---

bq. IIUC, the new validating patch requires a configuration of the sling post 
servlet bundle (for the ModificationValidatingPostProcessor) to set a pattern 
(like @Encrypted) that must not be present after all other processors have run 
through?

Correct.

bq. If we have a mechanism where the presence of a post processor that 
announces its @Suffix in the service properties itself is enough (see above), 
that additional configuration wouldn't be necessary. But that would mean all 
post processors handling custom suffixes need to be changed, otherwise their 
requests would fail.

I'm not sure I understand this. We can't prohibit the @ symbol in the 
modification set in general since this is a legal JCR character, as I wrote in 
https://issues.apache.org/jira/browse/SLING-6187?focusedCommentId=15606583=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15606583.
 And if we rely on the service properties, that doesn't really help if the 
service is not present (the original issue).



> Provide a way for a POST request to assert a set of required 
> SlingPostProcessors
> 
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
> Attachments: SLING-6187-profile.diff, SLING-6187-profile.diff, 
> SLING-6187-validating.diff, SLING-6187.patch
>
>
> I would like to add support for a new "special" request parameter understood 
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter 
> may contain a comma-delimited list of names (see below) which *must* be 
> available *at the time the request is processed* in order for the request to 
> be handled. Whether or not those processors _do_ anything or whether the 
> request succeeds or not is a separate question; this is just a preflight 
> check if you will.
> If any of the required SlingPostProcessors are not available, the request 
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service 
> registration property {{postProcessor.name}} and default to the simple name 
> of the SlingPostProcessor's implementation class if that property is not 
> defined.



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

[jira] [Commented] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek commented on SLING-6187:
--

IIUC, the new validating patch requires a configuration of the sling post 
servlet bundle (for the ModificationValidatingPostProcessor) to set a pattern 
(like @Encrypted) that must not be present after all other processors have run 
through?

That seems feasible, albeit it does require the @Encrypted post processor 
module provider to ensure this configuration on the sling post servlet is also 
present. If they put the configuration in the same deployment package as the 
post processor, there is still a (very small?) chance that these are 
temporarily gone _together_, leading to the original issue.

If we have a mechanism where the presence of a post processor that announces 
its @Suffix in the service properties itself is enough (see above), that 
additional configuration wouldn't be necessary. But that would mean all post 
processors handling custom suffixes need to be changed, otherwise their 
requests would fail. How many custom @Suffix based post processors do we know 
about?

I would like to hear others opinion on that as well.

> Provide a way for a POST request to assert a set of required 
> SlingPostProcessors
> 
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
> Attachments: SLING-6187-profile.diff, SLING-6187-profile.diff, 
> SLING-6187-validating.diff, SLING-6187.patch
>
>
> I would like to add support for a new "special" request parameter understood 
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter 
> may contain a comma-delimited list of names (see below) which *must* be 
> available *at the time the request is processed* in order for the request to 
> be handled. Whether or not those processors _do_ anything or whether the 
> request succeeds or not is a separate question; this is just a preflight 
> check if you will.
> If any of the required SlingPostProcessors are not available, the request 
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service 
> registration property {{postProcessor.name}} and default to the simple name 
> of the SlingPostProcessor's implementation class if that property is not 
> defined.



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

[jira] [Commented] (SLING-6352) do not use unstable Jackrabbit releases

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6352:
-

[~julian.resc...@gmx.de] Well it might be that there is an artifact that 
exports those packages, but looking at Sling's launchpad or AEM's quickstart, 
this bundle is not deployed there. So the repository implementation seems to 
embedd this stuff as well

> do not use unstable Jackrabbit releases
> ---
>
> Key: SLING-6352
> URL: https://issues.apache.org/jira/browse/SLING-6352
> Project: Sling
>  Issue Type: Task
>  Components: JCR
>Reporter: Julian Reschke
>
> bundles/jcr/webdav currently references jackrabbit 2.13.1. This is a test 
> release from an unstable branch.
> Please either change this to the latest stable release (2.12.*), or wait for 
> 2.14 to be released (track using JCR-4071).



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

[jira] [Commented] (SLING-6352) do not use unstable Jackrabbit releases

[Julian Reschke (JIRA)]

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

Julian Reschke commented on SLING-6352:
---

Let's do this step-by-step :-).

{noformat}
jackrabbit-jcr-server/target/jackrabbit-jcr-server-2.13.7-SNAPSHOT.jar
 Bundle-Version: 2.13.7.SNAPSHOT
  
org.apache.jackrabbit.server;version="1.0";uses:="javax.jcr,javax.servlet,javax.servlet.http"
{noformat}

So org.apache.jackrabbit.server *is* exported, but 
org.apache.jackrabbit.server.jcr,
org.apache.jackrabbit.server.remoting.davex and
org.apache.jackrabbit.server.util are not.

Would it be possible to stop embedding org.apache.jackrabbit.server right now, 
or is that pointless as long as sub-packages are not exported? [~anchela]: any 
idea why those are not supported?

> do not use unstable Jackrabbit releases
> ---
>
> Key: SLING-6352
> URL: https://issues.apache.org/jira/browse/SLING-6352
> Project: Sling
>  Issue Type: Task
>  Components: JCR
>Reporter: Julian Reschke
>
> bundles/jcr/webdav currently references jackrabbit 2.13.1. This is a test 
> release from an unstable branch.
> Please either change this to the latest stable release (2.12.*), or wait for 
> 2.14 to be released (track using JCR-4071).



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

[jira] [Commented] (SLING-6352) do not use unstable Jackrabbit releases

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6352:
-

[~fmeschbe] afaik, the jackrabbit bundles are not exporting these packages

> do not use unstable Jackrabbit releases
> ---
>
> Key: SLING-6352
> URL: https://issues.apache.org/jira/browse/SLING-6352
> Project: Sling
>  Issue Type: Task
>  Components: JCR
>Reporter: Julian Reschke
>
> bundles/jcr/webdav currently references jackrabbit 2.13.1. This is a test 
> release from an unstable branch.
> Please either change this to the latest stable release (2.12.*), or wait for 
> 2.14 to be released (track using JCR-4071).



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

[jira] [Commented] (SLING-6352) do not use unstable Jackrabbit releases

[Julian Reschke (JIRA)]

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

Julian Reschke commented on SLING-6352:
---

cc [~anchela]

If this is just for historic reasons (we never got to it), then we should 
improve things so it's not necessary anymore in Sling (because that clearly 
causes additional work every time we change something, in particular when 
related to security fixes).

If there is a good reason for *not* doing this, then at least document it 
here...

> do not use unstable Jackrabbit releases
> ---
>
> Key: SLING-6352
> URL: https://issues.apache.org/jira/browse/SLING-6352
> Project: Sling
>  Issue Type: Task
>  Components: JCR
>Reporter: Julian Reschke
>
> bundles/jcr/webdav currently references jackrabbit 2.13.1. This is a test 
> release from an unstable branch.
> Please either change this to the latest stable release (2.12.*), or wait for 
> 2.14 to be released (track using JCR-4071).



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

Re: [VOTE] Release Apache Sling JCR Base 3.0.0

[Julian Sedding]

The issue I observed is not a release blocker IMHO. I filed the
improvement SLING-6401[0], which also provides a description of the
issue.

Please continue voting! Thank you and sorry for the confusion.

Regards
Julian

[0] https://issues.apache.org/jira/browse/SLING-6401

On Thu, Dec 15, 2016 at 3:47 PM, Julian Sedding  wrote:
> Please refrain from any votes for the time being. I suspect there
> might be an issue with this release, currently verifying.
>
> Regards
> Julian
>
> On Thu, Dec 15, 2016 at 3:26 PM, Julian Sedding  wrote:
>> Hi all
>>
>> We solved 2 issues in the JCR Base 3.0.0 release:
>> https://issues.apache.org/jira/browse/SLING/fixforversion/12338709
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachesling-1602/
>>
>> 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 1602 /tmp/sling-staging
>>
>> Please vote to approve this release:
>>
>>   [ ] +1 Approve the release
>>   [ ]  0 Don't care
>>   [ ] -1 Don't release, because ...
>>
>> This majority vote is open for at least 72 hours.
>>
>> Regards
>> Julian

[jira] [Created] (SLING-6401) AbstractSlingRepositoryManager should guard against NPE due to async initialization

[Julian Sedding (JIRA)]

Julian Sedding created SLING-6401:
-

 Summary: AbstractSlingRepositoryManager should guard against NPE 
due to async initialization
 Key: SLING-6401
 URL: https://issues.apache.org/jira/browse/SLING-6401
 Project: Sling
  Issue Type: Improvement
  Components: JCR
Affects Versions: JCR Base 3.0.0
Reporter: Julian Sedding
Assignee: Julian Sedding
Priority: Minor


With the asynchronous initialization of the repository it is possible that 
subclasses or test cases call {{AbstractSlingRepositoryManager#create}} before 
the repository is fully initialized. This can lead to NPEs. We should guard 
against this problem.

Note, however, that the {{SlingRepository}} service is only registered *after* 
the repository is fully initialized. Therefore this issue, which was only 
observed in a 3rd party test-case, does not impact normal usage in an OSGi 
container.



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

Re: [VOTE] Release Apache Sling JCR Base 3.0.0

[Carsten Ziegeler]

+1

 

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

[jira] [Commented] (SLING-6352) do not use unstable Jackrabbit releases

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6352:
--

To be honest, I don't exactly remember why we chose embedding. It may be that 
when we began with these bundles, the Jackrabbit libraries have not been proper 
bundles. There may have been other/more reasons.

If now the Jackrabbit libraries are proper bundles with usable package exports, 
it might be worth a try to not embed any more.

> do not use unstable Jackrabbit releases
> ---
>
> Key: SLING-6352
> URL: https://issues.apache.org/jira/browse/SLING-6352
> Project: Sling
>  Issue Type: Task
>  Components: JCR
>Reporter: Julian Reschke
>
> bundles/jcr/webdav currently references jackrabbit 2.13.1. This is a test 
> release from an unstable branch.
> Please either change this to the latest stable release (2.12.*), or wait for 
> 2.14 to be released (track using JCR-4071).



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

Re: [VOTE] Release Apache Sling JCR Base 3.0.0

[Julian Sedding]

Please refrain from any votes for the time being. I suspect there
might be an issue with this release, currently verifying.

Regards
Julian

On Thu, Dec 15, 2016 at 3:26 PM, Julian Sedding  wrote:
> Hi all
>
> We solved 2 issues in the JCR Base 3.0.0 release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12338709
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1602/
>
> 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 1602 /tmp/sling-staging
>
> Please vote to approve this release:
>
>   [ ] +1 Approve the release
>   [ ]  0 Don't care
>   [ ] -1 Don't release, because ...
>
> This majority vote is open for at least 72 hours.
>
> Regards
> Julian

Re: [VOTE] Release Apache Sling Scripting HTL Compiler 1.0.4, Apache Sling Scripting HTL Java Compiler 1.0.6, Apache Sling Scripting HTL Engine 1.0.28, Apache Sling Scripting HTL Models Use Provider 1

[Carsten Ziegeler]

+1

 

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

Re: [VOTE] Release Apache Sling Scripting HTL Compiler 1.0.4, Apache Sling Scripting HTL Java Compiler 1.0.6, Apache Sling Scripting HTL Engine 1.0.28, Apache Sling Scripting HTL Models Use Provider 1

[Radu Cotescu]

Correction - 6 issues: SLING-6166, SLING-6186, SLING-6224, SLING-6230,
SLING-6390, SLING-6399.

Also, here's my +1.

Thanks,
Radu

On Thu, 15 Dec 2016 at 15:40 Radu Cotescu  wrote:

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

[VOTE] Release Apache Sling Scripting HTL Compiler 1.0.4, Apache Sling Scripting HTL Java Compiler 1.0.6, Apache Sling Scripting HTL Engine 1.0.28, Apache Sling Scripting HTL Models Use Provider 1.0.6

[Radu Cotescu]

Hi,

We solved 7 issues in these releases:
https://issues.apache.org/jira/browse/SLING/fixforversion/12338593
https://issues.apache.org/jira/browse/SLING/fixforversion/12338594
https://issues.apache.org/jira/browse/SLING/fixforversion/12338592
https://issues.apache.org/jira/browse/SLING/fixforversion/12338595
https://issues.apache.org/jira/browse/SLING/fixforversion/12338543
https://issues.apache.org/jira/browse/SLING/fixforversion/12338646

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

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

Please vote to approve this release:

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

This majority vote is open for at least 72 hours.

Cheers,
Radu

[jira] [Commented] (SLING-6352) do not use unstable Jackrabbit releases

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6352:
-

JCR Davex is embedding the following packages from jackrabbit:
org.apache.jackrabbit.server,
org.apache.jackrabbit.server.jcr,
org.apache.jackrabbit.server.remoting.davex,
org.apache.jackrabbit.server.util,
org.apache.jackrabbit.webdav.jcr.*
These are not exported by any jackrabbit bundle
Similar Sling's JCR Webdav embedds
   org.apache.jackrabbit.server,
   org.apache.jackrabbit.webdav.simple,
   org.apache.jackrabbit.webdav.jcr

I assume these are not exported as they are not intended for the public

The question is whether we can do anything about this? It would be great if we 
could avoid embedding.

[~fmeschbe], [~julian.resc...@gmx.de] Any ideas/opinions?



> do not use unstable Jackrabbit releases
> ---
>
> Key: SLING-6352
> URL: https://issues.apache.org/jira/browse/SLING-6352
> Project: Sling
>  Issue Type: Task
>  Components: JCR
>Reporter: Julian Reschke
>
> bundles/jcr/webdav currently references jackrabbit 2.13.1. This is a test 
> release from an unstable branch.
> Please either change this to the latest stable release (2.12.*), or wait for 
> 2.14 to be released (track using JCR-4071).



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

[jira] [Created] (SLING-6400) Server-Side Tests: Timeout-handling broken

[Stefan Seifert (JIRA)]

Stefan Seifert created SLING-6400:
-

 Summary: Server-Side Tests: Timeout-handling broken
 Key: SLING-6400
 URL: https://issues.apache.org/jira/browse/SLING-6400
 Project: Sling
  Issue Type: Bug
  Components: Testing
Affects Versions: JUnit Core 1.0.20
Reporter: Stefan Seifert
Assignee: Stefan Seifert
 Fix For: JUnit Core 1.0.22


the timeout handling for getting a service which was refactored in SLING-6335 
is currently broken: it adds to the configured timeout the current time in 
milliseconds (since 1970) which leads to a very long wait time.



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

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

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-5229:
-

[~asanso] jcr.base has a Loader class which allows to set namespace prefixes 
and define node types through bundle content. I think we don't need to switch 
that one a service user. WDYT?

> Remove getAdministrativeResourceResolver() and loginAdministrative() usage 
> from JCR components
> --
>
> Key: SLING-5229
> URL: https://issues.apache.org/jira/browse/SLING-5229
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Reporter: Antonio Sanso
> Fix For: JCR Resource 2.9.2, JCR ContentLoader 2.2.0, JCR Davex 
> 1.3.6, JCR Base 3.0.0
>
>
> * {{org.apache.sling.jcr.compiler}} : 1
> * {{org.apache.sling.installer.provider.jcr}}: 4
> * {{org.apache.sling.jcr.base}}: 2
> * {{org.apache.sling.jcr.contentloader}}: 2
> * {{org.apache.sling.jcr.davex}}: 1
> * {{org.apache.sling.jcr.resource}}: 5
> total of 15 occurrences



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

[jira] [Resolved] (SLING-6400) Server-Side Tests: Timeout-handling broken

[Stefan Seifert (JIRA)]

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

Stefan Seifert resolved SLING-6400.
---
Resolution: Fixed

Completed: At revision: 1774478  


> Server-Side Tests: Timeout-handling broken
> --
>
> Key: SLING-6400
> URL: https://issues.apache.org/jira/browse/SLING-6400
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: JUnit Core 1.0.20
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
> Fix For: JUnit Core 1.0.22
>
>
> the timeout handling for getting a service which was refactored in SLING-6335 
> is currently broken: it adds to the configured timeout the current time in 
> milliseconds (since 1970) which leads to a very long wait time.



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

[VOTE] Release Apache Sling JCR Base 3.0.0

[Julian Sedding]

Hi all

We solved 2 issues in the JCR Base 3.0.0 release:
https://issues.apache.org/jira/browse/SLING/fixforversion/12338709

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

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

Please vote to approve this release:

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

This majority vote is open for at least 72 hours.

Regards
Julian

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

[Julian Sedding (JIRA)]

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

Julian Sedding updated SLING-5229:
--
Fix Version/s: (was: JCR Base 3.0.0)
   JCR Base 3.0.2

> Remove getAdministrativeResourceResolver() and loginAdministrative() usage 
> from JCR components
> --
>
> Key: SLING-5229
> URL: https://issues.apache.org/jira/browse/SLING-5229
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Reporter: Antonio Sanso
> Fix For: JCR Resource 2.9.2, JCR ContentLoader 2.2.0, JCR Davex 
> 1.3.6, JCR Base 3.0.2
>
>
> * {{org.apache.sling.jcr.compiler}} : 1
> * {{org.apache.sling.installer.provider.jcr}}: 4
> * {{org.apache.sling.jcr.base}}: 2
> * {{org.apache.sling.jcr.contentloader}}: 2
> * {{org.apache.sling.jcr.davex}}: 1
> * {{org.apache.sling.jcr.resource}}: 5
> total of 15 occurrences



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

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

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-5229:
-

jcr.contentloader:
[~asanso] The content loader can add/remove/update any content including users, 
acls etc, add nodetypes. So I thing we should leave it like this. WDYT?

> Remove getAdministrativeResourceResolver() and loginAdministrative() usage 
> from JCR components
> --
>
> Key: SLING-5229
> URL: https://issues.apache.org/jira/browse/SLING-5229
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Reporter: Antonio Sanso
> Fix For: JCR Resource 2.9.2, JCR ContentLoader 2.2.0, JCR Davex 
> 1.3.6, JCR Base 3.0.0
>
>
> * {{org.apache.sling.jcr.compiler}} : 1
> * {{org.apache.sling.installer.provider.jcr}}: 4
> * {{org.apache.sling.jcr.base}}: 2
> * {{org.apache.sling.jcr.contentloader}}: 2
> * {{org.apache.sling.jcr.davex}}: 1
> * {{org.apache.sling.jcr.resource}}: 5
> total of 15 occurrences



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

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

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-5229:
-

jcr.davex:
[~asanso] SlingDavExServlet uses the admin session to impersonate to a user. 
Not sure if we can/should change this?

> Remove getAdministrativeResourceResolver() and loginAdministrative() usage 
> from JCR components
> --
>
> Key: SLING-5229
> URL: https://issues.apache.org/jira/browse/SLING-5229
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Reporter: Antonio Sanso
> Fix For: JCR Resource 2.9.2, JCR ContentLoader 2.2.0, JCR Davex 
> 1.3.6, JCR Base 3.0.0
>
>
> * {{org.apache.sling.jcr.compiler}} : 1
> * {{org.apache.sling.installer.provider.jcr}}: 4
> * {{org.apache.sling.jcr.base}}: 2
> * {{org.apache.sling.jcr.contentloader}}: 2
> * {{org.apache.sling.jcr.davex}}: 1
> * {{org.apache.sling.jcr.resource}}: 5
> total of 15 occurrences



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

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

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-5229:
-

jcr.resource:
JcrListenerBaseConfig : needs a user with read access to the whole repository
JcrSystemUserValidator: uses the admin session to check the user. [~asanso] Do 
we really need to change that?

> Remove getAdministrativeResourceResolver() and loginAdministrative() usage 
> from JCR components
> --
>
> Key: SLING-5229
> URL: https://issues.apache.org/jira/browse/SLING-5229
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Reporter: Antonio Sanso
> Fix For: JCR Resource 2.9.2, JCR ContentLoader 2.2.0, JCR Davex 
> 1.3.6, JCR Base 3.0.0
>
>
> * {{org.apache.sling.jcr.compiler}} : 1
> * {{org.apache.sling.installer.provider.jcr}}: 4
> * {{org.apache.sling.jcr.base}}: 2
> * {{org.apache.sling.jcr.contentloader}}: 2
> * {{org.apache.sling.jcr.davex}}: 1
> * {{org.apache.sling.jcr.resource}}: 5
> total of 15 occurrences



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

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

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-5229:
-

Removed jcr.compiler from the target list as we moved that bundle to the attic

> Remove getAdministrativeResourceResolver() and loginAdministrative() usage 
> from JCR components
> --
>
> Key: SLING-5229
> URL: https://issues.apache.org/jira/browse/SLING-5229
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Reporter: Antonio Sanso
> Fix For: JCR Resource 2.9.2, JCR ContentLoader 2.2.0, JCR Davex 
> 1.3.6, JCR Base 3.0.0
>
>
> * {{org.apache.sling.jcr.compiler}} : 1
> * {{org.apache.sling.installer.provider.jcr}}: 4
> * {{org.apache.sling.jcr.base}}: 2
> * {{org.apache.sling.jcr.contentloader}}: 2
> * {{org.apache.sling.jcr.davex}}: 1
> * {{org.apache.sling.jcr.resource}}: 5
> total of 15 occurrences



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

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

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-5229:

Fix Version/s: (was: JCR Compiler 2.1.2)

> Remove getAdministrativeResourceResolver() and loginAdministrative() usage 
> from JCR components
> --
>
> Key: SLING-5229
> URL: https://issues.apache.org/jira/browse/SLING-5229
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Reporter: Antonio Sanso
> Fix For: JCR Resource 2.9.2, JCR ContentLoader 2.2.0, JCR Davex 
> 1.3.6, JCR Base 3.0.0
>
>
> * {{org.apache.sling.jcr.compiler}} : 1
> * {{org.apache.sling.installer.provider.jcr}}: 4
> * {{org.apache.sling.jcr.base}}: 2
> * {{org.apache.sling.jcr.contentloader}}: 2
> * {{org.apache.sling.jcr.davex}}: 1
> * {{org.apache.sling.jcr.resource}}: 5
> total of 15 occurrences



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

[jira] [Resolved] (SLING-6357) Allow to extend LoginAdminWhitelist with multiple configurations

[Julian Sedding (JIRA)]

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

Julian Sedding resolved SLING-6357.
---
Resolution: Fixed

> Allow to extend LoginAdminWhitelist with multiple configurations
> 
>
> Key: SLING-6357
> URL: https://issues.apache.org/jira/browse/SLING-6357
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Affects Versions: JCR Base 2.4.2
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Blocker
> Fix For: JCR Base 3.0.0
>
>
> As [discussed on the mailing 
> list|http://sling.markmail.org/thread/7xfcefaufczvsdgk], it would be 
> desirable to allow multiple configurations to contribute to the 
> {{LoginAdminWhitelist}}.
> This issue is marked *blocker*, as the current implementation was not yet 
> released, thus allowing arbitrary changes without backwards compatibility 
> headaches.
> I propose to remove the {{whitelist.bundles.default}} and 
> {{whitelist.bundles.additional}} properties and replace them by "additional 
> configurations" that each allow to provide a list of whitlisted bundle 
> symbolic names.
> In the main configuration for {{LoginAdminWhitelist}} I propose to retain the 
> flag to bypass the whitelist completely.
> I am uncertain, whether we really need the whitelist regexp for testing, as 
> it is fairly simple to list a hand full of required bundles. If we keep it, I 
> suggest to make its metatype private.
> Optionally, we could consider the possibility to allow configuring a list of 
> required "additional configurations". I would leave this until we find a real 
> requirement for this, as it would complicate the implementation.



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

[jira] [Resolved] (SLING-6390) Remove metatype info for some HTL OSGi configurations

[Radu Cotescu (JIRA)]

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

Radu Cotescu resolved SLING-6390.
-
Resolution: Fixed

Fixed in [r1774436|https://svn.apache.org/r1774436].

> Remove metatype info for some HTL OSGi configurations
> -
>
> Key: SLING-6390
> URL: https://issues.apache.org/jira/browse/SLING-6390
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Scripting HTL JS Use Provider 1.0.18, Scripting HTL 
> Engine 1.0.28, Scripting HTL Models Use Provider 1.0.6
>
>
> The following components should be modified so that they don't provide any 
> configuration metatype information any more, eliminating the complexity of 
> having too many configurations in the System Console:
> {noformat}
> org.apache.sling.scripting.sightly.impl.engine.SightlyEngineConfiguration
> org.apache.sling.scripting.sightly.impl.engine.extension.use.JavaUseProvider
> org.apache.sling.scripting.sightly.impl.engine.extension.use.RenderUnitProvider
> org.apache.sling.scripting.sightly.impl.engine.extension.use.ResourceUseProvider
> org.apache.sling.scripting.sightly.impl.engine.extension.use.ScriptUseProvider
> org.apache.sling.scripting.sightly.js.impl.JsUseProvider
> org.apache.sling.scripting.sightly.models.impl.SlingModelsUseProvider
> {noformat}
> Advanced users will still have the possibility to configure the components by 
> using {{sling:OsgiConfig}} nodes, however they provide reasonable and tested 
> default values.



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

[jira] [Closed] (SLING-6337) Fix default folder name regular expression

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-6337.
--

> Fix default folder name regular expression
> --
>
> Key: SLING-6337
> URL: https://issues.apache.org/jira/browse/SLING-6337
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: JCR Installer 3.1.20
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: JCR Installer 3.1.22
>
>
> brackets got lost, regular expression has to be {{.*/(install|config)$}}



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

[jira] [Closed] (SLING-6274) Busy loop in jcr installer

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-6274.
--

> Busy loop in jcr installer
> --
>
> Key: SLING-6274
> URL: https://issues.apache.org/jira/browse/SLING-6274
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: JCR Installer 3.1.18
>Reporter: Carsten Ziegeler
>Assignee: Bertrand Delacretaz
> Fix For: JCR Installer 3.1.22
>
>
> It seems there is at least sometimes a busy loop:
> 09.11.2016 01:45:38.067 *DEBUG* [JcrInstaller.1] 
> org.apache.sling.installer.provider.jcr.impl.JcrInstaller Running watch cycle.
> 09.11.2016 01:45:38.067 *DEBUG* [JcrInstaller.1] 
> org.apache.sling.installer.provider.jcr.impl.JcrInstaller Found child nodes 
> [e693e4e4-4fab-4a71-aa5d-69170a605f1a] at path 
> /system/sling/installer/jcr/pauseInstallation. Scanning would be paused
> 09.11.2016 01:45:38.067 *DEBUG* [JcrInstaller.1] 
> org.apache.sling.installer.provider.jcr.impl.JcrInstaller Running watch cycle.
> 09.11.2016 01:45:38.067 *DEBUG* [JcrInstaller.1] 
> org.apache.sling.installer.provider.jcr.impl.JcrInstaller Found child nodes 
> [e693e4e4-4fab-4a71-aa5d-69170a605f1a] at path 
> /system/sling/installer/jcr/pauseInstallation. Scanning would be paused
> 09.11.2016 01:45:38.067 *DEBUG* [JcrInstaller.1] 
> org.apache.sling.installer.provider.jcr.impl.JcrInstaller Running watch cycle.
> 09.11.2016 01:45:38.067 *DEBUG* [JcrInstaller.1] 
> org.apache.sling.installer.provider.jcr.impl.JcrInstaller Found child nodes 
> [e693e4e4-4fab-4a71-aa5d-69170a605f1a] at path 
> /system/sling/installer/jcr/pauseInstallation. Scanning would be paused
> 09.11.2016 01:45:38.067 *DEBUG* [JcrInstaller.1] 
> org.apache.sling.installer.provider.jcr.impl.JcrInstaller Running watch cycle.
> 09.11.2016 01:45:38.067 *DEBUG* [JcrInstaller.1] 
> org.apache.sling.installer.provider.jcr.impl.JcrInstaller Found child nodes 
> [e693e4e4-4fab-4a71-aa5d-69170a605f1a] at path 
> /system/sling/installer/jcr/pauseInstallation. Scanning would be paused
> 09.11.2016 01:45:38.067 *DEBUG* [JcrInstaller.1] 
> org.apache.sling.installer.provider.jcr.impl.JcrInstaller Running watch cycle.
> 09.11.2016 01:45:38.067 *DEBUG* [JcrInstaller.1] 
> org.apache.sling.installer.provider.jcr.impl.JcrInstaller Found child nodes 
> [e693e4e4-4fab-4a71-aa5d-69170a605f1a] at path 
> /system/sling/installer/jcr/pauseInstallation. Scanning would be paused
> 09.11.2016 01:45:38.067 *DEBUG* [JcrInstaller.1] 
> org.apache.sling.installer.provider.jcr.impl.JcrInstaller Running watch cycle.
> 09.11.2016 01:45:38.067 *DEBUG* [JcrInstaller.1] 
> org.apache.sling.installer.provider.jcr.impl.JcrInstaller Found child nodes 
> [e693e4e4-4fab-4a71-aa5d-69170a605f1a] at path 
> /system/sling/installer/jcr/pauseInstallation. Scanning would be paused
> 09.11.2016 01:45:38.067 *DEBUG* [JcrInstaller.1] 
> org.apache.sling.installer.provider.jcr.impl.JcrInstaller Running watch cycle.
> 09.11.2016 01:45:38.067 *DEBUG* [JcrInstaller.1] 
> org.apache.sling.installer.provider.jcr.impl.JcrInstaller Found child nodes 
> [e693e4e4-4fab-4a71-aa5d-69170a605f1a] at path 
> /system/sling/installer/jcr/pauseInstallation. Scanning would be paused
> 09.11.2016 01:45:38.067 *DEBUG* [JcrInstaller.1] 
> org.apache.sling.installer.provider.jcr.impl.JcrInstaller Running watch cycle.
> 09.11.2016 01:45:38.067 *DEBUG* [JcrInstaller.1] 
> org.apache.sling.installer.provider.jcr.impl.JcrInstaller Found child nodes 
> [e693e4e4-4fab-4a71-aa5d-69170a605f1a] at path 
> /system/sling/installer/jcr/pauseInstallation. Scanning would be paused
> 09.11.2016 01:45:38.067 *DEBUG* [JcrInstaller.1] 
> org.apache.sling.installer.provider.jcr.impl.JcrInstaller Running watch cycle.
> 09.11.2016 01:45:38.067 *DEBUG* [JcrInstaller.1] 
> org.apache.sling.installer.provider.jcr.impl.JcrInstaller Found child nodes 
> [e693e4e4-4fab-4a71-aa5d-69170a605f1a] at path 
> /system/sling/installer/jcr/pauseInstallation. Scanning would be paused
> 09.11.2016 01:45:38.067 *DEBUG* [JcrInstaller.1] 
> org.apache.sling.installer.provider.jcr.impl.JcrInstaller Running watch cycle.



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

[jira] [Closed] (SLING-6326) JcrInstaller.counters should be accessed in a thread-safe manner

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-6326.
--

> JcrInstaller.counters should be accessed in a thread-safe manner
> 
>
> Key: SLING-6326
> URL: https://issues.apache.org/jira/browse/SLING-6326
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: JCR Installer 3.1.22
>
>
> The JcrInstaller.counter thread is a final long array. However, that does not 
> ensure that changes performed are safely published. Since they are 
> potentially accessed from multiple threads, including unit tests, this can 
> lead to random-looking, hard-to-debug issues.



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

[jira] [Closed] (SLING-5519) Extend default regexp for watched folders to include config

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5519.
--

> Extend default regexp for watched folders to include config
> ---
>
> Key: SLING-5519
> URL: https://issues.apache.org/jira/browse/SLING-5519
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: JCR Installer 3.1.22
>
>
> {{.*/install|config$}} allows keeping configuration and other artifacts in 
> distinct folders (matches pattern in AEM also)



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

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

[Robert Munteanu (JIRA)]

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

Robert Munteanu closed SLING-5228.
--

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



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

[RESULT] [VOTE] Release Apache Sling JCR Installer version 3.1.22

[Robert Munteanu]

Hi,

The vote has passed with the following result :

+1 (binding): Robert Munteanu, Stefan Seifert, Carsten Ziegeler
+1 (non binding): Julian Sedding

I will copy this release to the Sling dist directory and promote the
artifacts to the central Maven repository.

Robert

[jira] [Closed] (SLING-6355) org.apache.sling.scripting.core.impl.BindingsValuesProvidersByContextImpl should not register itself as a ServiceTrackerCustomizer service

[Radu Cotescu (JIRA)]

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

Radu Cotescu closed SLING-6355.
---

> org.apache.sling.scripting.core.impl.BindingsValuesProvidersByContextImpl 
> should not register itself as a ServiceTrackerCustomizer service
> --
>
> Key: SLING-6355
> URL: https://issues.apache.org/jira/browse/SLING-6355
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting Core 2.0.40
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Scripting Core 2.0.44
>
>
> org.apache.sling.scripting.core.impl.BindingsValuesProvidersByContextImpl is 
> currently registered as both a 
> org.apache.sling.scripting.api.BindingsValuesProvidersByContext and 
> org.osgi.util.tracker.ServiceTrackerCustomizer service. This makes it very 
> difficult to use this service from bundles which embed the 
> org.osgi.util.tracker package.



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

[jira] [Closed] (SLING-6165) Expose a service for Sling Scripting that provides request-scoped Resource Resolvers for scripting dependencies

[Radu Cotescu (JIRA)]

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

Radu Cotescu closed SLING-6165.
---

> Expose a service for Sling Scripting that provides request-scoped Resource 
> Resolvers for scripting dependencies
> ---
>
> Key: SLING-6165
> URL: https://issues.apache.org/jira/browse/SLING-6165
> Project: Sling
>  Issue Type: New Feature
>  Components: Scripting
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Scripting Core 2.0.44, Scripting API 2.1.12
>
>
> A new Sling Scripting service ({{ScriptingResourceResolverProvider}}) should 
> be implemented in order to provide access to request-based 
> {{ResourceResolvers}} for solving script dependencies.
> The following method should be available:
> {noformat}
> /**
>  * Provides a request-scoped {@link ResourceResolver} with only read access 
> to the search paths. This resolver should be used for script 
>  * resolution in the context of the same request rendering process. The 
> {@code ResourceResolver} should not be closed by consumers (calling
>  * {@link ResourceResolver#close} doesn't do anything), since this service 
> will handle the closing operation automatically. The 
>  * {@code ResourceResolver} will be shared between scripting dependencies 
> that render parts of the response for the same request.
>  */
> ResourceResolver getRequestScopedResourceResolver()
> {noformat}
> [sling-dev email 
> thread|https://lists.apache.org/thread.html/db2a78249baf2d6234a4549a5aff8b5474256add9829f86ac78d1c56@%3Cdev.sling.apache.org%3E]



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

Re: [VOTE] Release Apache Sling Slingstart Maven Plugin 1.7.0

[Julian Sedding]

[X] +1 Approve the release (non binding)

All checks are ok.

Regards
Julian

On Thu, Dec 15, 2016 at 1:01 PM, Robert Munteanu  wrote:
> On Thu, 2016-12-15 at 07:14 +0100, Carsten Ziegeler wrote:
>> This majority vote is open for at least 72 hours.
>
> +1, with the note that this needs a release of the provisioning model
> 1.8.0, which still under vote.
>
> Robert

Re: [VOTE] Release Apache Sling Scripting API 2.1.12, Apache Sling Scripting Core 2.0.44

[Julian Sedding]

[X] +1 Approve the release (non binding)

All checks are ok.

Regards
Julian


On Thu, Dec 15, 2016 at 12:59 PM, Robert Munteanu  wrote:
> Somehow I failed to see that :-)
>
> Thanks,
>
> Robert
>
> On Thu, 2016-12-15 at 11:57 +, Radu Cotescu wrote:
>> Hi Robert,
>>
>> Karl voted after I had sent the email.
>>
>> Cheers,
>> Radu
>>
>> On Thu, 15 Dec 2016 at 12:55, Robert Munteanu 
>> wrote:
>>
>> > On Wed, 2016-12-14 at 21:47 +, Radu Cotescu wrote:
>> > > Hi,
>> > >
>> > > We'd need another PMC member to check this release. Could
>> > > somebody
>> > > please
>> > > step in?
>> >
>> > Do we?
>> >
>> > I saw votes from Karl Pauls, Stefan Seifert and yourself, all PMC
>> > members according to [1]
>> >
>> > Robert
>> >
>> > [1]: https://sling.apache.org/project-information/project-team.html
>> >
>

[RESULT][VOTE] Release Apache Sling Scripting API 2.1.12, Apache Sling Scripting Core 2.0.44

[Radu Cotescu]

Hi,

The release passed with 3 +1s from Stefan Seifert, Karl Pauls and myself.

Thanks,
Radu

Re: [VOTE] Release Apache Sling Dynamic Include 3.0.0

[Julian Sedding]

[X] +1 Approve the release (non binding)

All checks are ok.

Regards
Julian


On Thu, Dec 15, 2016 at 12:56 PM, Robert Munteanu  wrote:
> On Thu, 2016-12-15 at 10:38 +0100, Bertrand Delacretaz wrote:
>> Please vote to approve this release:
>
> +1
>
> Robert

Re: [VOTE] Release Apache Sling org.apache.sling.i18n version 2.5.6

[Julian Sedding]

[X] +1 Approve the release (non binding)

All checks are ok.

Regards
Julian


On Thu, Dec 15, 2016 at 12:52 PM, Robert Munteanu  wrote:
> On Thu, 2016-12-15 at 11:11 +0100, Timothee Maret wrote:
>> Please vote to approve this release:
>
> +1
>
> Robert

Re: [VOTE] Release Apache Sling JCR Installer version 3.1.22

[Carsten Ziegeler]

+1


 

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

Re: [VOTE] Release Apache Sling JCR RepoInit module 1.2.2

[Carsten Ziegeler]

+1

 

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

Re: [VOTE] Release Apache Sling JCR RepoInit module 1.2.2

[Julian Sedding]

[X] +1 Approve the release (non binding)

All checks are ok.

Regards
Julian


On Thu, Dec 15, 2016 at 12:48 PM, Robert Munteanu  wrote:
>
> Hi,
>
> We solved 1 issue in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12338683
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1600
>
> 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 1600 /tmp/sling-staging
>
> Please vote to approve this release:
>
>   [ ] +1 Approve the release
>   [ ]  0 Don't care
>   [ ] -1 Don't release, because ...
>
> This majority vote is open for at least 72 hours.

[jira] [Updated] (SLING-6187) Provide a way for a POST request to assert a set of required SlingPostProcessors

[Justin Edelson (JIRA)]

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

Justin Edelson updated SLING-6187:
--
Attachment: SLING-6187-validating.diff

This new validating patch includes a new Post Processor which is configurable 
as a factory component to allow for multiple validation passes of the 
modification list.

> Provide a way for a POST request to assert a set of required 
> SlingPostProcessors
> 
>
> Key: SLING-6187
> URL: https://issues.apache.org/jira/browse/SLING-6187
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Servlets Post 2.3.16
>
> Attachments: SLING-6187-profile.diff, SLING-6187-profile.diff, 
> SLING-6187-validating.diff, SLING-6187.patch
>
>
> I would like to add support for a new "special" request parameter understood 
> by the Sling Post Servlet named {{:requiredPostProcessors}}. This parameter 
> may contain a comma-delimited list of names (see below) which *must* be 
> available *at the time the request is processed* in order for the request to 
> be handled. Whether or not those processors _do_ anything or whether the 
> request succeeds or not is a separate question; this is just a preflight 
> check if you will.
> If any of the required SlingPostProcessors are not available, the request 
> will fail with a 501 error.
> The name of a SlingPostProcessor will be defined by a newly defined service 
> registration property {{postProcessor.name}} and default to the simple name 
> of the SlingPostProcessor's implementation class if that property is not 
> defined.



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

Re: [VOTE] Release Apache Sling Slingstart Maven Plugin 1.7.0

[Robert Munteanu]

On Thu, 2016-12-15 at 07:14 +0100, Carsten Ziegeler wrote:
> This majority vote is open for at least 72 hours.

+1, with the note that this needs a release of the provisioning model
1.8.0, which still under vote.

Robert

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

Re: [VOTE] Release Apache Sling Scripting API 2.1.12, Apache Sling Scripting Core 2.0.44

[Robert Munteanu]

Somehow I failed to see that :-)

Thanks,

Robert

On Thu, 2016-12-15 at 11:57 +, Radu Cotescu wrote:
> Hi Robert,
> 
> Karl voted after I had sent the email.
> 
> Cheers,
> Radu
> 
> On Thu, 15 Dec 2016 at 12:55, Robert Munteanu 
> wrote:
> 
> > On Wed, 2016-12-14 at 21:47 +, Radu Cotescu wrote:
> > > Hi,
> > > 
> > > We'd need another PMC member to check this release. Could
> > > somebody
> > > please
> > > step in?
> > 
> > Do we?
> > 
> > I saw votes from Karl Pauls, Stefan Seifert and yourself, all PMC
> > members according to [1]
> > 
> > Robert
> > 
> > [1]: https://sling.apache.org/project-information/project-team.html
> > 

Re: [VOTE] Release Apache Sling JCR Installer version 3.1.22

[Robert Munteanu]

We still need one more binding vote, it's only been 17 days since the
vote started :-)

Robert

On Thu, 2016-12-08 at 13:55 +0200, Robert Munteanu wrote:
> Ahem ...
> 
> On Mon, 2016-12-05 at 18:34 +0200, Robert Munteanu wrote:
> > Ping! We still node one more binding vote.
> > 
> > Robert
> > 
> > 
> > On Mon, 2016-11-28 at 22:32 +0200, Robert Munteanu wrote:
> > > Hi,
> > > 
> > > We solved 6 issues in this release:
> > > https://issues.apache.org/jira/browse/SLING/fixforversion/1233877
> > > 8
> > > 
> > > Staging repository:
> > > https://repository.apache.org/content/repositories/orgapachesling
> > > -1
> > > 58
> > > 5
> > > 
> > > 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 1585 /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.
> > > 
> > > Robert
> > 
> > 
> 
> 

Re: [VOTE] Release Apache Sling Scripting API 2.1.12, Apache Sling Scripting Core 2.0.44

[Radu Cotescu]

Hi Robert,

Karl voted after I had sent the email.

Cheers,
Radu

On Thu, 15 Dec 2016 at 12:55, Robert Munteanu  wrote:

> On Wed, 2016-12-14 at 21:47 +, Radu Cotescu wrote:
> > Hi,
> >
> > We'd need another PMC member to check this release. Could somebody
> > please
> > step in?
>
> Do we?
>
> I saw votes from Karl Pauls, Stefan Seifert and yourself, all PMC
> members according to [1]
>
> Robert
>
> [1]: https://sling.apache.org/project-information/project-team.html
>

Re: [VOTE] Release Apache Sling Dynamic Include 3.0.0

[Robert Munteanu]

On Thu, 2016-12-15 at 10:38 +0100, Bertrand Delacretaz wrote:
> Please vote to approve this release:

+1

Robert

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

Re: [VOTE] Release Apache Sling Scripting API 2.1.12, Apache Sling Scripting Core 2.0.44

[Robert Munteanu]

On Wed, 2016-12-14 at 21:47 +, Radu Cotescu wrote:
> Hi,
> 
> We'd need another PMC member to check this release. Could somebody
> please
> step in?

Do we?

I saw votes from Karl Pauls, Stefan Seifert and yourself, all PMC
members according to [1]

Robert

[1]: https://sling.apache.org/project-information/project-team.html

Re: [VOTE] Release Apache Sling org.apache.sling.i18n version 2.5.6

[Robert Munteanu]

On Thu, 2016-12-15 at 11:11 +0100, Timothee Maret wrote:
> Please vote to approve this release:

+1

Robert

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

[VOTE] Release Apache Sling JCR RepoInit module 1.1.2

[Robert Munteanu]

Sorry, the version should be 1.1.2 , not 1.2.2

On Thu, 2016-12-15 at 11:48 +, Robert Munteanu wrote:
> Hi,
> 
> We solved 1 issue in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12338683
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-160
> 0
> 
> 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 1600 /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.

[VOTE] Release Apache Sling JCR RepoInit module 1.2.2

[Robert Munteanu]

Hi,

We solved 1 issue in this release:
https://issues.apache.org/jira/browse/SLING/fixforversion/12338683

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

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

Re: [VOTE] Release Apache Sling org.apache.sling.i18n version 2.5.6

[Carsten Ziegeler]

+1


 

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

[jira] [Commented] (SLING-6398) Repoinit should not attempt to create access control entries when no changes are needed

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-6398:


Thanks. Committed as [r1774410|https://svn.apache.org/r1774410] and will start 
a release vote later today if no integration issues pop up.

> Repoinit should not attempt to create access control entries when no changes 
> are needed
> ---
>
> Key: SLING-6398
> URL: https://issues.apache.org/jira/browse/SLING-6398
> Project: Sling
>  Issue Type: Improvement
>  Components: Repoinit
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Repoinit JCR 1.1.2
>
> Attachments: 
> 0001-SLING-6368-Repoinit-should-not-attempt-to-create-acc.patch
>
>
> I have a more complex Sling setup based on the recent Oak multiplexing 
> additions.
> The repository is split bewteen
> - /libs and /apps, read-only
> - the rest of the repository, read-write
> When the provisioning model contains ACL definitions, they are processed 
> directly without checking if they exist. In turn, Oak updates the 
> definitions, even if equivalent ones exist. This causes the repoinit part to 
> fail if it refers to ACLs for the read-only part of the repository.
> I would propose that the repoinit statements check if the ACL really needs to 
> be replaced or if it can be skipped. This also has the advantage of making it 
> symmetric with the checks for service users and paths and also should 
> slightly reduce provisioning time.
> [~bdelacretaz] - would that work for you?



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

[jira] [Resolved] (SLING-6398) Repoinit should not attempt to create access control entries when no changes are needed

[Robert Munteanu (JIRA)]

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

Robert Munteanu resolved SLING-6398.

Resolution: Fixed

> Repoinit should not attempt to create access control entries when no changes 
> are needed
> ---
>
> Key: SLING-6398
> URL: https://issues.apache.org/jira/browse/SLING-6398
> Project: Sling
>  Issue Type: Improvement
>  Components: Repoinit
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Repoinit JCR 1.1.2
>
> Attachments: 
> 0001-SLING-6368-Repoinit-should-not-attempt-to-create-acc.patch
>
>
> I have a more complex Sling setup based on the recent Oak multiplexing 
> additions.
> The repository is split bewteen
> - /libs and /apps, read-only
> - the rest of the repository, read-write
> When the provisioning model contains ACL definitions, they are processed 
> directly without checking if they exist. In turn, Oak updates the 
> definitions, even if equivalent ones exist. This causes the repoinit part to 
> fail if it refers to ACLs for the read-only part of the repository.
> I would propose that the repoinit statements check if the ACL really needs to 
> be replaced or if it can be skipped. This also has the advantage of making it 
> symmetric with the checks for service users and paths and also should 
> slightly reduce provisioning time.
> [~bdelacretaz] - would that work for you?



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

[VOTE] Release Apache Sling org.apache.sling.i18n version 2.5.6

[Timothee Maret]

Hi,

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

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

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

Please vote to approve this release:

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

This majority vote is open for at least 72 hours.

[jira] [Commented] (SLING-6398) Repoinit should not attempt to create access control entries when no changes are needed

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-6398:


I haven't looked at your code in detail but I see that it has tests and the log 
entry looks good to me, thanks!

> Repoinit should not attempt to create access control entries when no changes 
> are needed
> ---
>
> Key: SLING-6398
> URL: https://issues.apache.org/jira/browse/SLING-6398
> Project: Sling
>  Issue Type: Improvement
>  Components: Repoinit
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Repoinit JCR 1.1.2
>
> Attachments: 
> 0001-SLING-6368-Repoinit-should-not-attempt-to-create-acc.patch
>
>
> I have a more complex Sling setup based on the recent Oak multiplexing 
> additions.
> The repository is split bewteen
> - /libs and /apps, read-only
> - the rest of the repository, read-write
> When the provisioning model contains ACL definitions, they are processed 
> directly without checking if they exist. In turn, Oak updates the 
> definitions, even if equivalent ones exist. This causes the repoinit part to 
> fail if it refers to ACLs for the read-only part of the repository.
> I would propose that the repoinit statements check if the ACL really needs to 
> be replaced or if it can be skipped. This also has the advantage of making it 
> symmetric with the checks for service users and paths and also should 
> slightly reduce provisioning time.
> [~bdelacretaz] - would that work for you?



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

Re: Release of org.apache.sling.i18n

[Timothée Maret]

Hi Julian,

Thanks for looking at this! I could find out the issue. It was a rogue
/etc/hosts entry on my setup activated on VPN.

I'll proceed with the release shortly.

Regards,

Timothee

2016-12-13 12:33 GMT+01:00 Julian Sedding :

> Hi Timothee
>
> You need the instance logs to fully analyze the root cause, I think it
> may be in target/failsafe-reports/*-output.txt.
>
> In any case, I suspect the issue may be related to repository startup.
> I recently made repo startup asynchronous in bundles/jcr/base (no
> release yet), which allows additional services (e.g. service user
> amendments, login admin whitelist fragments, repository initializers)
> to be bound while the repo starts up (which can be a few seconds). As
> a side-effect, this seems to have improved the chances of the system
> being ready by the time tests are run.
>
> Regards
> Julian
>
>
> On Tue, Dec 13, 2016 at 11:45 AM, Timothee Maret 
> wrote:
> > Hi all,
> >
> > One thing that prevents me from running the release:prepare command for
> the
> > i18n bundle is that the Pax Exam seem to fail from time to time on my
> > machine. When it fails, it is because PaxExam can't find the remote
> > framework (the i18n tests run in a forked vm) [0].
> >
> > Is this a known issue or something that needs to be investigated ? Does
> > someone experience this as well (could be my environment) ?
> >
> > Regards,
> >
> > Timothee
> >
> > [0]
> >
> > Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 86.166
> sec
> > <<< FAILURE! - in org.apache.sling.i18n.it.ResourceBundleProviderIT
> > org.apache.sling.i18n.it.ResourceBundleProviderIT  Time elapsed: 86.165
> sec
> >  <<< ERROR!
> > org.ops4j.pax.exam.TestContainerException: cannot find remote framework
> in
> > RMI registry
> > at
> > org.ops4j.pax.exam.forked.ForkedFrameworkFactory.findRemoteFramework(
> ForkedFrameworkFactory.java:235)
> > at
> > org.ops4j.pax.exam.forked.ForkedFrameworkFactory.fork(
> ForkedFrameworkFactory.java:124)
> > at
> > org.ops4j.pax.exam.forked.ForkedTestContainer.start(
> ForkedTestContainer.java:162)
> > at
> > org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.setUp(
> EagerSingleStagedReactor.java:86)
> > at
> > org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.beforeClass(
> EagerSingleStagedReactor.java:136)
> > at
> > org.ops4j.pax.exam.spi.reactors.ReactorManager.
> beforeClass(ReactorManager.java:448)
> > at org.ops4j.pax.exam.junit.impl.ProbeRunner.run(ProbeRunner.java:97)
> > at org.ops4j.pax.exam.junit.PaxExam.run(PaxExam.java:93)
> > at
> > org.apache.maven.surefire.junit4.JUnit4Provider.execute(
> JUnit4Provider.java:283)
> > at
> > org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(
> JUnit4Provider.java:173)
> > at
> > org.apache.maven.surefire.junit4.JUnit4Provider.
> executeTestSet(JUnit4Provider.java:153)
> > at
> > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(
> JUnit4Provider.java:128)
> > at
> > org.apache.maven.surefire.booter.ForkedBooter.
> invokeProviderInSameClassLoader(ForkedBooter.java:203)
> > at
> > org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(
> ForkedBooter.java:155)
> > at org.apache.maven.surefire.booter.ForkedBooter.main(
> ForkedBooter.java:103)
> > Caused by: java.rmi.ConnectException: Connection refused to host:
> > 192.168.59.100; nested exception is:
> > java.net.ConnectException: Operation timed out
> > at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619)
> >
> > 2016-12-12 21:30 GMT+01:00 Robert Munteanu :
> >
> >> On Mon, 2016-12-12 at 20:39 +0100, Timothee Maret wrote:
> >> > Thanks Julian & Robert for your insight!
> >> >
> >> > The tests are fixed in r1773859 according to the successful run at
> >> > [2]
> >> > I'll follow [1] in order to eventually cut the release.
> >>
> >> Great, thanks for the quick turnaround!
> >>
> >> Robert
> >>
> >> >
> >> > Regards,
> >> >
> >> > Timothee
> >> >
> >> > [2]
> >> > https://builds.apache.org/view/S-Z/view/Sling-Dashboard/job/sling-bun
> >> > dles-extensions-i18n-1.8/7/
> >> >
> >> > 2016-12-12 14:39 GMT+01:00 Julian Sedding :
> >> >
> >> > > I think the failure is due to the fact the no
> >> > > "org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.ame
> >> > > nded"
> >> > > configuration is present for the Pax integration test in the i18n
> >> > > module.
> >> > >
> >> > > Regards
> >> > > Julian
> >> > >
> >> > > On Mon, Dec 12, 2016 at 2:20 PM, Robert Munteanu  >> > > g>
> >> > > wrote:
> >> > > > Hi,
> >> > > >
> >> > > > On Mon, 2016-12-12 at 11:03 +0100, Timothee Maret wrote:
> >> > > > > Hi,
> >> > > > >
> >> > > > > We fixed two bugs for org.apache.sling.i18n v 2.5.6 [0] and no
> >> > > > > issue
> >> > > > > is
> >> > > > > still opened.
> >> > > > > I think it'd make sense to cut a release for it, however I
> >> > > > > wonder
> >> > > > > how/who
> >> > > > > should do the release.
> 

[jira] [Updated] (SLING-6398) Repoinit should not attempt to create access control entries when no changes are needed

[Robert Munteanu (JIRA)]

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

Robert Munteanu updated SLING-6398:
---
Attachment: 0001-SLING-6368-Repoinit-should-not-attempt-to-create-acc.patch

[~bdelacretaz] - here's a patch that works for my scenario, with some tests 
added. 

I did not find a good way to test that the ACL is not set again, so I exposed 
an utility method from AclUtil and tested that.

The log entries are similar to

{noformat}15.12.2016 11:50:21.463 *INFO* [Apache Sling Repository Startup 
Thread] org.apache.sling.jcr.repoinit.impl.AclUtil Not adding 
[LocalAccessControlEntry# principal 
org.apache.jackrabbit.oak.security.user.SystemUserPrincipalImpl:sling-scripting,
 privileges: [jcr:read], isAllow : true] to path /libs since an equivalent 
access control entry already exists{noformat}

How does that look to you?

> Repoinit should not attempt to create access control entries when no changes 
> are needed
> ---
>
> Key: SLING-6398
> URL: https://issues.apache.org/jira/browse/SLING-6398
> Project: Sling
>  Issue Type: Improvement
>  Components: Repoinit
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Repoinit JCR 1.1.2
>
> Attachments: 
> 0001-SLING-6368-Repoinit-should-not-attempt-to-create-acc.patch
>
>
> I have a more complex Sling setup based on the recent Oak multiplexing 
> additions.
> The repository is split bewteen
> - /libs and /apps, read-only
> - the rest of the repository, read-write
> When the provisioning model contains ACL definitions, they are processed 
> directly without checking if they exist. In turn, Oak updates the 
> definitions, even if equivalent ones exist. This causes the repoinit part to 
> fail if it refers to ACLs for the read-only part of the repository.
> I would propose that the repoinit statements check if the ACL really needs to 
> be replaced or if it can be skipped. This also has the advantage of making it 
> symmetric with the checks for service users and paths and also should 
> slightly reduce provisioning time.
> [~bdelacretaz] - would that work for you?



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

[VOTE] Release Apache Sling Dynamic Include 3.0.0

[Bertrand Delacretaz]

Hi,

This is our first release of that module, see
https://issues.apache.org/jira/browse/SLING-6301 for details and
comments.

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

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 1598 /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-6301) First release Sling Dynamic Include: 3.0.0

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-6301:


I have prepared the org.apache.sling.dynamic-include 3.0.0 release, using that 
version number to clearly differentiate it from the version from which it was 
donated, https://github.com/Cognifide/Sling-Dynamic-Include . Starting the vote 
now.

I'm releasing this in "release early, release often" spirit but there are no 
automated tests so until we fix that this should be considered and alpha level 
release.

I have added a minimal documentation page at 
http://sling.apache.org/documentation/bundles/dynamic-includes.html



> First release Sling Dynamic Include: 3.0.0
> --
>
> Key: SLING-6301
> URL: https://issues.apache.org/jira/browse/SLING-6301
> Project: Sling
>  Issue Type: Wish
>Reporter: David Gonzalez
>Assignee: Bertrand Delacretaz
>
> Are there plans to cut a release of the Apache Sling Dynamic Include module 
> contributed via [1] 
> If it has been released can you point me to the bundle? I dont see the 
> artifact in any public repos.
> [1] https://issues.apache.org/jira/browse/SLING-5594



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

[jira] [Updated] (SLING-6301) First release Sling Dynamic Include: 3.0.0

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz updated SLING-6301:
---
Summary: First release Sling Dynamic Include: 3.0.0  (was: Release of Sling 
Dynamic Include)

> First release Sling Dynamic Include: 3.0.0
> --
>
> Key: SLING-6301
> URL: https://issues.apache.org/jira/browse/SLING-6301
> Project: Sling
>  Issue Type: Wish
>Reporter: David Gonzalez
>Assignee: Bertrand Delacretaz
>
> Are there plans to cut a release of the Apache Sling Dynamic Include module 
> contributed via [1] 
> If it has been released can you point me to the bundle? I dont see the 
> artifact in any public repos.
> [1] https://issues.apache.org/jira/browse/SLING-5594



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

[jira] [Assigned] (SLING-6301) Release of Sling Dynamic Include

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz reassigned SLING-6301:
--

Assignee: Bertrand Delacretaz

> Release of Sling Dynamic Include
> 
>
> Key: SLING-6301
> URL: https://issues.apache.org/jira/browse/SLING-6301
> Project: Sling
>  Issue Type: Wish
>Reporter: David Gonzalez
>Assignee: Bertrand Delacretaz
>
> Are there plans to cut a release of the Apache Sling Dynamic Include module 
> contributed via [1] 
> If it has been released can you point me to the bundle? I dont see the 
> artifact in any public repos.
> [1] https://issues.apache.org/jira/browse/SLING-5594



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

[jira] [Commented] (SLING-6398) Repoinit should not attempt to create access control entries when no changes are needed

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-6398:


In general I think it would be better for repoinit to describe a desired state 
rather the procedural operations on the ACLs, for example "I want user foo to 
be able to read /xyz" instead of "Add read ACL on /xyz for user foo". 

If you have ideas for getting closer to this declarative behavior let's discuss 
them on our dev list.

> Repoinit should not attempt to create access control entries when no changes 
> are needed
> ---
>
> Key: SLING-6398
> URL: https://issues.apache.org/jira/browse/SLING-6398
> Project: Sling
>  Issue Type: Improvement
>  Components: Repoinit
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Repoinit JCR 1.1.2
>
>
> I have a more complex Sling setup based on the recent Oak multiplexing 
> additions.
> The repository is split bewteen
> - /libs and /apps, read-only
> - the rest of the repository, read-write
> When the provisioning model contains ACL definitions, they are processed 
> directly without checking if they exist. In turn, Oak updates the 
> definitions, even if equivalent ones exist. This causes the repoinit part to 
> fail if it refers to ACLs for the read-only part of the repository.
> I would propose that the repoinit statements check if the ACL really needs to 
> be replaced or if it can be skipped. This also has the advantage of making it 
> symmetric with the checks for service users and paths and also should 
> slightly reduce provisioning time.
> [~bdelacretaz] - would that work for you?



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

[jira] [Commented] (SLING-6398) Repoinit should not attempt to create access control entries when no changes are needed

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-6398:


Coming back to this, I think that I can't support this scenario with perfect 
equality since the ACEs on some paths are created from many sources. So you can 
end up with 5 ACEs on /libs, added from 3 blocks. Each of the 3 blocks would 
cause the ACL to be regenerated, which defeats the purpose of my patch. I will 
revert to checking individual entries (for now).

> Repoinit should not attempt to create access control entries when no changes 
> are needed
> ---
>
> Key: SLING-6398
> URL: https://issues.apache.org/jira/browse/SLING-6398
> Project: Sling
>  Issue Type: Improvement
>  Components: Repoinit
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Repoinit JCR 1.1.2
>
>
> I have a more complex Sling setup based on the recent Oak multiplexing 
> additions.
> The repository is split bewteen
> - /libs and /apps, read-only
> - the rest of the repository, read-write
> When the provisioning model contains ACL definitions, they are processed 
> directly without checking if they exist. In turn, Oak updates the 
> definitions, even if equivalent ones exist. This causes the repoinit part to 
> fail if it refers to ACLs for the read-only part of the repository.
> I would propose that the repoinit statements check if the ACL really needs to 
> be replaced or if it can be skipped. This also has the advantage of making it 
> symmetric with the checks for service users and paths and also should 
> slightly reduce provisioning time.
> [~bdelacretaz] - would that work for you?



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