[jira] [Updated] (SLING-6431) Move RemoteLogDumper to org.apache.sling.testing.rules module

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra updated SLING-6431:
---
Assignee: Andrei Dulvac  (was: Chetan Mehrotra)

> Move RemoteLogDumper to org.apache.sling.testing.rules module
> -
>
> Key: SLING-6431
> URL: https://issues.apache.org/jira/browse/SLING-6431
> Project: Sling
>  Issue Type: Task
>  Components: Testing
>Reporter: Chetan Mehrotra
>Assignee: Andrei Dulvac
> Fix For: Apache Sling Testing Rules 1.0.2
>
>
> {{RemoteLogDumper}} is currently part of {{org.apache.sling.testing.tools}} 
> module. We should add a copy (or move) this class to 
> {{org.apache.sling.testing.rules}} module as that is holding all other rules



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

[jira] [Commented] (SLING-6431) Move RemoteLogDumper to org.apache.sling.testing.rules module

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra commented on SLING-6431:


Done initial commit in 1777452. keeping it open as [~andrei.dulvac] plans to do 
some further changes

> Move RemoteLogDumper to org.apache.sling.testing.rules module
> -
>
> Key: SLING-6431
> URL: https://issues.apache.org/jira/browse/SLING-6431
> Project: Sling
>  Issue Type: Task
>  Components: Testing
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: Apache Sling Testing Rules 1.0.2
>
>
> {{RemoteLogDumper}} is currently part of {{org.apache.sling.testing.tools}} 
> module. We should add a copy (or move) this class to 
> {{org.apache.sling.testing.rules}} module as that is holding all other rules



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

[jira] [Commented] (SLING-6439) Filesystem Resource Provider does not support "overlaying" nodes from repository

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6439:
-

[~sseif...@pro-vision.de] I've implemented the missing piece in rev 1777534, 
could you please give it a try?

> Filesystem Resource Provider does not support "overlaying" nodes from 
> repository
> 
>
> Key: SLING-6439
> URL: https://issues.apache.org/jira/browse/SLING-6439
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: File System Resource Provider 1.2.2
>Reporter: Stefan Seifert
>Assignee: Carsten Ziegeler
> Fix For: File System Resource Provider 1.2.2
>
>
> the file system resource provider does no longer provide "overlaying" 
> resources from the repository with resources from the filesystem. this worked 
> with the old version 1.1.4 and was a much-used feature when mounting an maven 
> project with content including JSON file fragements via sling content 
> installer. in this case the bundle had to be deployed once and all binary 
> files and content resources extracted. then, when the fsresource folder is 
> mounted, the binary files are served from filesystem while the nodes from the 
> JSON fragment files are still services from the repository.
> this does no longer work with the latest fsresource provider 1.2.0. perhaps 
> the underlying issue is not the fsresource implementation, but the new sling 
> resource provider SPI implementation.
> here is a sample project to reproduce the problem:
> https://github.com/stefanseifert/sling-fsresource-include-test
> follow the steps in the readme to reproduce the problem.
> in this branch - the only change is a switch to sling launchpad 8 and 
> fsresource 1.1.4 - the problem does not occur:
> https://github.com/stefanseifert/sling-fsresource-include-test/tree/fsresource-1.x



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

[jira] [Updated] (SLING-6439) Filesystem Resource Provider does not support "overlaying" nodes from repository

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-6439:

Summary: Filesystem Resource Provider does not support "overlaying" nodes 
from repository  (was: Filesystem Resource Provider 1.2 does not support 
"overlaying" nodes from repository)

