[jira] [Resolved] (SLING-7074) RRD4J improve configuration handling

[Robert Munteanu (JIRA)]

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

Robert Munteanu resolved SLING-7074.

Resolution: Fixed

Absolutely [~stillalex] :-) I was waiting for you and Marcel to settle over the 
patch.

Applied in [r1806051|https://svn.apache.org/r1806051], thanks for the 
contribution

> RRD4J improve configuration handling
> 
>
> Key: SLING-7074
> URL: https://issues.apache.org/jira/browse/SLING-7074
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Reporter: Alex Deparvu
>Assignee: Robert Munteanu
>Priority: Minor
> Fix For: Commons Metrics RRD4J 1.0.0
>
> Attachments: SLING-7074.patch, SLING-7074-v2.patch
>
>
> Opened the config manager and deleted all entries
> {noformat}
>   *ERROR* [CM Event Dispatcher (Fire ConfigurationEvent: 
> pid=org.apache.sling.commons.metrics.rrd4j.impl.CodahaleMetricsReporter)] 
> org.apache.sling.commons.metrics-rrd4j 
> [org.apache.sling.commons.metrics.rrd4j.impl.CodahaleMetricsReporter(3134)] 
> The activate method has thrown an exception (java.lang.NullPointerException)
> java.lang.NullPointerException: null
> at 
> org.apache.sling.commons.metrics.rrd4j.impl.RRD4JReporter$Builder.withDatasources(RRD4JReporter.java:91)
> at 
> org.apache.sling.commons.metrics.rrd4j.impl.CodahaleMetricsReporter.activate(CodahaleMetricsReporter.java:143)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> {noformat}
> fyi [~mreutegg]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (SLING-7074) RRD4J improve configuration handling

[Robert Munteanu (JIRA)]

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

Robert Munteanu reassigned SLING-7074:
--

Assignee: Robert Munteanu

> RRD4J improve configuration handling
> 
>
> Key: SLING-7074
> URL: https://issues.apache.org/jira/browse/SLING-7074
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Reporter: Alex Deparvu
>Assignee: Robert Munteanu
>Priority: Minor
> Fix For: Commons Metrics RRD4J 1.0.0
>
> Attachments: SLING-7074.patch, SLING-7074-v2.patch
>
>
> Opened the config manager and deleted all entries
> {noformat}
>   *ERROR* [CM Event Dispatcher (Fire ConfigurationEvent: 
> pid=org.apache.sling.commons.metrics.rrd4j.impl.CodahaleMetricsReporter)] 
> org.apache.sling.commons.metrics-rrd4j 
> [org.apache.sling.commons.metrics.rrd4j.impl.CodahaleMetricsReporter(3134)] 
> The activate method has thrown an exception (java.lang.NullPointerException)
> java.lang.NullPointerException: null
> at 
> org.apache.sling.commons.metrics.rrd4j.impl.RRD4JReporter$Builder.withDatasources(RRD4JReporter.java:91)
> at 
> org.apache.sling.commons.metrics.rrd4j.impl.CodahaleMetricsReporter.activate(CodahaleMetricsReporter.java:143)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> {noformat}
> fyi [~mreutegg]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (SLING-7085) Reduce code duplication

[Radu Cotescu (JIRA)]

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

Radu Cotescu updated SLING-7085:

Summary: Reduce code duplication  (was: Remove code duplication)

> Reduce code duplication
> ---
>
> Key: SLING-7085
> URL: https://issues.apache.org/jira/browse/SLING-7085
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting HTL Engine 1.0.20, Scripting HTL Compiler 
> 1.0.0, Scripting HTL Java Compiler 1.0.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Scripting HTL Engine 1.0.38, Scripting HTL Compiler 
> 1.0.12, Scripting HTL Java Compiler 1.0.12
>
>
> The modularisation of the HTL modules implemented in SLING-5787 introduced 
> some code duplication:
> * 
> https://github.com/apache/sling/blob/1aa2c8be782ecb858de9030501e67edc4aba1357/bundles/scripting/sightly/compiler/src/main/java/org/apache/sling/scripting/sightly/impl/compiler/CompileTimeObjectModel.java
> * 
> https://github.com/apache/sling/blob/1aa2c8be782ecb858de9030501e67edc4aba1357/bundles/scripting/sightly/java-compiler/src/main/java/org/apache/sling/scripting/sightly/render/AbstractRuntimeObjectModel.java
> * 
> https://github.com/apache/sling/blob/1aa2c8be782ecb858de9030501e67edc4aba1357/bundles/scripting/sightly/engine/src/main/java/org/apache/sling/scripting/sightly/impl/engine/runtime/SlingRuntimeObjectModel.java
> To reduce code duplication {{CompileTimeObjectModel}} should be exported as 
> {{ObjectModel}} and extend its methods with the specifics of each module 
> needing the functionality.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (SLING-3224) GetAclTest integration test fails due to incorrect privilege expansion in AbstractGetAclServlet

[Robert Munteanu (JIRA)]

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

Robert Munteanu updated SLING-3224:
---
Component/s: (was: Testing)
 JCR

> GetAclTest integration test fails due to incorrect privilege expansion in 
> AbstractGetAclServlet
> ---
>
> Key: SLING-3224
> URL: https://issues.apache.org/jira/browse/SLING-3224
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Reporter: Bertrand Delacretaz
>Priority: Minor
>  Labels: sling-IT
> Fix For: JCR Jackrabbit Access Manager 3.0.2
>
>
> Failed tests:   testEffectiveAclMergeForUser_SubsetOfPrivilegesDeniedOnChild:
> Expected privilege jcr:modifyProperties to be NOT INCLUDED in supplied list: 
> [rep:userManagement, jcr:nodeTypeManagement, jcr:modifyProperties, 
> jcr:namespaceManagement, rep:privilegeManagement, jcr:workspaceManagement, 
> rep:readProperties, rep:alterProperties, jcr:nodeTypeDefinitionManagement, 
> jcr:lockManagement, jcr:read, jcr:lifecycleManagement, jcr:removeNode, 
> jcr:modifyAccessControl, jcr:removeChildNodes, jcr:versionManagement, 
> rep:addProperties, rep:removeProperties, rep:readNodes, 
> jcr:readAccessControl, jcr:addChildNodes, jcr:retentionManagement])



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (SLING-7085) Remove code duplication

[Radu Cotescu (JIRA)]

Radu Cotescu created SLING-7085:
---

 Summary: Remove code duplication
 Key: SLING-7085
 URL: https://issues.apache.org/jira/browse/SLING-7085
 Project: Sling
  Issue Type: Bug
  Components: Scripting
Affects Versions: Scripting HTL Java Compiler 1.0.0, Scripting HTL Compiler 
1.0.0, Scripting HTL Engine 1.0.20
Reporter: Radu Cotescu
Assignee: Radu Cotescu
 Fix For: Scripting HTL Compiler 1.0.12, Scripting HTL Java 
Compiler 1.0.12, Scripting HTL Engine 1.0.38


The modularisation of the HTL modules implemented in SLING-5787 introduced some 
code duplication:

* 
https://github.com/apache/sling/blob/1aa2c8be782ecb858de9030501e67edc4aba1357/bundles/scripting/sightly/compiler/src/main/java/org/apache/sling/scripting/sightly/impl/compiler/CompileTimeObjectModel.java
* 
https://github.com/apache/sling/blob/1aa2c8be782ecb858de9030501e67edc4aba1357/bundles/scripting/sightly/java-compiler/src/main/java/org/apache/sling/scripting/sightly/render/AbstractRuntimeObjectModel.java
* 
https://github.com/apache/sling/blob/1aa2c8be782ecb858de9030501e67edc4aba1357/bundles/scripting/sightly/engine/src/main/java/org/apache/sling/scripting/sightly/impl/engine/runtime/SlingRuntimeObjectModel.java

To reduce code duplication {{CompileTimeObjectModel}} should be exported as 
{{ObjectModel}} and extend its methods with the specifics of each module 
needing the functionality.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (SLING-3224) GetAclTest integration test fails due to incorrect privilege expansion in AbstractGetAclServlet

[Robert Munteanu (JIRA)]

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

Robert Munteanu resolved SLING-3224.

Resolution: Fixed

> GetAclTest integration test fails due to incorrect privilege expansion in 
> AbstractGetAclServlet
> ---
>
> Key: SLING-3224
> URL: https://issues.apache.org/jira/browse/SLING-3224
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Reporter: Bertrand Delacretaz
>Assignee: Robert Munteanu
>  Labels: sling-IT
> Fix For: JCR Jackrabbit Access Manager 3.0.2
>
>
> Failed tests:   testEffectiveAclMergeForUser_SubsetOfPrivilegesDeniedOnChild:
> Expected privilege jcr:modifyProperties to be NOT INCLUDED in supplied list: 
> [rep:userManagement, jcr:nodeTypeManagement, jcr:modifyProperties, 
> jcr:namespaceManagement, rep:privilegeManagement, jcr:workspaceManagement, 
> rep:readProperties, rep:alterProperties, jcr:nodeTypeDefinitionManagement, 
> jcr:lockManagement, jcr:read, jcr:lifecycleManagement, jcr:removeNode, 
> jcr:modifyAccessControl, jcr:removeChildNodes, jcr:versionManagement, 
> rep:addProperties, rep:removeProperties, rep:readNodes, 
> jcr:readAccessControl, jcr:addChildNodes, jcr:retentionManagement])



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-3224) GetAclTest integration test fails due to incorrect privilege expansion in AbstractGetAclServlet

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-3224:


* fixed bug with minor refactoring + extensive tests in 
[r1806048|https://svn.apache.org/r1806048] 
* remove failing test in [r1806049|https://svn.apache.org/1806049] after 
validating that the test passes with the SNAPSHOT version of the bundle

I've removed the test since it was testing a very specific scenario now covered 
in a unit test placed in the bundle. I've left the over tests to make sure we 
have some integration coverage.

> GetAclTest integration test fails due to incorrect privilege expansion in 
> AbstractGetAclServlet
> ---
>
> Key: SLING-3224
> URL: https://issues.apache.org/jira/browse/SLING-3224
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Reporter: Bertrand Delacretaz
>Assignee: Robert Munteanu
>  Labels: sling-IT
> Fix For: JCR Jackrabbit Access Manager 3.0.2
>
>
> Failed tests:   testEffectiveAclMergeForUser_SubsetOfPrivilegesDeniedOnChild:
> Expected privilege jcr:modifyProperties to be NOT INCLUDED in supplied list: 
> [rep:userManagement, jcr:nodeTypeManagement, jcr:modifyProperties, 
> jcr:namespaceManagement, rep:privilegeManagement, jcr:workspaceManagement, 
> rep:readProperties, rep:alterProperties, jcr:nodeTypeDefinitionManagement, 
> jcr:lockManagement, jcr:read, jcr:lifecycleManagement, jcr:removeNode, 
> jcr:modifyAccessControl, jcr:removeChildNodes, jcr:versionManagement, 
> rep:addProperties, rep:removeProperties, rep:readNodes, 
> jcr:readAccessControl, jcr:addChildNodes, jcr:retentionManagement])



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (SLING-3224) GetAclTest integration test fails due to incorrect privilege expansion in AbstractGetAclServlet

[Robert Munteanu (JIRA)]

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

Robert Munteanu edited comment on SLING-3224 at 8/24/17 1:45 PM:
-

Stepping through the code I can see that Oak returns the privileges correctly. 
However, in {{AbstractGetAclServlet.internalGetAcl}} , the 
{{mergePrivilegeSet}} invocation does not work properly. The call that fails is 
at line 181:

{code:java}
mergePrivilegeSets(privilege,
privilegeToAncestorMap,
deniedSet, grantedSet);
{code}

where privilege is {{jcr:write}}, deniedSet is empty and grantedSet is 
{{jcr:all}}.

The logic is quite involved but I guess expansion of aggregate privileges is 
broken here.

_Edit_: typo


was (Author: rombert):
Stepping through the code I can see that Oak returns the privileges correctly. 
However, in {{AbstractGetAclServlet.internalGetAcl}} , the 
{{mergePrivilegeSet}} invocation does not work properly. The call that fails is 
at line 181:

{code:java}
mergePrivilegeSets(privilege,
privilegeToAncestorMap,
deniedSet, grantedSet);
{code}

where privilege is {{jcr:write}, deniedSet is empty and grantedSet is 
{{jcr:all}}.

The logic is quite involved but I guess expansion of aggregate privileges is 
broken here.

> GetAclTest integration test fails due to incorrect privilege expansion in 
> AbstractGetAclServlet
> ---
>
> Key: SLING-3224
> URL: https://issues.apache.org/jira/browse/SLING-3224
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Reporter: Bertrand Delacretaz
>Assignee: Robert Munteanu
>  Labels: sling-IT
> Fix For: JCR Jackrabbit Access Manager 3.0.2
>
>
> Failed tests:   testEffectiveAclMergeForUser_SubsetOfPrivilegesDeniedOnChild:
> Expected privilege jcr:modifyProperties to be NOT INCLUDED in supplied list: 
> [rep:userManagement, jcr:nodeTypeManagement, jcr:modifyProperties, 
> jcr:namespaceManagement, rep:privilegeManagement, jcr:workspaceManagement, 
> rep:readProperties, rep:alterProperties, jcr:nodeTypeDefinitionManagement, 
> jcr:lockManagement, jcr:read, jcr:lifecycleManagement, jcr:removeNode, 
> jcr:modifyAccessControl, jcr:removeChildNodes, jcr:versionManagement, 
> rep:addProperties, rep:removeProperties, rep:readNodes, 
> jcr:readAccessControl, jcr:addChildNodes, jcr:retentionManagement])



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (SLING-3224) GetAclTest integration test fails due to incorrect privilege expansion in AbstractGetAclServlet

[Robert Munteanu (JIRA)]

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

Robert Munteanu reassigned SLING-3224:
--

Assignee: Robert Munteanu

> GetAclTest integration test fails due to incorrect privilege expansion in 
> AbstractGetAclServlet
> ---
>
> Key: SLING-3224
> URL: https://issues.apache.org/jira/browse/SLING-3224
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Reporter: Bertrand Delacretaz
>Assignee: Robert Munteanu
>  Labels: sling-IT
> Fix For: JCR Jackrabbit Access Manager 3.0.2
>
>
> Failed tests:   testEffectiveAclMergeForUser_SubsetOfPrivilegesDeniedOnChild:
> Expected privilege jcr:modifyProperties to be NOT INCLUDED in supplied list: 
> [rep:userManagement, jcr:nodeTypeManagement, jcr:modifyProperties, 
> jcr:namespaceManagement, rep:privilegeManagement, jcr:workspaceManagement, 
> rep:readProperties, rep:alterProperties, jcr:nodeTypeDefinitionManagement, 
> jcr:lockManagement, jcr:read, jcr:lifecycleManagement, jcr:removeNode, 
> jcr:modifyAccessControl, jcr:removeChildNodes, jcr:versionManagement, 
> rep:addProperties, rep:removeProperties, rep:readNodes, 
> jcr:readAccessControl, jcr:addChildNodes, jcr:retentionManagement])



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (SLING-3224) GetAclTest integration test fails due to incorrect privilege expansion in AbstractGetAclServlet

[Robert Munteanu (JIRA)]

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

Robert Munteanu updated SLING-3224:
---
Priority: Major  (was: Minor)

> GetAclTest integration test fails due to incorrect privilege expansion in 
> AbstractGetAclServlet
> ---
>
> Key: SLING-3224
> URL: https://issues.apache.org/jira/browse/SLING-3224
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Reporter: Bertrand Delacretaz
>  Labels: sling-IT
> Fix For: JCR Jackrabbit Access Manager 3.0.2
>
>
> Failed tests:   testEffectiveAclMergeForUser_SubsetOfPrivilegesDeniedOnChild:
> Expected privilege jcr:modifyProperties to be NOT INCLUDED in supplied list: 
> [rep:userManagement, jcr:nodeTypeManagement, jcr:modifyProperties, 
> jcr:namespaceManagement, rep:privilegeManagement, jcr:workspaceManagement, 
> rep:readProperties, rep:alterProperties, jcr:nodeTypeDefinitionManagement, 
> jcr:lockManagement, jcr:read, jcr:lifecycleManagement, jcr:removeNode, 
> jcr:modifyAccessControl, jcr:removeChildNodes, jcr:versionManagement, 
> rep:addProperties, rep:removeProperties, rep:readNodes, 
> jcr:readAccessControl, jcr:addChildNodes, jcr:retentionManagement])



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (SLING-3224) GetAclTest integration test fails due to incorrect privilege expansion in AbstractGetAclServlet

[Robert Munteanu (JIRA)]

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