> Filesystem Resource Provider does not support "overlaying" nodes from 
> repository
> 
>
> Key: SLING-6439
> URL: https://issues.apache.org/jira/browse/SLING-6439
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: File System Resource Provider 1.2.2
>Reporter: Stefan Seifert
>Assignee: Carsten Ziegeler
> Fix For: File System Resource Provider 1.2.2
>
>
> the file system resource provider does no longer provide "overlaying" 
> resources from the repository with resources from the filesystem. this worked 
> with the old version 1.1.4 and was a much-used feature when mounting an maven 
> project with content including JSON file fragements via sling content 
> installer. in this case the bundle had to be deployed once and all binary 
> files and content resources extracted. then, when the fsresource folder is 
> mounted, the binary files are served from filesystem while the nodes from the 
> JSON fragment files are still services from the repository.
> this does no longer work with the latest fsresource provider 1.2.0. perhaps 
> the underlying issue is not the fsresource implementation, but the new sling 
> resource provider SPI implementation.
> here is a sample project to reproduce the problem:
> https://github.com/stefanseifert/sling-fsresource-include-test
> follow the steps in the readme to reproduce the problem.
> in this branch - the only change is a switch to sling launchpad 8 and 
> fsresource 1.1.4 - the problem does not occur:
> https://github.com/stefanseifert/sling-fsresource-include-test/tree/fsresource-1.x



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

[jira] [Assigned] (SLING-6439) Filesystem Resource Provider 1.2 does not support "overlaying" nodes from repository

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler reassigned SLING-6439:
---

Assignee: Carsten Ziegeler  (was: Stefan Seifert)

> Filesystem Resource Provider 1.2 does not support "overlaying" nodes from 
> repository
> 
>
> Key: SLING-6439
> URL: https://issues.apache.org/jira/browse/SLING-6439
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: File System Resource Provider 1.2.2
>Reporter: Stefan Seifert
>Assignee: Carsten Ziegeler
> Fix For: File System Resource Provider 1.2.2
>
>
> the file system resource provider does no longer provide "overlaying" 
> resources from the repository with resources from the filesystem. this worked 
> with the old version 1.1.4 and was a much-used feature when mounting an maven 
> project with content including JSON file fragements via sling content 
> installer. in this case the bundle had to be deployed once and all binary 
> files and content resources extracted. then, when the fsresource folder is 
> mounted, the binary files are served from filesystem while the nodes from the 
> JSON fragment files are still services from the repository.
> this does no longer work with the latest fsresource provider 1.2.0. perhaps 
> the underlying issue is not the fsresource implementation, but the new sling 
> resource provider SPI implementation.
> here is a sample project to reproduce the problem:
> https://github.com/stefanseifert/sling-fsresource-include-test
> follow the steps in the readme to reproduce the problem.
> in this branch - the only change is a switch to sling launchpad 8 and 
> fsresource 1.1.4 - the problem does not occur:
> https://github.com/stefanseifert/sling-fsresource-include-test/tree/fsresource-1.x



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

[jira] [Updated] (SLING-6439) Filesystem Resource Provider 1.2 does not support "overlaying" nodes from repository

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-6439:

Fix Version/s: File System Resource Provider 1.2.2

> Filesystem Resource Provider 1.2 does not support "overlaying" nodes from 
> repository
> 
>
> Key: SLING-6439
> URL: https://issues.apache.org/jira/browse/SLING-6439
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: File System Resource Provider 1.2.2
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
> Fix For: File System Resource Provider 1.2.2
>
>
> the file system resource provider does no longer provide "overlaying" 
> resources from the repository with resources from the filesystem. this worked 
> with the old version 1.1.4 and was a much-used feature when mounting an maven 
> project with content including JSON file fragements via sling content 
> installer. in this case the bundle had to be deployed once and all binary 
> files and content resources extracted. then, when the fsresource folder is 
> mounted, the binary files are served from filesystem while the nodes from the 
> JSON fragment files are still services from the repository.
> this does no longer work with the latest fsresource provider 1.2.0. perhaps 
> the underlying issue is not the fsresource implementation, but the new sling 
> resource provider SPI implementation.
> here is a sample project to reproduce the problem:
> https://github.com/stefanseifert/sling-fsresource-include-test
> follow the steps in the readme to reproduce the problem.
> in this branch - the only change is a switch to sling launchpad 8 and 
> fsresource 1.1.4 - the problem does not occur:
> https://github.com/stefanseifert/sling-fsresource-include-test/tree/fsresource-1.x



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

[jira] [Commented] (SLING-6439) Filesystem Resource Provider 1.2 does not support "overlaying" nodes from repository

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6439:
-