Robert Munteanu updated SLING-3224:
---
Fix Version/s: JCR Jackrabbit Access Manager 3.0.2

> GetAclTest integration test fails due to incorrect privilege expansion in 
> AbstractGetAclServlet
> ---
>
> Key: SLING-3224
> URL: https://issues.apache.org/jira/browse/SLING-3224
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Reporter: Bertrand Delacretaz
>Priority: Minor
>  Labels: sling-IT
> Fix For: JCR Jackrabbit Access Manager 3.0.2
>
>
> Failed tests:   testEffectiveAclMergeForUser_SubsetOfPrivilegesDeniedOnChild:
> Expected privilege jcr:modifyProperties to be NOT INCLUDED in supplied list: 
> [rep:userManagement, jcr:nodeTypeManagement, jcr:modifyProperties, 
> jcr:namespaceManagement, rep:privilegeManagement, jcr:workspaceManagement, 
> rep:readProperties, rep:alterProperties, jcr:nodeTypeDefinitionManagement, 
> jcr:lockManagement, jcr:read, jcr:lifecycleManagement, jcr:removeNode, 
> jcr:modifyAccessControl, jcr:removeChildNodes, jcr:versionManagement, 
> rep:addProperties, rep:removeProperties, rep:readNodes, 
> jcr:readAccessControl, jcr:addChildNodes, jcr:retentionManagement])



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-7061) Access control setup of repository-level permissions (i.e. null path)

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-7061:


Your alternative syntax makes sense, and IIUC if we respect the order of 
statements just inside the set/end blocks we're good w.r.t. your ordering 
example?

If yes I think that's a strong reason for supporting that alternative syntax.

However there are also cases where it leads to having to duplicate principal 
names, which is not convenient. So it's probably best to support both that 
syntax and the "set ACL on repository for <1..N principals>" that I suggested? 
I think that's not hard to do the way the parser is built. The principal names 
cannot be in both places though, it's either "my" or "your" syntax but not a 
mix of both.

As for ordering, you're right that composing various repoinit sources would 
need to be checked as well, so if we can avoid that and only respect ordering 
within statements that's much better IMO.

> Access control setup of repository-level permissions (i.e. null path)
> -
>
> Key: SLING-7061
> URL: https://issues.apache.org/jira/browse/SLING-7061
> Project: Sling
>  Issue Type: Improvement
>  Components: Repoinit
>Affects Versions: Repoinit Parser 1.1.0
>Reporter: angela
>Assignee: Timothee Maret
> Fix For: Repoinit Parser 1.1.2, Repoinit JCR 1.1.6
>
>
> If I am not mistaken it is currently not possible to create access control 
> setup for principals at the 'null' path, which according to JSR 283 is to be 
> used to setup repository level permissions such as 
> - node type definition management (i.e. registering new node types)
> - namespace management (i.e. registering new namespaces)
> - privilege management (i.e. registering new privileges)
> - workspace management (i.e. creating/removing workspaces)
> All of these operations are not bound to a path (like e.g. removing an item 
> or creating a new version for a given node) but instead take global effect on 
> the whole JCR repository... that's why permissions for these operations 
> cannot be granted at a given path.
> In the default authorization model shipped with Jackrabbit and Oak the -null- 
> path access control policy is stored with a dedicated _rep:repoPolicy_ node 
> located with the root node and 
> For service user definitions we need to be able to define entries for the 
> -null- path policy for the reasons explained above. Thanks for extending the 
> repo-init accordingly.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-6423) Allow for specifying ACL merge mode (ACHandling) in repoinit

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra commented on SLING-6423:
-

IIRC, the filevault merge also applies the ACE declarations on existing nodes. 
and IIUC, in the repoinit, the same must happen; i.e. the repo init defines the 
changed ACEs that should be applied to nodes.

> Allow for specifying ACL merge mode (ACHandling) in repoinit
> 
>
> Key: SLING-6423
> URL: https://issues.apache.org/jira/browse/SLING-6423
> Project: Sling
>  Issue Type: New Feature
>  Components: Repoinit
>Reporter: Nitin Nizhawan
>Assignee: Timothee Maret
> Fix For: Repoinit Parser 1.1.2
>
> Attachments: SLING-6423_parser_changes.patch, 
> SLING-6423_testcases.patch, SLING_6423_testcasesV2.patch
>
>
> Repoinit by default just add new ACLs if they are not already present.
> By contract package manager provides various strategies for ACL merging
> Extend repoinit to allow specifying these strategies 
> https://jackrabbit.apache.org/filevault/apidocs/org/apache/jackrabbit/vault/fs/io/AccessControlHandling.html#MERGE



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (SLING-7074) RRD4J improve configuration handling

[Alex Deparvu (JIRA)]

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

Alex Deparvu edited comment on SLING-7074 at 8/24/17 1:17 PM:
--

bq. IIUC the activate would throw an exception if I remove the path 
configuration entry. What do you think about a fallback to the default path in 
that case?
good point. I was covered for null, but not for empty strings. I've updated the 
patch to cover this as well: [^SLING-7074-v2.patch]

[~rombert] would you mind taking a look at the patch and applying some of that 
committer magic if it looks good? :)


was (Author: alex.parvulescu):
bq. IIUC the activate would throw an exception if I remove the path 
configuration entry. What do you think about a fallback to the default path in 
that case?
good point. I was covered for null, but not for empty strings. I've updated the 
patch to cover this as well: [^SLING-7074-v2.patch]

> RRD4J improve configuration handling
> 
>
> Key: SLING-7074
> URL: https://issues.apache.org/jira/browse/SLING-7074
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Reporter: Alex Deparvu
>Priority: Minor
> Fix For: Commons Metrics RRD4J 1.0.0
>
> Attachments: SLING-7074.patch, SLING-7074-v2.patch
>
>
> Opened the config manager and deleted all entries
> {noformat}
>   *ERROR* [CM Event Dispatcher (Fire ConfigurationEvent: 
> pid=org.apache.sling.commons.metrics.rrd4j.impl.CodahaleMetricsReporter)] 
> org.apache.sling.commons.metrics-rrd4j 
> [org.apache.sling.commons.metrics.rrd4j.impl.CodahaleMetricsReporter(3134)] 
> The activate method has thrown an exception (java.lang.NullPointerException)
> java.lang.NullPointerException: null
> at 
> org.apache.sling.commons.metrics.rrd4j.impl.RRD4JReporter$Builder.withDatasources(RRD4JReporter.java:91)
> at 
> org.apache.sling.commons.metrics.rrd4j.impl.CodahaleMetricsReporter.activate(CodahaleMetricsReporter.java:143)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> {noformat}
> fyi [~mreutegg]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (SLING-7074) RRD4J improve configuration handling

[Alex Deparvu (JIRA)]

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

Alex Deparvu updated SLING-7074:

Summary: RRD4J improve configuration handling  (was: RRD4J NPE on removing 
all "Data sources" from config)

> RRD4J improve configuration handling
> 
>
> Key: SLING-7074
> URL: https://issues.apache.org/jira/browse/SLING-7074
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Reporter: Alex Deparvu
>Priority: Minor
> Fix For: Commons Metrics RRD4J 1.0.0
>
> Attachments: SLING-7074.patch, SLING-7074-v2.patch
>
>
> Opened the config manager and deleted all entries
> {noformat}
>   *ERROR* [CM Event Dispatcher (Fire ConfigurationEvent: 
> pid=org.apache.sling.commons.metrics.rrd4j.impl.CodahaleMetricsReporter)] 
> org.apache.sling.commons.metrics-rrd4j 
> [org.apache.sling.commons.metrics.rrd4j.impl.CodahaleMetricsReporter(3134)] 
> The activate method has thrown an exception (java.lang.NullPointerException)
> java.lang.NullPointerException: null
> at 
> org.apache.sling.commons.metrics.rrd4j.impl.RRD4JReporter$Builder.withDatasources(RRD4JReporter.java:91)
> at 
> org.apache.sling.commons.metrics.rrd4j.impl.CodahaleMetricsReporter.activate(CodahaleMetricsReporter.java:143)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> {noformat}
> fyi [~mreutegg]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-7061) Access control setup of repository-level permissions (i.e. null path)

[Timothee Maret (JIRA)]

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

Timothee Maret commented on SLING-7061:
---

bq. can you provide an example?

Assuming this setup defined in a provisioning model

{code}
# user1 is member of group1

set repository ACL for user1
allow perm1
end

set repository ACL for group1
deny perm1
end
{code}

If the order of execution is defined, for instance from top to bottom in the 
provisioning model, then the repository setup will deterministic.

If the order of execution is not defined, then we don't know if user1 will be 
denied or allowed permission for perm1.

bq. Or an alternate syntax that works better for your case.

The alternative syntax may have been

{code}
set ACL on repository
allow perm1 for user1
deny perm1 for group1
end
{code}

bq. I think so but if we need that it must be demonstrated by automated tests.

Ok, I'll give it a try. 

In general, I think the order also needs to be defined when composing 
provisioning models.

> Access control setup of repository-level permissions (i.e. null path)
> -
>
> Key: SLING-7061
> URL: https://issues.apache.org/jira/browse/SLING-7061
> Project: Sling
>  Issue Type: Improvement
>  Components: Repoinit
>Affects Versions: Repoinit Parser 1.1.0
>Reporter: angela
>Assignee: Timothee Maret
> Fix For: Repoinit Parser 1.1.2, Repoinit JCR 1.1.6
>
>
> If I am not mistaken it is currently not possible to create access control 
> setup for principals at the 'null' path, which according to JSR 283 is to be 
> used to setup repository level permissions such as 
> - node type definition management (i.e. registering new node types)
> - namespace management (i.e. registering new namespaces)
> - privilege management (i.e. registering new privileges)
> - workspace management (i.e. creating/removing workspaces)
> All of these operations are not bound to a path (like e.g. removing an item 
> or creating a new version for a given node) but instead take global effect on 
> the whole JCR repository... that's why permissions for these operations 
> cannot be granted at a given path.
> In the default authorization model shipped with Jackrabbit and Oak the -null- 
> path access control policy is stored with a dedicated _rep:repoPolicy_ node 
> located with the root node and 
> For service user definitions we need to be able to define entries for the 
> -null- path policy for the reasons explained above. Thanks for extending the 
> repo-init accordingly.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-7074) RRD4J NPE on removing all "Data sources" from config

[Alex Deparvu (JIRA)]

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

Alex Deparvu commented on SLING-7074:
-

bq. IIUC the activate would throw an exception if I remove the path 
configuration entry. What do you think about a fallback to the default path in 
that case?
good point. I was covered for null, but not for empty strings. I've updated the 
patch to cover this as well: [^SLING-7074-v2.patch]

> RRD4J NPE on removing all "Data sources" from config
> 
>
> Key: SLING-7074
> URL: https://issues.apache.org/jira/browse/SLING-7074
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Reporter: Alex Deparvu
>Priority: Minor
> Fix For: Commons Metrics RRD4J 1.0.0
>
> Attachments: SLING-7074.patch, SLING-7074-v2.patch
>
>
> Opened the config manager and deleted all entries
> {noformat}
>   *ERROR* [CM Event Dispatcher (Fire ConfigurationEvent: 
> pid=org.apache.sling.commons.metrics.rrd4j.impl.CodahaleMetricsReporter)] 
> org.apache.sling.commons.metrics-rrd4j 
> [org.apache.sling.commons.metrics.rrd4j.impl.CodahaleMetricsReporter(3134)] 
> The activate method has thrown an exception (java.lang.NullPointerException)
> java.lang.NullPointerException: null
> at 
> org.apache.sling.commons.metrics.rrd4j.impl.RRD4JReporter$Builder.withDatasources(RRD4JReporter.java:91)
> at 
> org.apache.sling.commons.metrics.rrd4j.impl.CodahaleMetricsReporter.activate(CodahaleMetricsReporter.java:143)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> {noformat}
> fyi [~mreutegg]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [RT] Drop port 8888?

[Oliver Lietz]

On Thursday 24 August 2017 13:34:08 Robert Munteanu wrote:
> On Thu, 2017-08-24 at 13:19 +0200, Oliver Lietz wrote:
> > I guess  was chosen to prevent clashes with other servers running
> > on the
> > same machine and bound to 8080, e.g. Jenkins or regular Sling. Why
> > not use
> > dynamic ports when running tests?
> 
> Integration tests are using dynamic ports as far as I know. So there
> would be no clashes there.

launchpad/integration-tests is using a fixed port but 8080.

To prevent accidents (writing test data to local Sling instances*) I would 
omit any default port and force users to provide one (not running any tests 
when port is missing).

Regards,
O.

* I guess I could happen quite fast when developers build Sling modules 
locally

> Robert

[jira] [Updated] (SLING-7074) RRD4J NPE on removing all "Data sources" from config

[Alex Deparvu (JIRA)]

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

Alex Deparvu updated SLING-7074:

Attachment: SLING-7074-v2.patch

> RRD4J NPE on removing all "Data sources" from config
> 
>
> Key: SLING-7074
> URL: https://issues.apache.org/jira/browse/SLING-7074
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Reporter: Alex Deparvu
>Priority: Minor
> Fix For: Commons Metrics RRD4J 1.0.0
>
> Attachments: SLING-7074.patch, SLING-7074-v2.patch
>
>
> Opened the config manager and deleted all entries
> {noformat}
>   *ERROR* [CM Event Dispatcher (Fire ConfigurationEvent: 
> pid=org.apache.sling.commons.metrics.rrd4j.impl.CodahaleMetricsReporter)] 
> org.apache.sling.commons.metrics-rrd4j 
> [org.apache.sling.commons.metrics.rrd4j.impl.CodahaleMetricsReporter(3134)] 
> The activate method has thrown an exception (java.lang.NullPointerException)
> java.lang.NullPointerException: null
> at 
> org.apache.sling.commons.metrics.rrd4j.impl.RRD4JReporter$Builder.withDatasources(RRD4JReporter.java:91)
> at 
> org.apache.sling.commons.metrics.rrd4j.impl.CodahaleMetricsReporter.activate(CodahaleMetricsReporter.java:143)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> {noformat}
> fyi [~mreutegg]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-7084) Coverage report is not generated correctly for HTL modules

[Radu Cotescu (JIRA)]

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

Radu Cotescu closed SLING-7084.
---

> Coverage report is not generated correctly for HTL modules
> --
>
> Key: SLING-7084
> URL: https://issues.apache.org/jira/browse/SLING-7084
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>
> Due to SLING-7083 the code coverage report built by the Apache Sling 
> Scripting HTL Integration Tests module is not generated correctly, being 
> either incomplete or inexistent (if the jacoco agent hasn't managed to write 
> anything into the {{jacoco-it.exec}} file before the {{verify}} phase is 
> started.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (SLING-7084) Coverage report is not generated correctly for HTL modules

[Radu Cotescu (JIRA)]

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

Radu Cotescu resolved SLING-7084.
-
Resolution: Fixed

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

> Coverage report is not generated correctly for HTL modules
> --
>
> Key: SLING-7084
> URL: https://issues.apache.org/jira/browse/SLING-7084
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>
> Due to SLING-7083 the code coverage report built by the Apache Sling 
> Scripting HTL Integration Tests module is not generated correctly, being 
> either incomplete or inexistent (if the jacoco agent hasn't managed to write 
> anything into the {{jacoco-it.exec}} file before the {{verify}} phase is 
> started.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-7061) Access control setup of repository-level permissions (i.e. null path)

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-7061:


bq.  ...If we need to set different ACLs for different principals, then we 
would need multiple set, end blocks...

I'm not sure what you mean, can you provide an example? Or an alternate syntax 
that works better for your case.

bq. ...Do we guarantee that repoinit blocks are evaluated in order ?...

I think so but if we need that it must be demonstrated by automated tests.

> Access control setup of repository-level permissions (i.e. null path)
> -
>
> Key: SLING-7061
> URL: https://issues.apache.org/jira/browse/SLING-7061
> Project: Sling
>  Issue Type: Improvement
>  Components: Repoinit
>Affects Versions: Repoinit Parser 1.1.0
>Reporter: angela
>Assignee: Timothee Maret
> Fix For: Repoinit Parser 1.1.2, Repoinit JCR 1.1.6
>
>
> If I am not mistaken it is currently not possible to create access control 
> setup for principals at the 'null' path, which according to JSR 283 is to be 
> used to setup repository level permissions such as 
> - node type definition management (i.e. registering new node types)
> - namespace management (i.e. registering new namespaces)
> - privilege management (i.e. registering new privileges)
> - workspace management (i.e. creating/removing workspaces)
> All of these operations are not bound to a path (like e.g. removing an item 
> or creating a new version for a given node) but instead take global effect on 
> the whole JCR repository... that's why permissions for these operations 
> cannot be granted at a given path.
> In the default authorization model shipped with Jackrabbit and Oak the -null- 
> path access control policy is stored with a dedicated _rep:repoPolicy_ node 
> located with the root node and 
> For service user definitions we need to be able to define entries for the 
> -null- path policy for the reasons explained above. Thanks for extending the 
> repo-init accordingly.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-7061) Access control setup of repository-level permissions (i.e. null path)