[~sseif...@pro-vision.de] This is due to a change in how resource providers are 
handled with the SPI - they always own the whole subtree. If a provider wants 
to delegate to the shadowed provider it has to use the ResolveContext. I 
actually forgot to implement that part in the filesystem resource provider :(

> Filesystem Resource Provider 1.2 does not support "overlaying" nodes from 
> repository
> 
>
> Key: SLING-6439
> URL: https://issues.apache.org/jira/browse/SLING-6439
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: File System Resource Provider 1.2.2
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>
> the file system resource provider does no longer provide "overlaying" 
> resources from the repository with resources from the filesystem. this worked 
> with the old version 1.1.4 and was a much-used feature when mounting an maven 
> project with content including JSON file fragements via sling content 
> installer. in this case the bundle had to be deployed once and all binary 
> files and content resources extracted. then, when the fsresource folder is 
> mounted, the binary files are served from filesystem while the nodes from the 
> JSON fragment files are still services from the repository.
> this does no longer work with the latest fsresource provider 1.2.0. perhaps 
> the underlying issue is not the fsresource implementation, but the new sling 
> resource provider SPI implementation.
> here is a sample project to reproduce the problem:
> https://github.com/stefanseifert/sling-fsresource-include-test
> follow the steps in the readme to reproduce the problem.
> in this branch - the only change is a switch to sling launchpad 8 and 
> fsresource 1.1.4 - the problem does not occur:
> https://github.com/stefanseifert/sling-fsresource-include-test/tree/fsresource-1.x



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

[VOTE CANCELLED] Release Apache Sling File System Resource 1.2.0

[Carsten Ziegeler]

I hereby cancel the vote due to the problems found by Stefan

 Regards

Carsten

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

RE: [VOTE] Release Apache Sling File System Resource 1.2.0

[Stefan Seifert]

the release is technically fine, but i detected a major issue when using it as 
described in 
https://issues.apache.org/jira/browse/SLING-6439

i do not had the time to look deeper into it if this can be fixed within the 
fsresource provider, or if it is an issue in the underlying new resource 
provider SPI implementation (which then may affect other providers like [1] as 
well, have not tested it).

stefan

[1] https://github.com/apache/sling/tree/trunk/contrib/extensions/superimposing


>-Original Message-
>From: Carsten Ziegeler [mailto:cziege...@apache.org]
>Sent: Tuesday, January 3, 2017 10:15 AM
>To: Sling Developers
>Subject: [VOTE] Release Apache Sling File System Resource 1.2.0
>
>Hi,
>
>We solved 3 issues in this release:
>https://issues.apache.org/jira/browse/SLING/fixforversion/12328647
>
>Staging repository:
>https://repository.apache.org/content/repositories/orgapachesling-1615/
>
>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 1615 /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

[jira] [Commented] (SLING-6439) Filesystem Resource Provider 1.2 does not support "overlaying" nodes from repository

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-6439:
---

if the underlying issue is not in the fsresource provider and we do not want to 
support this somewhat hidden "overlaying feature" between multiple resource 
providers we may also implement the new feature SLING-6440 which would at least 
solve the problem described in this ticket in a clean way (and would provide 
much additional benefit as well).

> Filesystem Resource Provider 1.2 does not support "overlaying" nodes from 
> repository
> 
>
> Key: SLING-6439
> URL: https://issues.apache.org/jira/browse/SLING-6439
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: File System Resource Provider 1.2.0
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>
> the file system resource provider does no longer provide "overlaying" 
> resources from the repository with resources from the filesystem. this worked 
> with the old version 1.1.4 and was a much-used feature when mounting an maven 
> project with content including JSON file fragements via sling content 
> installer. in this case the bundle had to be deployed once and all binary 
> files and content resources extracted. then, when the fsresource folder is 
> mounted, the binary files are served from filesystem while the nodes from the 
> JSON fragment files are still services from the repository.
> this does no longer work with the latest fsresource provider 1.2.0. perhaps 
> the underlying issue is not the fsresource implementation, but the new sling 
> resource provider SPI implementation.
> here is a sample project to reproduce the problem:
> https://github.com/stefanseifert/sling-fsresource-include-test
> follow the steps in the readme to reproduce the problem.
> in this branch - the only change is a switch to sling launchpad 8 and 
> fsresource 1.1.4 - the problem does not occur:
> https://github.com/stefanseifert/sling-fsresource-include-test/tree/fsresource-1.x



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

[jira] [Created] (SLING-6440) Filesystem Resource Provider: Support "mounting" content resources from JSON and XML files

[Stefan Seifert (JIRA)]

Stefan Seifert created SLING-6440:
-

 Summary: Filesystem Resource Provider: Support "mounting" content 
resources from JSON and XML files
 Key: SLING-6440
 URL: https://issues.apache.org/jira/browse/SLING-6440
 Project: Sling
  Issue Type: New Feature
  Components: Extensions
Reporter: Stefan Seifert


it would be nice if the filesystem resource provider does not only support 
serving binary files and folders, but also arbitrary resources stored in .json 
files or .xml file vault files in the folder hierarchy which are normally 
extracted when installing the bundle with sling-initial-content.

is is necessary to explicitly switch this feature on per configuration, because 
it may be desired to directly serve the JSON and XML files as binary files in 
some cases.



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

[jira] [Created] (SLING-6439) Filesystem Resource Provider 1.2 does not support "overlaying" nodes from repository

[Stefan Seifert (JIRA)]

Stefan Seifert created SLING-6439:
-

 Summary: Filesystem Resource Provider 1.2 does not support 
"overlaying" nodes from repository
 Key: SLING-6439
 URL: https://issues.apache.org/jira/browse/SLING-6439
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: File System Resource Provider 1.2.0
Reporter: Stefan Seifert
Assignee: Stefan Seifert


the file system resource provider does no longer provide "overlaying" resources 
from the repository with resources from the filesystem. this worked with the 
old version 1.1.4 and was a much-used feature when mounting an maven project 
with content including JSON file fragements via sling content installer. in 
this case the bundle had to be deployed once and all binary files and content 
resources extracted. then, when the fsresource folder is mounted, the binary 
files are served from filesystem while the nodes from the JSON fragment files 
are still services from the repository.

this does no longer work with the latest fsresource provider 1.2.0. perhaps the 
underlying issue is not the fsresource implementation, but the new sling 
resource provider SPI implementation.

here is a sample project to reproduce the problem:
https://github.com/stefanseifert/sling-fsresource-include-test
follow the steps in the readme to reproduce the problem.

in this branch - the only change is a switch to sling launchpad 8 and 
fsresource 1.1.4 - the problem does not occur:
https://github.com/stefanseifert/sling-fsresource-include-test/tree/fsresource-1.x




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

[jira] [Created] (SLING-6438) Add encodeForHTMLAttrName() to XSSAPI

[Lars Krapf (JIRA)]

Lars Krapf created SLING-6438:
-

 Summary: Add encodeForHTMLAttrName() to XSSAPI
 Key: SLING-6438
 URL: https://issues.apache.org/jira/browse/SLING-6438
 Project: Sling
  Issue Type: Improvement
  Components: XSS Protection API
Affects Versions: XSS Protection API 1.0.16
Reporter: Lars Krapf


The XSSAPI currently does not provide a method to safely encode HTML attribute 
names. This could cause problems if for example attackers were allowed to 
define arbitrary "data-" attributes. I don't think Encoder already provides a 
context for that, but {{forHtmlUnquotedAttribute}} might just do the trick.



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

[jira] [Updated] (SLING-6393) Sling installer can duplicate factory configurations on opposite node if configuration is changed on local cluster node

[Elemer Kisch (JIRA)]

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

Elemer Kisch updated SLING-6393:

Description: 
Sling installer can duplicate factory configurations on opposite node if 
configuration is changed on local cluster node:

Reproducible on RDMBK-DB2 cluster environment.

{noformat}

06.12.2016 16:38:35.021 *INFO* [OsgiInstallerImpl] 
org.apache.sling.audit.osgi.installer Installed configuration 
org.apache.sling.commons.log.LogManager.factory.config.8af9a8a1-a3ad-4699-980d-6494aad6314e
 from resource 
TaskResource(url=jcrinstall:/apps/system/config/org.apache.sling.commons.log.LogManager.factory.config-audit.log.config,
 
entity=config:org.apache.sling.commons.log.LogManager.factory.config.audit.log, 
state=INSTALL, 
attributes=[org.apache.sling.installer.api.tasks.ResourceTransformer=:28:84:, 
service.factoryPid=org.apache.sling.commons.log.LogManager.factory.config, 
service.pid=audit.log], digest=562d244ccd03c4e8b208ec6e8488a131)
06.12.2016 16:46:56.140 *INFO* [JcrInstaller.1] 
org.apache.sling.installer.provider.jcr.impl.JcrInstaller Registering resource 
with OSGi installer: [InstallableResource, priority=200, 
id=/apps/system/config/org.apache.sling.commons.log.LogManager.factory.config-audit.log.config]
06.12.2016 16:46:56.176 *INFO* [OsgiInstallerImpl] 
org.apache.sling.audit.osgi.installer Installed configuration 
org.apache.sling.commons.log.LogManager.factory.config.8af9a8a1-a3ad-4699-980d-6494aad6314e
 from resource 
TaskResource(url=jcrinstall:/apps/system/config/org.apache.sling.commons.log.LogManager.factory.config-audit.log.config,
 
entity=config:org.apache.sling.commons.log.LogManager.factory.config.audit.log, 
state=INSTALL, 
attributes=[org.apache.sling.installer.api.tasks.ResourceTransformer=:28:84:, 
service.factoryPid=org.apache.sling.commons.log.LogManager.factory.config, 
service.pid=audit.log], digest=24ee5abae6a89146693d896e8376f046)
06.12.2016 16:48:55.674 *INFO* [JcrInstaller.1] 
org.apache.sling.installer.provider.jcr.impl.JcrInstaller Registering resource 
with OSGi installer: [InstallableResource, priority=200, 
id=/apps/system/config/org.apache.sling.commons.log.LogManager.config]
06.12.2016 16:48:55.715 *INFO* [OsgiInstallerImpl] 
org.apache.sling.audit.osgi.installer Installed configuration 
org.apache.sling.commons.log.LogManager from resource 
TaskResource(url=jcrinstall:/apps/system/config/org.apache.sling.commons.log.LogManager.config,
 entity=config:org.apache.sling.commons.log.LogManager, state=INSTALL, 
attributes=[org.apache.sling.installer.api.tasks.ResourceTransformer=:28:84:, 
service.pid=org.apache.sling.commons.log.LogManager], 
digest=ab4ea1c2827b4a27163236320694c81d)
06.12.2016 17:00:30.004 *INFO* [pool-11-thread-3] 
com.adobe.granite.taskmanagement.impl.jcr.TaskArchiveService archiving tasks 
at: 'Tue Dec 06 17:00:30 CET 2016'
{noformat}

{noformat}
Suse-001:/data/software/wlp/usr/servers/server1 # cd -
/data/software/wlp/usr/servers/server1/crx-quickstart/launchpad/config/org/apache/sling/commons/log/LogManager/factory/config
Suse-001:/data/software/wlp/usr/servers/server1/crx-quickstart/launchpad/config/org/apache/sling/commons/log/LogManager/factory/config
 # ls -lart
total 28
-rw-r--r-- 1 root root 377 Jun 11 2015 
8ab79cc1-780e-4f4d-b967-c95774fb2bcb.config
-rw-r--r-- 1 root root 375 Jun 11 2015 
31887166-1934-4f82-9420-0146bcb8d20c.config
-rw-r--r-- 1 root root 413 Jun 11 2015 
40697bf8-0ffc-47e9-b8f3-08a0d3b36511.config
-rw-r--r-- 1 root root 505 Jun 11 2015 
3ffce209-310b-448b-9d0b-b5d0ea33f1f2.config
drwxr-xr-x 4 root root 96 Jun 11 2015 ..
-rw-r--r-- 1 root root 435 Jun 11 2015 
36b4a289-61ee-4fc2-a71d-fa5445cb9b5d.config
-rw-r- 1 root root 653 Nov 11 15:32 factory.config
-rw-r- 1 root root 352 Dec 6 16:46 
8af9a8a1-a3ad-4699-980d-6494aad6314e.config
drwxr-xr-x 2 root root 464 Dec 6 16:46 .
{noformat}

Please have a look at the 16:46 occurrence. Just changing on the secondary 
cluster via OSGi Console, e.g. the audit.log log level from INFO to ERROR, you 
should get the same duplication.

For an environment to reproduce, please contact me.





  was:
Sling installer can duplicate factory configurations on opposite node if 
configuration is changed on local cluster node:

Reproducible on RDMBK-DB2 cluster environment.

{noformat}

06.12.2016 16:38:35.021 *INFO* [OsgiInstallerImpl] 
org.apache.sling.audit.osgi.installer Installed configuration 
org.apache.sling.commons.log.LogManager.factory.config.8af9a8a1-a3ad-4699-980d-6494aad6314e
 from resource 
TaskResource(url=jcrinstall:/apps/system/config/org.apache.sling.commons.log.LogManager.factory.config-audit.log.config,
 
entity=config:org.apache.sling.commons.log.LogManager.factory.config.audit.log, 
state=INSTALL, 
attributes=[org.apache.sling.installer.api.tasks.ResourceTransformer=:28:84:, 
service.factoryPid=org.apache.sling.commons.log.LogManager.factory.config, 

[jira] [Updated] (SLING-6422) Allow for specifying oak restrictions with repoinit

[Nitin Nizhawan (JIRA)]

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

Nitin Nizhawan updated SLING-6422:
--
Attachment: SLING-6422.patch

[~bdelacretaz] Attached patch for supporting restriction clause in repoinit as 
mentioned. Currently, it does not accept explicit type information but we can 
add that incrementally i.e. type hint can be optional. Please review and merge

> Allow for specifying oak restrictions with repoinit
> ---
>
> Key: SLING-6422
> URL: https://issues.apache.org/jira/browse/SLING-6422
> Project: Sling
>  Issue Type: New Feature
>  Components: Repoinit
>Reporter: Nitin Nizhawan
> Attachments: SLING-6422.patch
>
>
> Allow for specifying oak restrictions with repoinit. Currently repoinit 
> allows one to ADD remove ACLs but there is no way to specify oak restrictions.
> http://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html



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

[jira] [Commented] (SLING-6422) Allow for specifying oak restrictions with repoinit

[ASF GitHub Bot (JIRA)]

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

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

GitHub user nitin-nizhawan opened a pull request:

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

SLING-6422, Allow for specifying oak restrictions with repoinit

   - Add support for restriction clause in parser
   - example acl with restriction spec
 - set ACL on /libs
 deny jcr:modifyProperties for user2 
restriction(rep:itemNames,prop1,prop2)
   end
 - set ACL for user1,u2
 allow jcr:addChildNodes on /apps,/content 
restriction(rep:glob,/cat/*,*/cat,*cat/*)
   end

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

$ git pull https://github.com/nitin-nizhawan/sling 
nitin-nizhawan/restrictionsV3

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

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

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

This closes #195


commit d7ea9e1a33a34a170da427fa2638dfe813cafb75
Author: Nitin Nizhawan 
Date:   2017-01-05T14:00:26Z

SLING-6422, Allow for specifying oak restrictions with repoinit

   - Add support for restriction clause in parser
   - example acl with restriction spec
 - set ACL on /libs
 deny jcr:modifyProperties for user2 
restriction(rep:itemNames,prop1,prop2)
   end
 - set ACL for user1,u2
 allow jcr:addChildNodes on /apps,/content 
restriction(rep:glob,/cat/*,*/cat,*cat/*)
   end




> Allow for specifying oak restrictions with repoinit
> ---
>
> Key: SLING-6422
> URL: https://issues.apache.org/jira/browse/SLING-6422
> Project: Sling
>  Issue Type: New Feature
>  Components: Repoinit
>Reporter: Nitin Nizhawan
>
> Allow for specifying oak restrictions with repoinit. Currently repoinit 
> allows one to ADD remove ACLs but there is no way to specify oak restrictions.
> http://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html



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

[GitHub] sling pull request #195: SLING-6422, Allow for specifying oak restrictions w...

[nitin-nizhawan]

GitHub user nitin-nizhawan opened a pull request:

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

SLING-6422, Allow for specifying oak restrictions with repoinit

   - Add support for restriction clause in parser
   - example acl with restriction spec
 - set ACL on /libs
 deny jcr:modifyProperties for user2 
restriction(rep:itemNames,prop1,prop2)
   end
 - set ACL for user1,u2
 allow jcr:addChildNodes on /apps,/content 
restriction(rep:glob,/cat/*,*/cat,*cat/*)
   end

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

$ git pull https://github.com/nitin-nizhawan/sling 
nitin-nizhawan/restrictionsV3

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

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

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

This closes #195


commit d7ea9e1a33a34a170da427fa2638dfe813cafb75
Author: Nitin Nizhawan 
Date:   2017-01-05T14:00:26Z

SLING-6422, Allow for specifying oak restrictions with repoinit

   - Add support for restriction clause in parser
   - example acl with restriction spec
 - set ACL on /libs
 deny jcr:modifyProperties for user2 
restriction(rep:itemNames,prop1,prop2)
   end
 - set ACL for user1,u2
 allow jcr:addChildNodes on /apps,/content 
restriction(rep:glob,/cat/*,*/cat,*cat/*)
   end




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

[jira] [Resolved] (SLING-6406) TestLogServlet should register filter using HttpWhiteboardConstants.HTTP_WHITEBOARD_FILTER_PATTERN

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra resolved SLING-6406.

Resolution: Fixed

Fixed with 1777433. It now uses following header names

* X-Sling-TestName and X-Sling-TestClass instead of older X-Sling-Test-Name to 
avoid conflict with TestNameLoggingFilter in testing/tools module which is 
deprecated now. Otherwise on a system where both tools and junit core bundle is 
deployed then it causes lots of log for each request.

Now for a test a single message would logged at start

{noformat}
05.01.2017 13:58:22.217 *INFO* [qtp2112772548-750] 
org.apache.sling.junit.impl.servlet.TestLogServlet Starting test execution  
==[fooTest(com.example.BarIT)] ==
{noformat}

> TestLogServlet should register filter using 
> HttpWhiteboardConstants.HTTP_WHITEBOARD_FILTER_PATTERN
> --
>
> Key: SLING-6406
> URL: https://issues.apache.org/jira/browse/SLING-6406
> Project: Sling
>  Issue Type: Bug
>  Components: JUnit Core
>Affects Versions: JUnit Core 1.0.18
>Reporter: Andrei Dulvac
>Assignee: Chetan Mehrotra
> Fix For: JUnit Core 1.0.24
>
>
> TestServlet should register filter with 
> HttpWhiteboardConstants.HTTP_WHITEBOARD_FILTER_PATTERN at 
> https://github.com/apache/sling/blob/trunk/testing/junit/core/src/main/java/org/apache/sling/junit/impl/servlet/TestLogServlet.java#L229



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

[jira] [Resolved] (SLING-6405) Make testing.clients.interceptors.TestDescriptionInterceptor in line with TestLogServlet from junit core

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra resolved SLING-6405.

Resolution: Fixed

Fixed with 1777434. Now it uses following header name

* X-Sling-TestClass - For test class
* X-Sling-TestName - For test name

Same is used in TestLogServlet which is also responsible for logging the test 
startup logs

> Make testing.clients.interceptors.TestDescriptionInterceptor in line with 
> TestLogServlet from junit core
> 
>
> Key: SLING-6405
> URL: https://issues.apache.org/jira/browse/SLING-6405
> Project: Sling
>  Issue Type: Bug
>  Components: Apache Sling Testing Clients
>Affects Versions: Apache Sling Testing Clients 1.0.0
>Reporter: Andrei Dulvac
>Assignee: Chetan Mehrotra
> Fix For: Apache Sling Testing Clients 1.0.2
>
>
> https://github.com/apache/sling/blob/trunk/testing/http/clients/src/main/java/org/apache/sling/testing/clients/interceptors/TestDescriptionInterceptor.java#L35-L36
>  uses wrong headers.
> They should be in line with 
> https://github.com/apache/sling/blob/trunk/testing/junit/core/src/main/java/org/apache/sling/junit/impl/servlet/TestLogServlet.java



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

[jira] [Resolved] (SLING-6437) TestDescriptionRule in testing rules has incorrect has wrong order of method calls

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra resolved SLING-6437.

Resolution: Fixed

Fixed with r1777432

> TestDescriptionRule in testing rules has incorrect has wrong order of method 
> calls
> --
>
> Key: SLING-6437
> URL: https://issues.apache.org/jira/browse/SLING-6437
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: Apache Sling Testing Rules 1.0.2
>
>
> {{TestDescriptionRule}} calls method on TestDescriptionHolder in wrong order. 
> It invokes setter in {{finished}} and clear in {{starting}}



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

[jira] [Assigned] (SLING-6405) Make testing.clients.interceptors.TestDescriptionInterceptor in line with TestLogServlet from junit core

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra reassigned SLING-6405:
--

Assignee: Chetan Mehrotra  (was: Andrei Dulvac)

> Make testing.clients.interceptors.TestDescriptionInterceptor in line with 
> TestLogServlet from junit core
> 
>
> Key: SLING-6405
> URL: https://issues.apache.org/jira/browse/SLING-6405
> Project: Sling
>  Issue Type: Bug
>  Components: Apache Sling Testing Clients
>Affects Versions: Apache Sling Testing Clients 1.0.0
>Reporter: Andrei Dulvac
>Assignee: Chetan Mehrotra
> Fix For: Apache Sling Testing Clients 1.0.2
>
>
> https://github.com/apache/sling/blob/trunk/testing/http/clients/src/main/java/org/apache/sling/testing/clients/interceptors/TestDescriptionInterceptor.java#L35-L36
>  uses wrong headers.
> They should be in line with 
> https://github.com/apache/sling/blob/trunk/testing/junit/core/src/main/java/org/apache/sling/junit/impl/servlet/TestLogServlet.java



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

[jira] [Assigned] (SLING-6406) TestLogServlet should register filter using HttpWhiteboardConstants.HTTP_WHITEBOARD_FILTER_PATTERN

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra reassigned SLING-6406:
--

Assignee: Chetan Mehrotra  (was: Andrei Dulvac)

> TestLogServlet should register filter using 
> HttpWhiteboardConstants.HTTP_WHITEBOARD_FILTER_PATTERN
> --
>
> Key: SLING-6406
> URL: https://issues.apache.org/jira/browse/SLING-6406
> Project: Sling
>  Issue Type: Bug
>  Components: JUnit Core
>Affects Versions: JUnit Core 1.0.18
>Reporter: Andrei Dulvac
>Assignee: Chetan Mehrotra
> Fix For: JUnit Core 1.0.24
>
>
> TestServlet should register filter with 
> HttpWhiteboardConstants.HTTP_WHITEBOARD_FILTER_PATTERN at 
> https://github.com/apache/sling/blob/trunk/testing/junit/core/src/main/java/org/apache/sling/junit/impl/servlet/TestLogServlet.java#L229



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

[jira] [Created] (SLING-6437) TestDescriptionRule in testing rules has incorrect has wrong order of method calls

[Chetan Mehrotra (JIRA)]

Chetan Mehrotra created SLING-6437:
--

 Summary: TestDescriptionRule in testing rules has incorrect has 
wrong order of method calls
 Key: SLING-6437
 URL: https://issues.apache.org/jira/browse/SLING-6437
 Project: Sling
  Issue Type: Bug
  Components: Testing
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
 Fix For: Apache Sling Testing Rules 1.0.2


{{TestDescriptionRule}} calls method on TestDescriptionHolder in wrong order. 
It invokes setter in {{finished}} and clear in {{starting}}



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