[Timothee Maret (JIRA)]

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

Timothee Maret commented on SLING-7061:
---

[~bdelacretaz] IIUC the syntax you propose is concise, but it limits the 
principals concerned by an {{set}}, {{end}} block to a fixed number of 
principals. If we need to set different ACLs for different principals, then we 
would need multiple {{set}}, {{end}} blocks.

Since the order of ACEs is meaningful, I wanted to confirm with you if an 
execution order is already defined between the {{set}}, {{end}} blocks. Do we 
guarantee that repoinit blocks are evaluated in order ?

> Access control setup of repository-level permissions (i.e. null path)
> -
>
> Key: SLING-7061
> URL: https://issues.apache.org/jira/browse/SLING-7061
> Project: Sling
>  Issue Type: Improvement
>  Components: Repoinit
>Affects Versions: Repoinit Parser 1.1.0
>Reporter: angela
>Assignee: Timothee Maret
> Fix For: Repoinit Parser 1.1.2, Repoinit JCR 1.1.6
>
>
> If I am not mistaken it is currently not possible to create access control 
> setup for principals at the 'null' path, which according to JSR 283 is to be 
> used to setup repository level permissions such as 
> - node type definition management (i.e. registering new node types)
> - namespace management (i.e. registering new namespaces)
> - privilege management (i.e. registering new privileges)
> - workspace management (i.e. creating/removing workspaces)
> All of these operations are not bound to a path (like e.g. removing an item 
> or creating a new version for a given node) but instead take global effect on 
> the whole JCR repository... that's why permissions for these operations 
> cannot be granted at a given path.
> In the default authorization model shipped with Jackrabbit and Oak the -null- 
> path access control policy is stored with a dedicated _rep:repoPolicy_ node 
> located with the root node and 
> For service user definitions we need to be able to define entries for the 
> -null- path policy for the reasons explained above. Thanks for extending the 
> repo-init accordingly.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-6423) Allow for specifying ACL merge mode (ACHandling) in repoinit

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-6423:


Thanks for your analysis Tim, I'm strongly in favor of using the same merging 
logic code between FileVault and repoinit.

> Allow for specifying ACL merge mode (ACHandling) in repoinit
> 
>
> Key: SLING-6423
> URL: https://issues.apache.org/jira/browse/SLING-6423
> Project: Sling
>  Issue Type: New Feature
>  Components: Repoinit
>Reporter: Nitin Nizhawan
>Assignee: Timothee Maret
> Fix For: Repoinit Parser 1.1.2
>
> Attachments: SLING-6423_parser_changes.patch, 
> SLING-6423_testcases.patch, SLING_6423_testcasesV2.patch
>
>
> Repoinit by default just add new ACLs if they are not already present.
> By contract package manager provides various strategies for ACL merging
> Extend repoinit to allow specifying these strategies 
> https://jackrabbit.apache.org/filevault/apidocs/org/apache/jackrabbit/vault/fs/io/AccessControlHandling.html#MERGE



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (SLING-7074) RRD4J NPE on removing all "Data sources" from config

[Marcel Reutegger (JIRA)]

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

Marcel Reutegger edited comment on SLING-7074 at 8/24/17 12:25 PM:
---

Looks very good to me.

Regarding the path. IIUC the activate would throw an exception if I remove the 
path configuration entry. What do you think about a fallback to the default 
path in that case?

Btw, the title for this issue should probably be changed as well. This isn't 
just about data sources after all.


was (Author: mreutegg):
Looks very good to me.

Regarding the path. IIUC the activate would throw an exception if I remove the 
path configuration entry. What do you think about a fallback to the default 
path in that case?

> RRD4J NPE on removing all "Data sources" from config
> 
>
> Key: SLING-7074
> URL: https://issues.apache.org/jira/browse/SLING-7074
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Reporter: Alex Deparvu
>Priority: Minor
> Fix For: Commons Metrics RRD4J 1.0.0
>
> Attachments: SLING-7074.patch
>
>
> Opened the config manager and deleted all entries
> {noformat}
>   *ERROR* [CM Event Dispatcher (Fire ConfigurationEvent: 
> pid=org.apache.sling.commons.metrics.rrd4j.impl.CodahaleMetricsReporter)] 
> org.apache.sling.commons.metrics-rrd4j 
> [org.apache.sling.commons.metrics.rrd4j.impl.CodahaleMetricsReporter(3134)] 
> The activate method has thrown an exception (java.lang.NullPointerException)
> java.lang.NullPointerException: null
> at 
> org.apache.sling.commons.metrics.rrd4j.impl.RRD4JReporter$Builder.withDatasources(RRD4JReporter.java:91)
> at 
> org.apache.sling.commons.metrics.rrd4j.impl.CodahaleMetricsReporter.activate(CodahaleMetricsReporter.java:143)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> {noformat}
> fyi [~mreutegg]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-7074) RRD4J NPE on removing all "Data sources" from config

[Marcel Reutegger (JIRA)]

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

Marcel Reutegger commented on SLING-7074:
-

Looks very good to me.

Regarding the path. IIUC the activate would throw an exception if I remove the 
path configuration entry. What do you think about a fallback to the default 
path in that case?

> RRD4J NPE on removing all "Data sources" from config
> 
>
> Key: SLING-7074
> URL: https://issues.apache.org/jira/browse/SLING-7074
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Reporter: Alex Deparvu
>Priority: Minor
> Fix For: Commons Metrics RRD4J 1.0.0
>
> Attachments: SLING-7074.patch
>
>
> Opened the config manager and deleted all entries
> {noformat}
>   *ERROR* [CM Event Dispatcher (Fire ConfigurationEvent: 
> pid=org.apache.sling.commons.metrics.rrd4j.impl.CodahaleMetricsReporter)] 
> org.apache.sling.commons.metrics-rrd4j 
> [org.apache.sling.commons.metrics.rrd4j.impl.CodahaleMetricsReporter(3134)] 
> The activate method has thrown an exception (java.lang.NullPointerException)
> java.lang.NullPointerException: null
> at 
> org.apache.sling.commons.metrics.rrd4j.impl.RRD4JReporter$Builder.withDatasources(RRD4JReporter.java:91)
> at 
> org.apache.sling.commons.metrics.rrd4j.impl.CodahaleMetricsReporter.activate(CodahaleMetricsReporter.java:143)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> {noformat}
> fyi [~mreutegg]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-6423) Allow for specifying ACL merge mode (ACHandling) in repoinit

[Timothee Maret (JIRA)]

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

Timothee Maret commented on SLING-6423:
---

I look at this issue and if we generalize it, it is about supporting the 
FileVault AccessControlHandling.
The AccessControlHandling does not only cover MERGE, it also has plenty of 
other modes that will likely be required at some point (CLEAR, IGNORE, 
MERGE_PRESERVE and OVERWRITE).

Ideally, we don't re-implement those behaviour in Sling repoinit, and instead 
keep the same logic in one place, in FileVault.

This would imply that I. we add a new dependency to the vault bundles in the 
{{org.apache.sling.jcr.repoinit}} bundle and II. that the FileVault code may 
need to be adapted to allow merging either documents (the XML representation of 
nodes AFAIU) or regular nodes.

[~tripod] I am not that familiar with the FileVault code, but would it already 
be possible to apply the merge logic between regular JCR nodes ? If not, would 
it make sense to you to try factoring out the code to allow that ?

> Allow for specifying ACL merge mode (ACHandling) in repoinit
> 
>
> Key: SLING-6423
> URL: https://issues.apache.org/jira/browse/SLING-6423
> Project: Sling
>  Issue Type: New Feature
>  Components: Repoinit
>Reporter: Nitin Nizhawan
>Assignee: Timothee Maret
> Fix For: Repoinit Parser 1.1.2
>
> Attachments: SLING-6423_parser_changes.patch, 
> SLING-6423_testcases.patch, SLING_6423_testcasesV2.patch
>
>
> Repoinit by default just add new ACLs if they are not already present.
> By contract package manager provides various strategies for ACL merging
> Extend repoinit to allow specifying these strategies 
> https://jackrabbit.apache.org/filevault/apidocs/org/apache/jackrabbit/vault/fs/io/AccessControlHandling.html#MERGE



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

RE: [VOTE] Release Apache Sling Servlets Resolver 2.4.14

[Stefan Seifert]

+1 

Re: [RT] Drop port 8888?

[Bertrand Delacretaz]

On Thu, Aug 24, 2017 at 1:19 PM, Oliver Lietz  wrote:
> Why not use dynamic ports when running tests?..

I agree that's best and as Robert says we're doing that in most places.

However we do have a default port for launchpad etc. and the problem
is that we currently have two default values - a single one would be
better.

-Bertrand

[jira] [Created] (SLING-7084) Coverage report is not generated correctly for HTL modules

[Radu Cotescu (JIRA)]

Radu Cotescu created SLING-7084:
---

 Summary: Coverage report is not generated correctly for HTL modules
 Key: SLING-7084
 URL: https://issues.apache.org/jira/browse/SLING-7084
 Project: Sling
  Issue Type: Bug
  Components: Scripting
Reporter: Radu Cotescu
Assignee: Radu Cotescu


Due to SLING-7083 the code coverage report built by the Apache Sling Scripting 
HTL Integration Tests module is not generated correctly, being either 
incomplete or inexistent (if the jacoco agent hasn't managed to write anything 
into the {{jacoco-it.exec}} file before the {{verify}} phase is started.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [RT] Drop port 8888?

[Robert Munteanu]

On Thu, 2017-08-24 at 13:19 +0200, Oliver Lietz wrote:
> I guess  was chosen to prevent clashes with other servers running
> on the 
> same machine and bound to 8080, e.g. Jenkins or regular Sling. Why
> not use 
> dynamic ports when running tests?

Integration tests are using dynamic ports as far as I know. So there
would be no clashes there.

Robert

[VOTE RESULT] Release Apache Sling Scripting JSP 2.3.2

[Carsten Ziegeler]

The vote passes with five binding +1 votes.

Thanks everyone

 Carsten

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

[jira] [Closed] (SLING-7044) Scripted tag files are not found

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler closed SLING-7044.
---

> Scripted tag files are not found
> 
>
> Key: SLING-7044
> URL: https://issues.apache.org/jira/browse/SLING-7044
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting JSP 2.3.0
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Scripting JSP 2.3.2
>
> Attachments: org.apache.sling.its.scripting.jsp.tar.gz
>
>
> If a taglib in a bundle references a tag implemented as a script (located in 
> /META-INF/tags) this script is not found as it is not searched within the 
> bundle containing the tld - it's rather used as a resource on the classpath.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [RT] Drop port 8888?

[Oliver Lietz]

On Thursday 24 August 2017 11:19:23 Robert Munteanu wrote:
> Hi,

Hi,

> We are using two main ports when dealing with Sling:
> 
> - 8080 for 'regular' instances
> -  for 'testing' instances - mainly used in the integration tests
> 
> I usually notice this when I want to try running an IT from my IDE
> against a running Sling instance and it times out looking for something
> on port  .
> 
> I am not familiar with the reasons for using port , but would it be
> worth dropping this port and using 8080 from now on? It would IMO make
> development with Sling simpler.
> 
> The changes would be quite localised:
> 
> - code change in
> bundles/commons/testing/src/main/java/org/apache/sling/commons/testing/
> integration/HttpTestBase.java
> - documentation changes in launchpad and contrib/launchpad
> 
> Thoughts?

I guess  was chosen to prevent clashes with other servers running on the 
same machine and bound to 8080, e.g. Jenkins or regular Sling. Why not use 
dynamic ports when running tests?

Regards,
O.

> Robert

[jira] [Commented] (SLING-7072) Build failure with Java 9 - unable to create javax script engine for javascript

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-7072:


A fix will require using Maven 3.5.1 or newer, so once that is out we need to 
ask infra to install it, upgrade our jobs and only then add testing jobs for 
Java 9.

> Build failure with Java 9 - unable to create javax script engine for 
> javascript
> ---
>
> Key: SLING-7072
> URL: https://issues.apache.org/jira/browse/SLING-7072
> Project: Sling
>  Issue Type: Bug
>  Components: General
>Reporter: Robert Munteanu
> Fix For: Parent 32
>
>
> {noformat}[ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-antrun-plugin:1.8:run 
> (set-bundle-required-execution-environment) on project 
> org.apache.sling.engine: An Ant BuildException has occured: Unable to create 
> javax script engine for javascript
> [ERROR] around Ant part 

[jira] [Comment Edited] (SLING-7083) The StopMojo should block until the process is finished

[Radu Cotescu (JIRA)]

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

Radu Cotescu edited comment on SLING-7083 at 8/24/17 11:02 AM:
---

Fixed in [r1806025|https://svn.apache.org/r1806025]. [~cziegeler], could you 
please review the fix?


was (Author: radu.cotescu):
Fixed in [r1806025|https://svn.apache.org/r1806025].

> The StopMojo should block until the process is finished
> ---
>
> Key: SLING-7083
> URL: https://issues.apache.org/jira/browse/SLING-7083
> Project: Sling
>  Issue Type: Bug
>  Components: Tooling
>Affects Versions: Slingstart Maven Plugin 1.1.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Slingstart Maven Plugin 1.7.8
>
>
> Currently the {{StopMojo}} blocks with a timeout only if the instance 
> provides a control port and the stop command is sent to this socket.
> However, if the mojo has to terminate the instance process by itself then it 
> just sends the terminate command without waiting for the process to actually 
> finish. Without blocking, the {{verify}} Maven lifecycle phase will start, 
> although processing of tasks started in the {{post-integration-test}} phase 
> might not have finished.
> One of the potential side-effects of this bug is the inability to properly 
> collect code coverage results with the {{jacoco-maven-plugin}}, because the 
> plugin will start reading the {{*.exec}} file before its agent (usually 
> attached to a Sling instance started by the {{StartMojo}}) had a chance to 
> flush the coverage contents.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (SLING-3224) GetAclTest integration test fails due to incorrect privilege expansion in AbstractGetAclServlet

[Robert Munteanu (JIRA)]

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

Robert Munteanu updated SLING-3224:
---
Summary: GetAclTest integration test fails due to incorrect privilege 
expansion in AbstractGetAclServlet  (was: GetAclTest integration test fails on 
Oak)

> GetAclTest integration test fails due to incorrect privilege expansion in 
> AbstractGetAclServlet
> ---
>
> Key: SLING-3224
> URL: https://issues.apache.org/jira/browse/SLING-3224
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Reporter: Bertrand Delacretaz
>Priority: Minor
>  Labels: sling-IT
>
> Failed tests:   testEffectiveAclMergeForUser_SubsetOfPrivilegesDeniedOnChild:
> Expected privilege jcr:modifyProperties to be NOT INCLUDED in supplied list: 
> [rep:userManagement, jcr:nodeTypeManagement, jcr:modifyProperties, 
> jcr:namespaceManagement, rep:privilegeManagement, jcr:workspaceManagement, 
> rep:readProperties, rep:alterProperties, jcr:nodeTypeDefinitionManagement, 
> jcr:lockManagement, jcr:read, jcr:lifecycleManagement, jcr:removeNode, 
> jcr:modifyAccessControl, jcr:removeChildNodes, jcr:versionManagement, 
> rep:addProperties, rep:removeProperties, rep:readNodes, 
> jcr:readAccessControl, jcr:addChildNodes, jcr:retentionManagement])



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (SLING-7083) The StopMojo should block until the process is finished

[Radu Cotescu (JIRA)]

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

Radu Cotescu resolved SLING-7083.
-
Resolution: Fixed

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

> The StopMojo should block until the process is finished
> ---
>
> Key: SLING-7083
> URL: https://issues.apache.org/jira/browse/SLING-7083
> Project: Sling
>  Issue Type: Bug
>  Components: Tooling
>Affects Versions: Slingstart Maven Plugin 1.1.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Slingstart Maven Plugin 1.7.8
>
>
> Currently the {{StopMojo}} blocks with a timeout only if the instance 
> provides a control port and the stop command is sent to this socket.
> However, if the mojo has to terminate the instance process by itself then it 
> just sends the terminate command without waiting for the process to actually 
> finish. Without blocking, the {{verify}} Maven lifecycle phase will start, 
> although processing of tasks started in the {{post-integration-test}} phase 
> might not have finished.
> One of the potential side-effects of this bug is the inability to properly 
> collect code coverage results with the {{jacoco-maven-plugin}}, because the 
> plugin will start reading the {{*.exec}} file before its agent (usually 
> attached to a Sling instance started by the {{StartMojo}}) had a chance to 
> flush the coverage contents.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-3224) GetAclTest integration test fails on Oak

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-3224:


Stepping through the code I can see that Oak returns the privileges correctly. 
However, in {{AbstractGetAclServlet.internalGetAcl}} , the 
{{mergePrivilegeSet}} invocation does not work properly. The call that fails is 
at line 181:

{code:java}
mergePrivilegeSets(privilege,
privilegeToAncestorMap,
deniedSet, grantedSet);
{code}

where privilege is {{jcr:write}, deniedSet is empty and grantedSet is 
{{jcr:all}}.

The logic is quite involved but I guess expansion of aggregate privileges is 
broken here.

> GetAclTest integration test fails on Oak
> 
>
> Key: SLING-3224
> URL: https://issues.apache.org/jira/browse/SLING-3224
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Reporter: Bertrand Delacretaz
>Priority: Minor
>  Labels: sling-IT
>
> Failed tests:   testEffectiveAclMergeForUser_SubsetOfPrivilegesDeniedOnChild:
> Expected privilege jcr:modifyProperties to be NOT INCLUDED in supplied list: 
> [rep:userManagement, jcr:nodeTypeManagement, jcr:modifyProperties, 
> jcr:namespaceManagement, rep:privilegeManagement, jcr:workspaceManagement, 
> rep:readProperties, rep:alterProperties, jcr:nodeTypeDefinitionManagement, 
> jcr:lockManagement, jcr:read, jcr:lifecycleManagement, jcr:removeNode, 
> jcr:modifyAccessControl, jcr:removeChildNodes, jcr:versionManagement, 
> rep:addProperties, rep:removeProperties, rep:readNodes, 
> jcr:readAccessControl, jcr:addChildNodes, jcr:retentionManagement])



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-7012) Pipes miss some integration tests

[Oliver Lietz (JIRA)]

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

Oliver Lietz commented on SLING-7012:
-

[~npeltier], Sling Distribution is somehow *not* optional.

I did some housekeeping before addressing integration testing (we switched to 
Commons Lang 3 in several modules).

> Pipes miss some integration tests
> -
>
> Key: SLING-7012
> URL: https://issues.apache.org/jira/browse/SLING-7012
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Nicolas Peltier
> Fix For: Pipes 1.0.4
>
>
> As pipes depend so much on sling components that can't easily be tested in UT 
> (xpath, true repo operations, ...), some IT would be nice



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (SLING-7083) The StopMojo should block until the process is finished

[Radu Cotescu (JIRA)]

Radu Cotescu created SLING-7083:
---

 Summary: The StopMojo should block until the process is finished
 Key: SLING-7083
 URL: https://issues.apache.org/jira/browse/SLING-7083
 Project: Sling
  Issue Type: Bug
  Components: Tooling
Affects Versions: Slingstart Maven Plugin 1.1.0
Reporter: Radu Cotescu
Assignee: Radu Cotescu
 Fix For: Slingstart Maven Plugin 1.7.8


Currently the {{StopMojo}} blocks with a timeout only if the instance provides 
a control port and the stop command is sent to this socket.

However, if the mojo has to terminate the instance process by itself then it 
just sends the terminate command without waiting for the process to actually 
finish. Without blocking, the {{verify}} Maven lifecycle phase will start, 
although processing of tasks started in the {{post-integration-test}} phase 
might not have finished.

One of the potential side-effects of this bug is the inability to properly 
collect code coverage results with the {{jacoco-maven-plugin}}, because the 
plugin will start reading the {{*.exec}} file before its agent (usually 
attached to a Sling instance started by the {{StartMojo}}) had a chance to 
flush the coverage contents.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [RT] Drop port 8888?

[Bertrand Delacretaz]

On Thu, Aug 24, 2017 at 11:19 AM, Robert Munteanu  wrote:
> ...I am not familiar with the reasons for using port , but would it be
> worth dropping this port and using 8080 from now on?...

+1 for using a single port throughout.

I see a few more occurences than you mention but nothing major, see below.

-Bertrand

./contrib/launchpad/testing/pom.xml:

./contrib/launchpad/testing/README.txt:with mvn jetty:run, from
http://localhost:/system/console/vmstat. ***
./launchpad/builder/README.txt:http://localhost:
./launchpad/integration-tests/src/main/java/org/apache/sling/launchpad/webapp/integrationtest/JsonRenderingTest.java:
 // We skip
http://localhost:/org.apache.sling.launchpad.testing-6-SNAPSHOT/
./launchpad/integration-tests/src/main/java/org/apache/sling/launchpad/webapp/integrationtest/JsonRenderingTest.java:
 // or http://localhost:/
./samples/installing-dependencies/pom.xml:
http://localhost:/system/console
./testing/tools/src/main/java/org/apache/sling/testing/tools/junit/RemoteLogDumper.java:
   baseUrl = "http://localhost:;;

[jira] [Commented] (SLING-7012) Pipes miss some integration tests

[Nicolas Peltier (JIRA)]

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

Nicolas Peltier commented on SLING-7012:


[~olli] awesome, thanks! how did you get them to run at all? Is it the 
commons.lang dep you fixed?

> Pipes miss some integration tests
> -
>
> Key: SLING-7012
> URL: https://issues.apache.org/jira/browse/SLING-7012
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Nicolas Peltier
> Fix For: Pipes 1.0.4
>
>
> As pipes depend so much on sling components that can't easily be tested in UT 
> (xpath, true repo operations, ...), some IT would be nice



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-7012) Pipes miss some integration tests

[Oliver Lietz (JIRA)]

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

Oliver Lietz commented on SLING-7012:
-

[~npeltier], please have a look: [r1806016|https://svn.apache.org/r1806016]

> Pipes miss some integration tests
> -
>
> Key: SLING-7012
> URL: https://issues.apache.org/jira/browse/SLING-7012
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Nicolas Peltier
> Fix For: Pipes 1.0.4
>
>
> As pipes depend so much on sling components that can't easily be tested in UT 
> (xpath, true repo operations, ...), some IT would be nice



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (SLING-7012) Pipes miss some integration tests

[Oliver Lietz (JIRA)]

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

Oliver Lietz updated SLING-7012:

Fix Version/s: Pipes 1.0.4

> Pipes miss some integration tests
> -
>
> Key: SLING-7012
> URL: https://issues.apache.org/jira/browse/SLING-7012
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Nicolas Peltier
> Fix For: Pipes 1.0.4
>
>
> As pipes depend so much on sling components that can't easily be tested in UT 
> (xpath, true repo operations, ...), some IT would be nice



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (SLING-7012) Pipes miss some integration tests

[Oliver Lietz (JIRA)]

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

Oliver Lietz updated SLING-7012:

Summary: Pipes miss some integration tests  (was: pipes miss some 
integration tests)

> Pipes miss some integration tests
> -
>
> Key: SLING-7012
> URL: https://issues.apache.org/jira/browse/SLING-7012
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Nicolas Peltier
>
> As pipes depend so much on sling components that can't easily be tested in UT 
> (xpath, true repo operations, ...), some IT would be nice



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[RT] Drop port 8888?

[Robert Munteanu]

Hi,

We are using two main ports when dealing with Sling:

- 8080 for 'regular' instances
-  for 'testing' instances - mainly used in the integration tests

I usually notice this when I want to try running an IT from my IDE
against a running Sling instance and it times out looking for something
on port  .

I am not familiar with the reasons for using port , but would it be
worth dropping this port and using 8080 from now on? It would IMO make
development with Sling simpler.

The changes would be quite localised:

- code change in
bundles/commons/testing/src/main/java/org/apache/sling/commons/testing/
integration/HttpTestBase.java
- documentation changes in launchpad and contrib/launchpad

Thoughts?

Robert

[jira] [Commented] (SLING-3224) GetAclTest integration test fails on Oak

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-3224:


I am not sure that this is an error in Oak. Failing to find an actual test for 
this scenario, I wrote one which passes:

{noformat}diff --git 
a/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/security/authorization/ChildNodePermissionsTest.java
 
b/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/security/authorization/ChildNodePermissionsTest.java
new file mode 100644
index 00..18b64026c2
--- /dev/null
+++ 
b/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/security/authorization/ChildNodePermissionsTest.java
@@ -0,0 +1,38 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.jackrabbit.oak.jcr.security.authorization;
+
+import javax.jcr.Node;
+import javax.jcr.security.Privilege;
+
+import org.junit.Test;
+
+public class ChildNodePermissionsTest extends AbstractEvaluationTest {
+
+@Test
+public void testChildNodeDeniedJcrWrite() throws Exception {
+
+Node n = superuser.getNode(path);
+Node child = n.addNode("child");
+
+allow(n.getPath(), privilegesFromName(Privilege.JCR_ALL));
+deny(child.getPath(), privilegesFromName(Privilege.JCR_WRITE));
+
+assertHasPrivilege(child.getPath(), Privilege.JCR_MODIFY_PROPERTIES, 
false);
+}
+}
{noformat}

> GetAclTest integration test fails on Oak
> 
>
> Key: SLING-3224
> URL: https://issues.apache.org/jira/browse/SLING-3224
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Reporter: Bertrand Delacretaz
>Priority: Minor
>  Labels: sling-IT
>
> Failed tests:   testEffectiveAclMergeForUser_SubsetOfPrivilegesDeniedOnChild:
> Expected privilege jcr:modifyProperties to be NOT INCLUDED in supplied list: 
> [rep:userManagement, jcr:nodeTypeManagement, jcr:modifyProperties, 
> jcr:namespaceManagement, rep:privilegeManagement, jcr:workspaceManagement, 
> rep:readProperties, rep:alterProperties, jcr:nodeTypeDefinitionManagement, 
> jcr:lockManagement, jcr:read, jcr:lifecycleManagement, jcr:removeNode, 
> jcr:modifyAccessControl, jcr:removeChildNodes, jcr:versionManagement, 
> rep:addProperties, rep:removeProperties, rep:readNodes, 
> jcr:readAccessControl, jcr:addChildNodes, jcr:retentionManagement])



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (SLING-7074) RRD4J NPE on removing all "Data sources" from config

[Alex Deparvu (JIRA)]

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

Alex Deparvu updated SLING-7074:

Attachment: SLING-7074.patch

attaching proposed patch.
tried to fallback to defaults whenever possible. could not find a way to expose 
the archives, so this specific info is borderline useless (at least it shows 
the count). did not cover the path param at all in tests, but I'm willing to 
update the patch if this is needed.

Bonus, I added a debug log for value updates. This was there for a single value 
type but went away, I found it useful so I added it for all cases. If it's not 
interesting, I can remove it and update a new version of the patch.

[~mreutegg] how does this look to you?

> RRD4J NPE on removing all "Data sources" from config
> 
>
> Key: SLING-7074
> URL: https://issues.apache.org/jira/browse/SLING-7074
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Reporter: Alex Deparvu
>Priority: Minor
> Fix For: Commons Metrics RRD4J 1.0.0
>
> Attachments: SLING-7074.patch
>
>
> Opened the config manager and deleted all entries
> {noformat}
>   *ERROR* [CM Event Dispatcher (Fire ConfigurationEvent: 
> pid=org.apache.sling.commons.metrics.rrd4j.impl.CodahaleMetricsReporter)] 
> org.apache.sling.commons.metrics-rrd4j 
> [org.apache.sling.commons.metrics.rrd4j.impl.CodahaleMetricsReporter(3134)] 
> The activate method has thrown an exception (java.lang.NullPointerException)
> java.lang.NullPointerException: null
> at 
> org.apache.sling.commons.metrics.rrd4j.impl.RRD4JReporter$Builder.withDatasources(RRD4JReporter.java:91)
> at 
> org.apache.sling.commons.metrics.rrd4j.impl.CodahaleMetricsReporter.activate(CodahaleMetricsReporter.java:143)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> {noformat}
> fyi [~mreutegg]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (SLING-7082) Use Commons Lang 3

[Oliver Lietz (JIRA)]

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

Oliver Lietz resolved SLING-7082.
-
Resolution: Done

[r1806009|https://svn.apache.org/r1806009]

> Use Commons Lang 3
> --
>
> Key: SLING-7082
> URL: https://issues.apache.org/jira/browse/SLING-7082
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Pipes 1.0.4
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (SLING-7077) Reduce size of RRD4J metrics reporter

[Robert Munteanu (JIRA)]

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

Robert Munteanu resolved SLING-7077.

Resolution: Fixed

Applied in [r1806010|https://svn.apache.org/r1806010], thanks [~mreutegg]!

> Reduce size of RRD4J metrics reporter
> -
>
> Key: SLING-7077
> URL: https://issues.apache.org/jira/browse/SLING-7077
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Reporter: Marcel Reutegger
>Assignee: Robert Munteanu
>Priority: Minor
> Fix For: Commons Metrics RRD4J 1.0.0
>
> Attachments: SLING-7077.patch
>
>
> The RRD4J library contains graph functionality and fonts not needed by the 
> reporter. These should be excluded from the bundle. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (SLING-7077) Reduce size of RRD4J metrics reporter

[Robert Munteanu (JIRA)]

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

Robert Munteanu reassigned SLING-7077:
--

Assignee: Robert Munteanu

> Reduce size of RRD4J metrics reporter
> -
>
> Key: SLING-7077
> URL: https://issues.apache.org/jira/browse/SLING-7077
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Reporter: Marcel Reutegger
>Assignee: Robert Munteanu
>Priority: Minor
> Fix For: Commons Metrics RRD4J 1.0.0
>
> Attachments: SLING-7077.patch
>
>
> The RRD4J library contains graph functionality and fonts not needed by the 
> reporter. These should be excluded from the bundle. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (SLING-7082) Use Commons Lang 3

[Oliver Lietz (JIRA)]

Oliver Lietz created SLING-7082:
---

 Summary: Use Commons Lang 3
 Key: SLING-7082
 URL: https://issues.apache.org/jira/browse/SLING-7082
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Oliver Lietz
Assignee: Oliver Lietz
 Fix For: Pipes 1.0.4






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] Release Apache Sling Servlets Resolver 2.4.14

[Carsten Ziegeler]

+1

 

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

[VOTE] Release Apache Sling Servlets Resolver 2.4.14

[Carsten Ziegeler]

Hi,

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


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

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 1774 /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
Carsten
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: [VOTE] Release Apache Sling Scripting JSP 2.3.2

[Oliver Lietz]

On Monday 21 August 2017 11:47:56 Carsten Ziegeler wrote:
> Hi,
> 
> We solved 1 issues in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12340247

+1

O.

[jira] [Commented] (SLING-7074) RRD4J NPE on removing all "Data sources" from config

[Marcel Reutegger (JIRA)]

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

Marcel Reutegger commented on SLING-7074:
-

I agree, it would be nice if there was some validation possible with the config 
manager. My preference is fallback to default values whenever possible and 
server side validation before values are passed to RRD4J. I would probably 
still start the reporter even if some values are malformed. E.g. when there is 
a syntax error in a datasource or archive definition. We could just ignore that 
entry and log an error or warning. A check on the datasources is already 
implemented. Something similar could be done with the archive definitions.

> RRD4J NPE on removing all "Data sources" from config
> 
>
> Key: SLING-7074
> URL: https://issues.apache.org/jira/browse/SLING-7074
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Reporter: Alex Deparvu
>Priority: Minor
> Fix For: Commons Metrics RRD4J 1.0.0
>
>
> Opened the config manager and deleted all entries
> {noformat}
>   *ERROR* [CM Event Dispatcher (Fire ConfigurationEvent: 
> pid=org.apache.sling.commons.metrics.rrd4j.impl.CodahaleMetricsReporter)] 
> org.apache.sling.commons.metrics-rrd4j 
> [org.apache.sling.commons.metrics.rrd4j.impl.CodahaleMetricsReporter(3134)] 
> The activate method has thrown an exception (java.lang.NullPointerException)
> java.lang.NullPointerException: null
> at 
> org.apache.sling.commons.metrics.rrd4j.impl.RRD4JReporter$Builder.withDatasources(RRD4JReporter.java:91)
> at 
> org.apache.sling.commons.metrics.rrd4j.impl.CodahaleMetricsReporter.activate(CodahaleMetricsReporter.java:143)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> {noformat}
> fyi [~mreutegg]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] Release Apache Sling Models API 1.3.6, Implementation 1.4.4 and Jackson Exporter 1.0.8

[Carsten Ziegeler]

+1

 

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