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

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-6337:

Affects Version/s: (was: JCR Installer 3.1.20)
   JCR Installer 3.1.18

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



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

[VOTE] Release Apache Sling Commons FSClassLoader 1.0.4

[Carsten Ziegeler]

Hi,

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

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

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 1612 /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 Installer Console 1.0.2

[Carsten Ziegeler]

+1

 

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

[jira] [Commented] (SLING-4541) Provide an extensive test suite for the JCR content loader

[Petr Shypila (JIRA)]

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

Petr Shypila commented on SLING-4541:
-

[~cziegeler], as far as I remember it was not completed. I worked on this 
project in scope of Google Summer of Code 2015. Unfortunately I do not remember 
all the details. 

> Provide an extensive test suite for the JCR content loader
> --
>
> Key: SLING-4541
> URL: https://issues.apache.org/jira/browse/SLING-4541
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Affects Versions: JCR ContentLoader 2.1.10
>Reporter: Radu Cotescu
>Assignee: Petr Shypila
> Fix For: JCR ContentLoader 2.2.0
>
> Attachments: week-4-completed.patch, week-4_first_part.patch, 
> week2-part1-pathentry.patch, week2-part2-defaultcontentcreator.patch, 
> week2-part3-single-jcrmock-test.patch, week3.patch, week4-5.patch
>
>
> The JCR content loader is a sensible bundle. An extensive IT suite should be 
> written to make sure that code changes don't affect core functionality.



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

[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=15766739#comment-15766739
 ] 

Bertrand Delacretaz commented on SLING-6423:


In order to implement this we'll need (possibly failing) tests that demonstrate 
the desired behavior.

The existing code is at 
http://svn.apache.org/repos/asf/sling/trunk/bundles/jcr/repoinit/ and 
contributions of such tests are very welcome.

If various merging strategies can apply we might need to add support for such 
options in the repoinit language parser, that module is at 
http://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/repoinit/parser/

> 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
>
> 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.3.4#6332)

[jira] [Commented] (SLING-3535) reduce duplicated code in content loader

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-3535:
-

[~olli] Is this still a todo?

> reduce duplicated code in content loader
> 
>
> Key: SLING-3535
> URL: https://issues.apache.org/jira/browse/SLING-3535
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Affects Versions: JCR ContentLoader 2.1.6
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: JCR ContentLoader 2.2.0
>
>
> e.g. {{DefaultContentImporter}} and {{Loader}} can share more code in 
> {{BaseImportLoader}}



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

[jira] [Commented] (SLING-3619) Content Loader should handle input errors gracefully

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-3619:
-

[~olli] Is there anything left to do?

> Content Loader should handle input errors gracefully
> 
>
> Key: SLING-3619
> URL: https://issues.apache.org/jira/browse/SLING-3619
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Affects Versions: JCR ContentLoader 2.1.8
>Reporter: Yogesh Upadhyay
>Assignee: Oliver Lietz
>Priority: Minor
> Fix For: JCR ContentLoader 2.2.0
>
>
> After upgrading to latest sling jar file, content loader stopped working to 
> load content using Sling-Initial-Content. Getting following message in log
> 29.05.2014 23:20:21.504 *INFO* [Background Install 
> /var/folders/mh/tkx6mmq53tb_bcph_cfp7wzmgn/T/install277506169886207.tmp]
>  org.apache.sling.jcr.contentloader.internal.DefaultContentCreator 
> createFile: Cannot find content type for body.jsp, using 
> application/octet-stream



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

[jira] [Commented] (SLING-3533) improve error handling and logging in content loader

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-3533:
-

[~olli] Should we move this out of the 2.2.0 release schedule to not block it?

> improve error handling and logging in content loader
> 
>
> Key: SLING-3533
> URL: https://issues.apache.org/jira/browse/SLING-3533
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Affects Versions: JCR ContentLoader 2.1.6
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: JCR ContentLoader 2.2.0
>
>
> handle errors more appropriate and use proper log levels



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

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

[Nitin Nizhawan (JIRA)]

Nitin Nizhawan created SLING-6423:
-

 Summary: 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


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.3.4#6332)

Re: [VOTE] Release Apache Sling Commons FSClassLoader 1.0.4

[Carsten Ziegeler]

+1

 

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

Re: [RESULT] [VOTE] Release Apache Sling JCR Base 3.0.0

[Robert Munteanu]

On Tue, 2016-12-20 at 18:19 +0100, Julian Sedding wrote:
> @any PMC member: please copy this release to the Sling dist
> directory.

Done in r17514.

Robert

Re: [VOTE] Release Apache Sling Servlets Resolver 2.4.10

[Robert Munteanu]

On Tue, 2016-12-20 at 16:08 +0100, Carsten Ziegeler wrote:
> Please vote to approve this release:

+1

Robert

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

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

[Nitin Nizhawan (JIRA)]

Nitin Nizhawan created SLING-6422:
-

 Summary: 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)

Re: svn commit: r1774871 - /sling/trunk/tooling/jenkins/create_jobs.groovy

[Robert Munteanu]

Ping :-)


On Mon, 2016-12-19 at 11:33 +0200, Robert Munteanu wrote:
> Hi Olli,
> 
> I guess you just discovered why we don't allow SNAPSHOT dependencies
> to
> external projects in trunk :-)
> 
> Rather than remove the jobs, please work on a branch if you have work
> that requires SNAPSHOT dependencies. That's what we did for the IDE
> tooling until FileVault was released, for instance.
> 
> This way both the Jenkins jobs and other contributors/committers
> besides yourself can build the Karaf integration.
> 
> Thanks,
> 
> Robert
> 
> On Sun, 2016-12-18 at 10:15 +, o...@apache.org wrote:
> > Author: olli
> > Date: Sun Dec 18 10:15:02 2016
> > New Revision: 1774871
> > 
> > URL: http://svn.apache.org/viewvc?rev=1774871=rev
> > Log:
> > SLING-6411 Upgrade Karaf to 4.1
> > 
> > disable Jenkins build jobs due to use of external snapshots
> > 
> > Modified:
> > sling/trunk/tooling/jenkins/create_jobs.groovy
> > 
> > Modified: sling/trunk/tooling/jenkins/create_jobs.groovy
> > URL: http://svn.apache.org/viewvc/sling/trunk/tooling/jenkins/creat
> > e_
> > jobs.groovy?rev=1774871=1774870=1774871=diff
> > ===
> > ==
> > =
> > --- sling/trunk/tooling/jenkins/create_jobs.groovy (original)
> > +++ sling/trunk/tooling/jenkins/create_jobs.groovy Sun Dec 18
> > 10:15:02 2016
> > @@ -32,7 +32,7 @@ def modules = [
> >  ],
> >  [
> >  location: 'bundles/commons/log-webconsole'
> > -],
> > +],
> >  [
> >  location: 'bundles/commons/logservice'
> >  ],
> > @@ -593,24 +593,24 @@ def modules = [
> >  [
> >  location: "installer/providers/file"
> >  ],
> > -[
> > -location: 'karaf/org.apache.sling.karaf-distribution'
> > -],
> > -[
> > -location: 'karaf/org.apache.sling.karaf-features'
> > -],
> > -[
> > -location: 'karaf/org.apache.sling.karaf-integration-tests'
> > -],
> > -[
> > -location: 'karaf/org.apache.sling.karaf-launchpad-oak-tar-
> > integration-tests'
> > -],
> > -[
> > -location: 'karaf/org.apache.sling.karaf-repoinit'
> > -],
> > -[
> > -location: 'karaf/org.apache.sling.karaf-configs'
> > -],
> > +//[
> > +//location: 'karaf/org.apache.sling.karaf-distribution'
> > +//],
> > +//[
> > +//location: 'karaf/org.apache.sling.karaf-features'
> > +//],
> > +//[
> > +//location: 'karaf/org.apache.sling.karaf-integration-
> > tests'
> > +//],
> > +//[
> > +//location: 'karaf/org.apache.sling.karaf-launchpad-oak-
> > tar-
> > integration-tests'
> > +//],
> > +//[
> > +//location: 'karaf/org.apache.sling.karaf-repoinit'
> > +//],
> > +//[
> > +//location: 'karaf/org.apache.sling.karaf-configs'
> > +//],
> >  [
> >  location: 'launchpad/api',
> >  jdks: ["1.8"]
> > @@ -915,7 +915,7 @@ for more details''')
> >  // job is triggered first and we may end up with a
> >  // mix of Java 7 and Java 8 artifacts for projects
> > which
> >  // use these 2 versions
> > -def extraGoalsParams = module.extraGoalsParams ?: "" 
> > +def extraGoalsParams = module.extraGoalsParams ?: ""
> >  goals( (deploy ? "-U clean deploy" : "-U clean
> > verify")
> > + " " + extraGoalsParams)
> >  
> >  publishers {
> > 
> > 
> 
> 

[VOTE] Release Apache Sling Installer Console 1.0.2

[Carsten Ziegeler]

Hi,

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

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

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 1611 /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-4541) Provide an extensive test suite for the JCR content loader

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-4541:
-

[~bdelacretaz], [~petr.shypila] What is the status here? 

> Provide an extensive test suite for the JCR content loader
> --
>
> Key: SLING-4541
> URL: https://issues.apache.org/jira/browse/SLING-4541
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Affects Versions: JCR ContentLoader 2.1.10
>Reporter: Radu Cotescu
>Assignee: Petr Shypila
> Fix For: JCR ContentLoader 2.2.0
>
> Attachments: week-4-completed.patch, week-4_first_part.patch, 
> week2-part1-pathentry.patch, week2-part2-defaultcontentcreator.patch, 
> week2-part3-single-jcrmock-test.patch, week3.patch, week4-5.patch
>
>
> The JCR content loader is a sensible bundle. An extensive IT suite should be 
> written to make sure that code changes don't affect core functionality.



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

[jira] [Commented] (SLING-3534) separate node name and content type in content loader

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-3534:
-

[~olli] Can we close this?

> separate node name and content type in content loader
> -
>
> Key: SLING-3534
> URL: https://issues.apache.org/jira/browse/SLING-3534
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Affects Versions: JCR ContentLoader 2.1.6
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: JCR ContentLoader 2.2.0
>
>
> extend API (node name and content type are currently taken from file name)



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

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

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz updated SLING-6301:
---
Fix Version/s: Dynamic Include 3.0.0

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



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

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

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz resolved SLING-6301.

Resolution: Fixed

Release is done, marking this fixed

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



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

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

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz closed SLING-6301.
--

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



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

[jira] [Closed] (SLING-5594) Donation of Sling Dynamic Include

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz closed SLING-5594.
--

First version 3.0.0 released, see SLING-6301

> Donation of Sling Dynamic Include
> -
>
> Key: SLING-5594
> URL: https://issues.apache.org/jira/browse/SLING-5594
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Reporter: Przemo Pakulski
>Assignee: Bertrand Delacretaz
> Fix For: Dynamic Include 3.0.0
>
> Attachments: sling-dynamic-include.zip
>
>
> Issue to track donation of Sling Dynamic Include to Apache Sling project.
> Code base and documentation are currently here [0]:
> [0] https://github.com/Cognifide/Sling-Dynamic-Include/tree/sling-extension



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

[jira] [Commented] (SLING-6305) LoginAdminWhitelist configuration is applied too late

[Julian Sedding (JIRA)]

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

Julian Sedding commented on SLING-6305:
---

Based on my analysis, I suspect the main reason why tests usually pass now is 
that the repo initialization is asynchronous now.
Normally, repo initialization takes a few seconds and used to block any other 
configs or bundles from being installed. Thus it now allows more time for 
configurations to be registered, leading to a higher success rate. Due to the 
fact that we're still relying on a (now heavily biased) race, strictly 
speaking, I would argue that the tests are not yet fully deterministic. But 
they seem to be good enough for the moment.

> LoginAdminWhitelist configuration is applied too late
> -
>
> Key: SLING-6305
> URL: https://issues.apache.org/jira/browse/SLING-6305
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Affects Versions: JCR Base 2.4.2
>Reporter: Robert Munteanu
>
> I've been getting some local failures with the launchpad/testing module, and 
> I noticed that the {{org.apache.sling.junit.scriptable}} bundle was not 
> whitelisted for loginAdministrative:
> {noformat}19.11.2016 10:40:54.063 *ERROR* [CM Event Dispatcher (Fire 
> ConfigurationEvent: 
> pid=org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)] 
> org.apache.sling.junit.scriptable 
> [org.apache.sling.junit.scriptable.ScriptableTestsProvider(204)] The activate 
> method has thrown an exception (javax.jcr.LoginException: Bundle 
> org.apache.sling.junit.scriptable is NOT whitelisted)
> javax.jcr.LoginException: Bundle org.apache.sling.junit.scriptable is NOT 
> whitelisted{noformat}
> The configuration was correct, so I added a little debug information in the 
> {{org.apache.sling.jcr.base}} bundle to print the whitelist regexp in the 
> same line as the whitelisted bundles. I noticed then that the component is 
> activated several times, with only the last one actually setting the 
> configuration
> {noformat}19.11.2016 10:40:51.630 *INFO* [CM Event Dispatcher (Fire 
> ConfigurationEvent: 
> pid=org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)] 
> org.apache.sling.jcr.base.internal.LoginAdminWhitelist bypassWhitelist=false, 
> whitelisted BSNs(17)=[org.apache.sling.discovery.base, 
> org.apache.sling.discovery.commons, org.apache.sling.discovery.oak, 
> org.apache.sling.extensions.webconsolesecurityprovider, 
> org.apache.sling.i18n, org.apache.sling.installer.provider.jcr, 
> org.apache.sling.jcr.base, org.apache.sling.jcr.contentloader, 
> org.apache.sling.jcr.davex, org.apache.sling.jcr.jackrabbit.usermanager, 
> org.apache.sling.jcr.oak.server, org.apache.sling.jcr.repoinit, 
> org.apache.sling.jcr.resource, org.apache.sling.jcr.webconsole, 
> org.apache.sling.resourceresolver, org.apache.sling.servlets.post, 
> org.apache.sling.servlets.resolver], whitelistRegexp=null
> 19.11.2016 10:40:55.150 *INFO* [CM Event Dispatcher (Fire ConfigurationEvent: 
> pid=org.apache.jackrabbit.oak.security.authentication.AuthenticationConfigurationImpl)]
>  org.apache.sling.jcr.base.internal.LoginAdminWhitelist 
> bypassWhitelist=false, whitelisted BSNs(17)=[org.apache.sling.discovery.base, 
> org.apache.sling.discovery.commons, org.apache.sling.discovery.oak, 
> org.apache.sling.extensions.webconsolesecurityprovider, 
> org.apache.sling.i18n, org.apache.sling.installer.provider.jcr, 
> org.apache.sling.jcr.base, org.apache.sling.jcr.contentloader, 
> org.apache.sling.jcr.davex, org.apache.sling.jcr.jackrabbit.usermanager, 
> org.apache.sling.jcr.oak.server, org.apache.sling.jcr.repoinit, 
> org.apache.sling.jcr.resource, org.apache.sling.jcr.webconsole, 
> org.apache.sling.resourceresolver, org.apache.sling.servlets.post, 
> org.apache.sling.servlets.resolver], whitelistRegexp=null
> 19.11.2016 10:40:56.200 *INFO* [CM Event Dispatcher (Fire ConfigurationEvent: 
> pid=org.apache.jackrabbit.oak.security.user.UserConfigurationImpl)] 
> org.apache.sling.jcr.base.internal.LoginAdminWhitelist bypassWhitelist=false, 
> whitelisted BSNs(17)=[org.apache.sling.discovery.base, 
> org.apache.sling.discovery.commons, org.apache.sling.discovery.oak, 
> org.apache.sling.extensions.webconsolesecurityprovider, 
> org.apache.sling.i18n, org.apache.sling.installer.provider.jcr, 
> org.apache.sling.jcr.base, org.apache.sling.jcr.contentloader, 
> org.apache.sling.jcr.davex, org.apache.sling.jcr.jackrabbit.usermanager, 
> org.apache.sling.jcr.oak.server, org.apache.sling.jcr.repoinit, 
> org.apache.sling.jcr.resource, org.apache.sling.jcr.webconsole, 
> org.apache.sling.resourceresolver, org.apache.sling.servlets.post, 
> org.apache.sling.servlets.resolver], whitelistRegexp=null
> 19.11.2016 10:40:57.190 *INFO* [CM Event Dispatcher (Fire 

Re: svn commit: r1774871 - /sling/trunk/tooling/jenkins/create_jobs.groovy

[Oliver Lietz]

On Wednesday 21 December 2016 17:02:49 Robert Munteanu wrote:
> On Wed, 2016-12-21 at 15:46 +0100, Oliver Lietz wrote:
> > On Monday 19 December 2016 11:33:54 Robert Munteanu wrote:
> > > Hi Olli,
> > 
> > Hi Robert,
> > 
> > > I guess you just discovered why we don't allow SNAPSHOT
> > > dependencies to
> > > external projects in trunk :-)
> > 
> > no, I'm aware that external SNAPSHOTs are not accessible in our
> > default build 
> > setup and disabled all Karaf build jobs _before_ using them.
> 
> Right, that does indeed save us the trouble of being flooded by
> notifications, which is appreciated.
> 
> > > Rather than remove the jobs, please work on a branch if you have
> > > work
> > > that requires SNAPSHOT dependencies. That's what we did for the IDE
> > > tooling until FileVault was released, for instance.
> > > 
> > > This way both the Jenkins jobs and other contributors/committers
> > > besides yourself can build the Karaf integration.
> > 
> > Further development is blocked as Sling requires R6 Http features
> > which are 
> > not available with Karaf 4.0. I have to use Karaf 4.1-SNAPSHOT and
> > Pax Web 
> > 6.0-SNAPSHOT, please see SLING-6411.
> 
> Ack
> 
> > We hadn't a release yet and there are no other Sling developers
> > moving 
> > Sling/Karaf forward – so I don't see a problem in disabling the build
> > jobs.
> 
> Ack. My point was not about the build jobs, it's about keeping trunk in
> a buildable state at all times.
> 
> I understand your argument about no release and no other contributors.
> However, we don't know who is trying to build the SVN repository and
> who is interested in the Karaf integration. They might try building it
> only to have it fail due to missing dependencies.
> 
> I like simple rules :-) one of those is having trunk always build.
> 
> What would be the disadvantage of working with SNAPSHOTs in branches
> and merging back to trunk once we have releases of the respective
> projects?

Well, the extra work of branching and merging in SVN. It's my spare time I 
spend on Sling.

The Sling/Karaf build is frequently broken by other developers who do not care 
about those modules. Especially the org.apache.sling.karaf-launchpad-oak-tar-
integration-tests module where I have to use snapshots of test bundles.

I'm not happy with the current situation either but trying to get it fixed 
(see related issues in upstream projects also: Karaf, Pax Web, Pax Exam).

The same time I switched to Karaf snapshots the README was updated and every 
move is documented in JIRA. So it should be very clear that it is work in 
progress.

Regards,
O.

> Thanks,
> 
> Robert
> 
> > Thanks,
> > O.
> > 
> > > Thanks,
> > > 
> > > Robert
> > > 
> > > On Sun, 2016-12-18 at 10:15 +, o...@apache.org wrote:
> > > > Author: olli
> > > > Date: Sun Dec 18 10:15:02 2016
> > > > New Revision: 1774871
> > > > 
> > > > URL: http://svn.apache.org/viewvc?rev=1774871=rev
> > > > Log:
> > > > SLING-6411 Upgrade Karaf to 4.1
> > > > 
> > > > disable Jenkins build jobs due to use of external snapshots
> > > > 
> > > > Modified:
> > > > sling/trunk/tooling/jenkins/create_jobs.groovy
> > > > 
> > > > Modified: sling/trunk/tooling/jenkins/create_jobs.groovy
> > > > URL: http://svn.apache.org/viewvc/sling/trunk/tooling/jenkins/cre
> > > > ate_
> > > > jobs.groovy?rev=1774871=1774870=1774871=diff
> > > > =
> > > > 
> > > > =
> > > > --- sling/trunk/tooling/jenkins/create_jobs.groovy (original)
> > > > +++ sling/trunk/tooling/jenkins/create_jobs.groovy Sun Dec 18
> > > > 10:15:02 2016
> > > > @@ -32,7 +32,7 @@ def modules = [
> > > >  ],
> > > >  [
> > > >  location: 'bundles/commons/log-webconsole'
> > > > -],
> > > > +],
> > > >  [
> > > >  location: 'bundles/commons/logservice'
> > > >  ],
> > > > @@ -593,24 +593,24 @@ def modules = [
> > > >  [
> > > >  location: "installer/providers/file"
> > > >  ],
> > > > -[
> > > > -location: 'karaf/org.apache.sling.karaf-distribution'
> > > > -],
> > > > -[
> > > > -location: 'karaf/org.apache.sling.karaf-features'
> > > > -],
> > > > -[
> > > > -location: 'karaf/org.apache.sling.karaf-integration-
> > > > tests'
> > > > -],
> > > > -[
> > > > -location: 'karaf/org.apache.sling.karaf-launchpad-oak-
> > > > tar-
> > > > integration-tests'
> > > > -],
> > > > -[
> > > > -location: 'karaf/org.apache.sling.karaf-repoinit'
> > > > -],
> > > > -[
> > > > -location: 'karaf/org.apache.sling.karaf-configs'
> > > > -],
> > > > +//[
> > > > +//location: 'karaf/org.apache.sling.karaf-distribution'
> > > > +//],
> > > > +//[
> > > > +//location: 'karaf/org.apache.sling.karaf-features'
> > > > +//],
> > > > +//[
> > > > +//location: 'karaf/org.apache.sling.karaf-integration-
> > > > tests'
> > > > +//],
> > 

[jira] [Commented] (SLING-3535) reduce duplicated code in content loader

[Oliver Lietz (JIRA)]

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

Oliver Lietz commented on SLING-3535:
-

Yes

> reduce duplicated code in content loader
> 
>
> Key: SLING-3535
> URL: https://issues.apache.org/jira/browse/SLING-3535
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Affects Versions: JCR ContentLoader 2.1.6
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: JCR ContentLoader 2.2.0
>
>
> e.g. {{DefaultContentImporter}} and {{Loader}} can share more code in 
> {{BaseImportLoader}}



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

[jira] [Resolved] (SLING-6420) Enhance Conversion Rules for ValueMapDecorator

[Stefan Seifert (JIRA)]

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

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

Completed: At revision: 1775411  


> Enhance Conversion Rules for ValueMapDecorator
> --
>
> Key: SLING-6420
> URL: https://issues.apache.org/jira/browse/SLING-6420
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Affects Versions: API 2.16.2
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
> Fix For: API 2.16.4
>
>
> background in this discussion in the [mailing 
> list|https://lists.apache.org/thread.html/696deaf2f6b67d99ee969aad19e5b8b00d9c53c78e9ad75633e9e809@%3Cdev.sling.apache.org%3E]
>  the conversion rules of the ValueMapDecorator should be unified with the 
> conversion rules of the JCR ValueMap implement (as long as they are not too 
> JCR specific).
> the conversion rules that are currently supported are outlined here: 
> https://cwiki.apache.org/confluence/x/OQkIB
> with this ticket we want to add support for
> * Convert any number type of (Long, Byte, Short, Integer, Double, Float, 
> BigDecimal) -> to each of them or String and vice versa
> * Convert any date type of (Calendar, Date) -> to each of them or String and 
> vice versa
> * and make the existing implementation a bit more efficient (avoid string 
> parsing when possible)



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

[jira] [Commented] (SLING-6305) LoginAdminWhitelist configuration is applied too late

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-6305:


[~sseif...@pro-vision.de] - the caconfig ITs seem to be working just fine now, 
I think that it's due to the upstream projects moving to LoginAdminWhiteList 
fragments, e.g.

{noformat}  
org.apache.sling.jcr.base.internal.LoginAdminWhitelist.fragment-composum
whitelist.name="composum"
whitelist.bundles=[
"com.composum.core.commons",\
]{noformat}

Additionally, the ITs were being hit by SLING-6332 - the original 
LoginAdminWhiteList config was declared in the {{sling}} features, but the 
additional one was included in the {{integration-tests}} one, so which one was 
being picked up was random.

I would suggest that the caconfig ITs move to a config fragment as well, to be 
consistent.

> LoginAdminWhitelist configuration is applied too late
> -
>
> Key: SLING-6305
> URL: https://issues.apache.org/jira/browse/SLING-6305
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Affects Versions: JCR Base 2.4.2
>Reporter: Robert Munteanu
>
> I've been getting some local failures with the launchpad/testing module, and 
> I noticed that the {{org.apache.sling.junit.scriptable}} bundle was not 
> whitelisted for loginAdministrative:
> {noformat}19.11.2016 10:40:54.063 *ERROR* [CM Event Dispatcher (Fire 
> ConfigurationEvent: 
> pid=org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)] 
> org.apache.sling.junit.scriptable 
> [org.apache.sling.junit.scriptable.ScriptableTestsProvider(204)] The activate 
> method has thrown an exception (javax.jcr.LoginException: Bundle 
> org.apache.sling.junit.scriptable is NOT whitelisted)
> javax.jcr.LoginException: Bundle org.apache.sling.junit.scriptable is NOT 
> whitelisted{noformat}
> The configuration was correct, so I added a little debug information in the 
> {{org.apache.sling.jcr.base}} bundle to print the whitelist regexp in the 
> same line as the whitelisted bundles. I noticed then that the component is 
> activated several times, with only the last one actually setting the 
> configuration
> {noformat}19.11.2016 10:40:51.630 *INFO* [CM Event Dispatcher (Fire 
> ConfigurationEvent: 
> pid=org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)] 
> org.apache.sling.jcr.base.internal.LoginAdminWhitelist bypassWhitelist=false, 
> whitelisted BSNs(17)=[org.apache.sling.discovery.base, 
> org.apache.sling.discovery.commons, org.apache.sling.discovery.oak, 
> org.apache.sling.extensions.webconsolesecurityprovider, 
> org.apache.sling.i18n, org.apache.sling.installer.provider.jcr, 
> org.apache.sling.jcr.base, org.apache.sling.jcr.contentloader, 
> org.apache.sling.jcr.davex, org.apache.sling.jcr.jackrabbit.usermanager, 
> org.apache.sling.jcr.oak.server, org.apache.sling.jcr.repoinit, 
> org.apache.sling.jcr.resource, org.apache.sling.jcr.webconsole, 
> org.apache.sling.resourceresolver, org.apache.sling.servlets.post, 
> org.apache.sling.servlets.resolver], whitelistRegexp=null
> 19.11.2016 10:40:55.150 *INFO* [CM Event Dispatcher (Fire ConfigurationEvent: 
> pid=org.apache.jackrabbit.oak.security.authentication.AuthenticationConfigurationImpl)]
>  org.apache.sling.jcr.base.internal.LoginAdminWhitelist 
> bypassWhitelist=false, whitelisted BSNs(17)=[org.apache.sling.discovery.base, 
> org.apache.sling.discovery.commons, org.apache.sling.discovery.oak, 
> org.apache.sling.extensions.webconsolesecurityprovider, 
> org.apache.sling.i18n, org.apache.sling.installer.provider.jcr, 
> org.apache.sling.jcr.base, org.apache.sling.jcr.contentloader, 
> org.apache.sling.jcr.davex, org.apache.sling.jcr.jackrabbit.usermanager, 
> org.apache.sling.jcr.oak.server, org.apache.sling.jcr.repoinit, 
> org.apache.sling.jcr.resource, org.apache.sling.jcr.webconsole, 
> org.apache.sling.resourceresolver, org.apache.sling.servlets.post, 
> org.apache.sling.servlets.resolver], whitelistRegexp=null
> 19.11.2016 10:40:56.200 *INFO* [CM Event Dispatcher (Fire ConfigurationEvent: 
> pid=org.apache.jackrabbit.oak.security.user.UserConfigurationImpl)] 
> org.apache.sling.jcr.base.internal.LoginAdminWhitelist bypassWhitelist=false, 
> whitelisted BSNs(17)=[org.apache.sling.discovery.base, 
> org.apache.sling.discovery.commons, org.apache.sling.discovery.oak, 
> org.apache.sling.extensions.webconsolesecurityprovider, 
> org.apache.sling.i18n, org.apache.sling.installer.provider.jcr, 
> org.apache.sling.jcr.base, org.apache.sling.jcr.contentloader, 
> org.apache.sling.jcr.davex, org.apache.sling.jcr.jackrabbit.usermanager, 
> org.apache.sling.jcr.oak.server, org.apache.sling.jcr.repoinit, 
> org.apache.sling.jcr.resource, org.apache.sling.jcr.webconsole, 
> org.apache.sling.resourceresolver, 

[jira] [Created] (SLING-6424) ValueMapDecoratory: Empty arrays for multi-value properties should not be converted to null

[Stefan Seifert (JIRA)]

Stefan Seifert created SLING-6424:
-

 Summary: ValueMapDecoratory: Empty arrays for multi-value 
properties should not be converted to null
 Key: SLING-6424
 URL: https://issues.apache.org/jira/browse/SLING-6424
 Project: Sling
  Issue Type: Bug
  Components: API
Affects Versions: API 2.16.2
Reporter: Stefan Seifert
Assignee: Stefan Seifert
 Fix For: API 2.16.4


currently empty arrays in the base map manged by the ValueMapDecorator are 
converted to null.
this is imho wrong, because an empty list might be a valid value for a 
multi-valued property which should not lead to fallback to the default value 
for example.



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

[jira] [Updated] (SLING-6424) ValueMapDecorator: Empty arrays for multi-value properties should not be converted to null

[Stefan Seifert (JIRA)]

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

Stefan Seifert updated SLING-6424:
--
Summary: ValueMapDecorator: Empty arrays for multi-value properties should 
not be converted to null  (was: ValueMapDecoratory: Empty arrays for 
multi-value properties should not be converted to null)

> ValueMapDecorator: Empty arrays for multi-value properties should not be 
> converted to null
> --
>
> Key: SLING-6424
> URL: https://issues.apache.org/jira/browse/SLING-6424
> Project: Sling
>  Issue Type: Bug
>  Components: API
>Affects Versions: API 2.16.2
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
> Fix For: API 2.16.4
>
>
> currently empty arrays in the base map manged by the ValueMapDecorator are 
> converted to null.
> this is imho wrong, because an empty list might be a valid value for a 
> multi-valued property which should not lead to fallback to the default value 
> for example.



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

[jira] [Resolved] (SLING-6416) MockValueMap does not permit to get a BigDecimal value

[Stefan Seifert (JIRA)]

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

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

Completed: At revision: 1775430  


> MockValueMap does not permit to get a BigDecimal value
> --
>
> Key: SLING-6416
> URL: https://issues.apache.org/jira/browse/SLING-6416
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: Testing ResourceResolver Mock 1.1.14
>Reporter: Christophe Jelger
>Assignee: Stefan Seifert
>
> The {{get(String name, Class type)}} method in {{MockValueMap.java}} does 
> not support {{BigDecimal}} as a type. This is supported by the 
> {{JcrValueMap}} and {{JcrPropertyMapCacheEntry}} classes, and hence means 
> that it's not possible to test code that reads a {{BigDecimal}} property 
> value from the JCR.



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

[jira] [Resolved] (SLING-6424) ValueMapDecorator: Empty arrays for multi-value properties should not be converted to null

[Stefan Seifert (JIRA)]

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

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

Completed: At revision: 1775427  


> ValueMapDecorator: Empty arrays for multi-value properties should not be 
> converted to null
> --
>
> Key: SLING-6424
> URL: https://issues.apache.org/jira/browse/SLING-6424
> Project: Sling
>  Issue Type: Bug
>  Components: API
>Affects Versions: API 2.16.2
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
> Fix For: API 2.16.4
>
>
> currently empty arrays in the base map manged by the ValueMapDecorator are 
> converted to null.
> this is imho wrong, because an empty list might be a valid value for a 
> multi-valued property which should not lead to fallback to the default value 
> for example.



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

[jira] [Created] (SLING-6425) Update Pax Exam to 4.10

[Oliver Lietz (JIRA)]

Oliver Lietz created SLING-6425:
---

 Summary: Update Pax Exam to 4.10
 Key: SLING-6425
 URL: https://issues.apache.org/jira/browse/SLING-6425
 Project: Sling
  Issue Type: Task
  Components: Karaf
Reporter: Oliver Lietz
Assignee: Oliver Lietz
 Fix For: Karaf Integration Tests 0.2.0


Pax Exam 4.10 is required to use Felix Configuration Admin {{.config}} files 
(used by Sling) in tests:

[PAXEXAM-805|https://ops4j1.jira.com/browse/PAXEXAM-805] Support configuration 
files in Felix Configuration Admin format (.config)



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

[jira] [Created] (SLING-6426) Use Felix Configuration Admin format for all configurations

[Oliver Lietz (JIRA)]

Oliver Lietz created SLING-6426:
---

 Summary: Use Felix Configuration Admin format for all 
configurations
 Key: SLING-6426
 URL: https://issues.apache.org/jira/browse/SLING-6426
 Project: Sling
  Issue Type: Task
  Components: Karaf
Reporter: Oliver Lietz
Assignee: Oliver Lietz
 Fix For: Karaf Features 0.2.0, Karaf Integration Tests 0.2.0, 
Karaf Distribution 0.2.0, Karaf Configs 0.2.0






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

Snapshot dependencies to external projects (was: svn commit: r1775432 - /sling/trunk/karaf/org.apache.sling.karaf-integration-tests/pom.xml)

[Robert Munteanu]

Olli,

Please, stop using dependencies to external projects in trunk. It makes
projects not build out of the box and unable to release without doing
work which is out of our control.

You've done this with Karaf and then with Pax-Exam.

Working on branches is a great way to allow everyone else to build and
work on the projects until we get external releases.

If you believe that is the wrong approach, please let us know, but
ignoring the policy is not that productive :-)

Thanks,

Robert

On Wed, 2016-12-21 at 14:21 +, o...@apache.org wrote:
> Author: olli
> Date: Wed Dec 21 14:21:31 2016
> New Revision: 1775432
> 
> URL: http://svn.apache.org/viewvc?rev=1775432=rev
> Log:
> SLING-6425 Update Pax Exam to 4.10
> 
> use 4.10.0-SNAPSHOT
> 
> Modified:
> sling/trunk/karaf/org.apache.sling.karaf-integration-
> tests/pom.xml
> 
> Modified: sling/trunk/karaf/org.apache.sling.karaf-integration-
> tests/pom.xml
> URL: http://svn.apache.org/viewvc/sling/trunk/karaf/org.apache.sling.
> karaf-integration-
> tests/pom.xml?rev=1775432=1775431=1775432=diff
> =
> =
> --- sling/trunk/karaf/org.apache.sling.karaf-integration-
> tests/pom.xml (original)
> +++ sling/trunk/karaf/org.apache.sling.karaf-integration-
> tests/pom.xml Wed Dec 21 14:21:31 2016
> @@ -38,7 +38,7 @@
>    
>  2.13.1 sion>
>  4.1.0-
> SNAPSHOT
> -4.9.2
> +4.10.0-
> SNAPSHOT
>    
>  
>    
> 
> 

[VOTE] Release Apache Sling Testing ResourceResolver Mock 1.1.16

[Stefan Seifert]

Hi,

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

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

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

Please vote to approve this release:

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

This majority vote is open for at least 72 hours.

stefan

[jira] [Commented] (SLING-3619) Content Loader should handle input errors gracefully

[Oliver Lietz (JIRA)]

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

Oliver Lietz commented on SLING-3619:
-

Yes

> Content Loader should handle input errors gracefully
> 
>
> Key: SLING-3619
> URL: https://issues.apache.org/jira/browse/SLING-3619
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Affects Versions: JCR ContentLoader 2.1.8
>Reporter: Yogesh Upadhyay
>Assignee: Oliver Lietz
>Priority: Minor
> Fix For: JCR ContentLoader 2.2.0
>
>
> After upgrading to latest sling jar file, content loader stopped working to 
> load content using Sling-Initial-Content. Getting following message in log
> 29.05.2014 23:20:21.504 *INFO* [Background Install 
> /var/folders/mh/tkx6mmq53tb_bcph_cfp7wzmgn/T/install277506169886207.tmp]
>  org.apache.sling.jcr.contentloader.internal.DefaultContentCreator 
> createFile: Cannot find content type for body.jsp, using 
> application/octet-stream



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

[jira] [Commented] (SLING-3533) improve error handling and logging in content loader

[Oliver Lietz (JIRA)]

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

Oliver Lietz commented on SLING-3533:
-

Yes. All Content Loader issues assigned to me are still on my TODO, but Content 
Loader needs major cleanup and much more testing.

> improve error handling and logging in content loader
> 
>
> Key: SLING-3533
> URL: https://issues.apache.org/jira/browse/SLING-3533
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Affects Versions: JCR ContentLoader 2.1.6
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: JCR ContentLoader 2.2.0
>
>
> handle errors more appropriate and use proper log levels



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

Re: Jenkins build is still unstable: sling-launchpad-testing-1.8 #339

[Julian Sedding]

It seems that launchpad testing started to fail with
https://svn.apache.org/r1775262 (see launchpad-testing #326 [0]
triggered by launchpad builder #417 [1] triggered by r1775262).

Carsten, could you please take a look?

Regards
Julian

[0] https://builds.apache.org/job/sling-launchpad-testing-1.8/326/
[1] https://builds.apache.org/job/sling-launchpad-builder-1.8/417/

On Wed, Dec 21, 2016 at 1:25 PM, Apache Jenkins Server
 wrote:
> See 
>

[jira] [Commented] (SLING-3534) separate node name and content type in content loader

[Oliver Lietz (JIRA)]

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

Oliver Lietz commented on SLING-3534:
-

Yes, missing tests can be added in SLING-4541.

> separate node name and content type in content loader
> -
>
> Key: SLING-3534
> URL: https://issues.apache.org/jira/browse/SLING-3534
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Affects Versions: JCR ContentLoader 2.1.6
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: JCR ContentLoader 2.2.0
>
>
> extend API (node name and content type are currently taken from file name)



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

Re: [RESULT] [VOTE] Release Apache Sling JCR Base 3.0.0

[Julian Sedding]

Thanks Robert!

Regards
Julian

On Wed, Dec 21, 2016 at 11:23 AM, Robert Munteanu  wrote:
> On Tue, 2016-12-20 at 18:19 +0100, Julian Sedding wrote:
>> @any PMC member: please copy this release to the Sling dist
>> directory.
>
> Done in r17514.
>
> Robert

Re: svn commit: r1774871 - /sling/trunk/tooling/jenkins/create_jobs.groovy

[Robert Munteanu]

On Wed, 2016-12-21 at 16:46 +0100, Oliver Lietz wrote:
> Well, the extra work of branching and merging in SVN. It's my spare
> time I 
> spend on Sling.
> 
> The Sling/Karaf build is frequently broken by other developers who do
> not care 
> about those modules. Especially the org.apache.sling.karaf-launchpad-
> oak-tar-
> integration-tests module where I have to use snapshots of test
> bundles.

How can we find out if we broke something in the Karaf integration?

> 
> I'm not happy with the current situation either but trying to get it
> fixed 
> (see related issues in upstream projects also: Karaf, Pax Web, Pax
> Exam).

And that is very much appreciated.

Robert

> 
> The same time I switched to Karaf snapshots the README was updated
> and every 
> move is documented in JIRA. So it should be very clear that it is
> work in 
> progress.
> 
> Regards,
> O.

Re: svn commit: r1774871 - /sling/trunk/tooling/jenkins/create_jobs.groovy

[Robert Munteanu]

On Wed, 2016-12-21 at 17:07 +0100, Oliver Lietz wrote:
> On Wednesday 21 December 2016 16:16:36 Bertrand Delacretaz wrote:
> > On Wed, Dec 21, 2016 at 4:02 PM, Robert Munteanu  > g> wrote:
> > > ...What would be the disadvantage of working with SNAPSHOTs in
> > > branches
> > > and merging back to trunk once we have releases of the respective
> > > projects?...
> > 
> > IMO the problem is that this makes that work essentially
> > "invisible"
> > to others as we do not usually work with svn branches.
> 
> Good point.
> 
> > We could use instead a Maven profile in the main pom for such
> > modules
> > that require external snapshots. Disabled by default, so the trunk
> > builds and one can easily re-enable those modules as needed.
> 
> That does not work unfortunately. The Sling Karaf modules will fail
> with 
> latest Sling releases because of missing R6 Http support.
> I stopped updating some dependencies (using the Http Whiteboard, e.g.
> Engine, 
> Rewriter, i18n) but the gap is getting bigger and bigger every day
> and hard to 
> catch up. Other parts of Sling are also moving fast and need special
> attention 
> (e.g. Login Admin Whitelist and system users).
> 
> I'm close again (test with Oak Mongo is broken and
> org.apache.sling.karaf-
> launchpad-oak-tar-integration-tests has issues) at the cost of not
> having a 
> Jenkins build until all required upstream projects are released.

I double-checked, and the Karaf modules are not part of the main
reactor anyway.

How far away are we from upstream releases of Karaf and Pax-Exam?

Robert

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

[JIRA]

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

Dominik Süß commented on SLING-6187:


Do we really want the request to define the PostProcessors? in my mind 
PostProcessing is an implementation detail that should not be wired to the 
request. 

When I was analyzing PostProcessors some years ago I always had the impression 
that we would probably need to have a better registry of postprocessing 
pipelines/chains and would make sure every step in the defined pipeline (e.g. 
registered for a certain path or resourcetype) would need to be satisfied. So 
instead of dynamically wiring postprocessors that are available by their 
service ranking we would have a defined pipeline naming steps where the 
postprocessors would provide the implementation for the steps and none of the 
steps can be unsatisfied (or would lead to implicit failure).

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



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

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

[Amit Gupta (JIRA)]

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

Amit Gupta resolved SLING-4753.
---
Resolution: Fixed
  Assignee: Amit Gupta

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



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

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

[Timothee Maret (JIRA)]

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

Timothee Maret commented on SLING-4753:
---

[~amitgupt] it seems the patch has been commit at {{r1681937}}. Could you close 
this issue ? 

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



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

[jira] [Commented] (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:comment-tabpanel=15768852#comment-15768852
 ] 

Nitin Nizhawan commented on SLING-6422:
---

+1 , in addition to this, do we think that we need to add any type hint or we 
can add that later if required? \[0\]. 
{code}
allow ... restriction{String}(rep:glob, *.jsp, *.txt) restriction(rep:ntNames, 
sling:Folder) restriction(rep:prefixes, sling)
allow ... restriction{Date}(my:custom, "13:00UTC, 23:59UTC")
allow ... restriction{Decimal}(my:custom2, 1, 2)
allow ... restriction{Name}(rep:ntNames, dam:Asset, nt:unstructured)
allow ... restriction(my:string, "It's \"quoted\"", "second string")
{code}





\[0\] 
https://docs.adobe.com/content/docs/en/spec/javax.jcr/javadocs/jcr-2.0/javax/jcr/Value.html?is-external=true

> 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)

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

[Nitin Nizhawan (JIRA)]

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

Nitin Nizhawan commented on SLING-6423:
---

It seems current repoinit implementation just adds ACEs to ACLs if those ACEs 
didn't already exist. Whereas behaviour of merge and merge_preserve is based on 
principals \[0\]. For example given existing ACLs as
{code}
ALLOW bob rep:write
ALLOW alice jcr:read
{code}
New ACL
{code}
ALLOW bob rep:write
ALLOW bob cq:replicate
ALLOW alice jcr:read

{code}
When merged will have following resutls
1. Using repoinit
{code}
ALLOW bob rep:write
ALLOW alice jcr:read
ALLOW bob cq:replicate
{code}
2. Using merge ACHandling
{code}
ALLOW bob rep:write
ALLOW bob cq:replicate
ALLOW alice jcr:read
{code}
3. Using merge_preserve ACHandling
{code}
ALLOW bob rep:write
ALLOW alice jcr:read
{code}

\[0\] 
https://github.com/apache/jackrabbit-filevault/blob/4528e3ebb851377e37f46fc7cac411d12520ace6/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/JackrabbitACLImporter.java#L277
Thanks
Nitin

> 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
>
> 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.3.4#6332)

[jira] [Comment Edited] (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:comment-tabpanel=15768852#comment-15768852
 ] 

Nitin Nizhawan edited comment on SLING-6422 at 12/22/16 3:02 AM:
-

+1 , in addition to this, do we think that we need to add any type hint or we 
can add that later if required? \[0\]. 
{code}
allow ... restriction{String}(rep:glob, *.jsp, *.txt) 
restriction{Name}(rep:ntNames, sling:Folder) restriction{String}(rep:prefixes, 
sling)
allow ... restriction{Date}(my:custom, "13:00UTC, 23:59UTC")
allow ... restriction{Decimal}(my:custom2, 1, 2)
allow ... restriction{Name}(rep:ntNames, dam:Asset, nt:unstructured)
allow ... restriction(my:string, "It's \"quoted\"", "second string")
{code}





\[0\] 
https://docs.adobe.com/content/docs/en/spec/javax.jcr/javadocs/jcr-2.0/javax/jcr/Value.html?is-external=true


was (Author: nitin.nizhawan):
+1 , in addition to this, do we think that we need to add any type hint or we 
can add that later if required? \[0\]. 
{code}
allow ... restriction{String}(rep:glob, *.jsp, *.txt) restriction(rep:ntNames, 
sling:Folder) restriction(rep:prefixes, sling)
allow ... restriction{Date}(my:custom, "13:00UTC, 23:59UTC")
allow ... restriction{Decimal}(my:custom2, 1, 2)
allow ... restriction{Name}(rep:ntNames, dam:Asset, nt:unstructured)
allow ... restriction(my:string, "It's \"quoted\"", "second string")
{code}





\[0\] 
https://docs.adobe.com/content/docs/en/spec/javax.jcr/javadocs/jcr-2.0/javax/jcr/Value.html?is-external=true

> 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)

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

[Felix Meschberger (JIRA)]

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

Felix Meschberger edited comment on SLING-4753 at 12/22/16 7:37 AM:


Hmm, I am a bit concerned, yet, of course, late in the game.

IIRC we explicitly did *not* commit the changes to the Tenant before calling 
the customers to abort/roll-back the creation in case of problems. This change 
of course prevents that from happening.

I am also a bit concerned with the reasoning behind this change: AEM's 
PageManager.createPage method presumably clearing any changes before acting. I 
am not sure, we really want to support such questionable behaviour.

Also, while I agree that is not clearly spec-ed that changes are not persisted 
*before* calling the customizers, there is some indication in that:

* It is clearly stated in the TenantManager.setup method that changes are 
persisted *before* the method returns
* It is clearly stated with the TenantCustomer that ResourceResolver.commit 
must not be called

Particularly from the second statement we could deduce, that also 
ResourceResolver.revert should not be called, hence calling Session.refresh is 
equally unexpected and undesired.

Plus, even if the original creation is persisted, the behaviour could even 
revert any changes that a previous customizer applied. I really think, we 
should fix the problem not the symptom.

As such, the longer I think about it, the longer I have the impression, that 
this change should be reverted.

Last but not least: Do we really close issues before a release has been cut ?

/cc [~marett], [~amitgupt]


was (Author: fmeschbe):
Hmm, I am a bit concerned, yet, of course, late in the game.

IIRC we explicitly did *not* commit the changes to the Tenant before calling 
the customers to abort/roll-back the creation in case of problems. This change 
of course prevents that from happening.

I am also a bit concerned with the reasoning behind this change: AEM's 
PageManager.createPage method presumably clearing any changes before acting. I 
am not sure, we really want to support such questionable behaviour.

Also, while I agree that is not clearly spec-ed that changes are not persisted 
*before* calling the customizers, there is some indication in that:

* It is clearly stated in the TenantManager.setup method that changes are 
persisted *before* the method returns
* It is clearly stated with the TenantCustomer that ResourceResolver.commit 
must not be called

Particularly from the second statement we could deduce, that also 
ResourceResolver.revert should not be called, hence calling Session.refresh is 
equally unexpected and undesired.

As such, the longer I think about it, the longer I have the impression, that 
this change should be reverted.

Last but not least: Do we really close issues before a release has been cut ?

/cc [~marett], [~amitgupt]

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



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

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

[Felix Meschberger (JIRA)]

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

Felix Meschberger reopened SLING-4753:
--

Reopening as I think this is not done yet.

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



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

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

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-4753:
--

Hmm, I am a bit concerned, yet, of course, late in the game.

IIRC we explicitly did *not* commit the changes to the Tenant before calling 
the customers to abort/roll-back the creation in case of problems. This change 
of course prevents that from happening.

I am also a bit concerned with the reasoning behind this change: AEM's 
PageManager.createPage method presumably clearing any changes before acting. I 
am not sure, we really want to support such questionable behaviour.

Also, while I agree that is not clearly spec-ed that changes are not persisted 
*before* calling the customizers, there is some indication in that:

* It is clearly stated in the TenantManager.setup method that changes are 
persisted *before* the method returns
* It is clearly stated with the TenantCustomer that ResourceResolver.commit 
must not be called

Particularly from the second statement we could deduce, that also 
ResourceResolver.revert should not be called, hence calling Session.refresh is 
equally unexpected and undesired.

As such, the longer I think about it, the longer I have the impression, that 
this change should be reverted.

Last but not least: Do we really close issues before a release has been cut ?

/cc [~marett], [~amitgupt]

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



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

RE: [VOTE] Release Apache Sling Installer Console 1.0.2

[Stefan Seifert]

+1 

Re: svn commit: r1774871 - /sling/trunk/tooling/jenkins/create_jobs.groovy

[Oliver Lietz]

On Monday 19 December 2016 11:33:54 Robert Munteanu wrote:
> Hi Olli,

Hi Robert,

> I guess you just discovered why we don't allow SNAPSHOT dependencies to
> external projects in trunk :-)

no, I'm aware that external SNAPSHOTs are not accessible in our default build 
setup and disabled all Karaf build jobs _before_ using them.

> Rather than remove the jobs, please work on a branch if you have work
> that requires SNAPSHOT dependencies. That's what we did for the IDE
> tooling until FileVault was released, for instance.
> 
> This way both the Jenkins jobs and other contributors/committers
> besides yourself can build the Karaf integration.

Further development is blocked as Sling requires R6 Http features which are 
not available with Karaf 4.0. I have to use Karaf 4.1-SNAPSHOT and Pax Web 
6.0-SNAPSHOT, please see SLING-6411.

We hadn't a release yet and there are no other Sling developers moving 
Sling/Karaf forward – so I don't see a problem in disabling the build jobs.

Thanks,
O.

> Thanks,
> 
> Robert
> 
> On Sun, 2016-12-18 at 10:15 +, o...@apache.org wrote:
> > Author: olli
> > Date: Sun Dec 18 10:15:02 2016
> > New Revision: 1774871
> > 
> > URL: http://svn.apache.org/viewvc?rev=1774871=rev
> > Log:
> > SLING-6411 Upgrade Karaf to 4.1
> > 
> > disable Jenkins build jobs due to use of external snapshots
> > 
> > Modified:
> > sling/trunk/tooling/jenkins/create_jobs.groovy
> > 
> > Modified: sling/trunk/tooling/jenkins/create_jobs.groovy
> > URL: http://svn.apache.org/viewvc/sling/trunk/tooling/jenkins/create_
> > jobs.groovy?rev=1774871=1774870=1774871=diff
> > =
> > =
> > --- sling/trunk/tooling/jenkins/create_jobs.groovy (original)
> > +++ sling/trunk/tooling/jenkins/create_jobs.groovy Sun Dec 18
> > 10:15:02 2016
> > @@ -32,7 +32,7 @@ def modules = [
> >  ],
> >  [
> >  location: 'bundles/commons/log-webconsole'
> > -],
> > +],
> >  [
> >  location: 'bundles/commons/logservice'
> >  ],
> > @@ -593,24 +593,24 @@ def modules = [
> >  [
> >  location: "installer/providers/file"
> >  ],
> > -[
> > -location: 'karaf/org.apache.sling.karaf-distribution'
> > -],
> > -[
> > -location: 'karaf/org.apache.sling.karaf-features'
> > -],
> > -[
> > -location: 'karaf/org.apache.sling.karaf-integration-tests'
> > -],
> > -[
> > -location: 'karaf/org.apache.sling.karaf-launchpad-oak-tar-
> > integration-tests'
> > -],
> > -[
> > -location: 'karaf/org.apache.sling.karaf-repoinit'
> > -],
> > -[
> > -location: 'karaf/org.apache.sling.karaf-configs'
> > -],
> > +//[
> > +//location: 'karaf/org.apache.sling.karaf-distribution'
> > +//],
> > +//[
> > +//location: 'karaf/org.apache.sling.karaf-features'
> > +//],
> > +//[
> > +//location: 'karaf/org.apache.sling.karaf-integration-tests'
> > +//],
> > +//[
> > +//location: 'karaf/org.apache.sling.karaf-launchpad-oak-tar-
> > integration-tests'
> > +//],
> > +//[
> > +//location: 'karaf/org.apache.sling.karaf-repoinit'
> > +//],
> > +//[
> > +//location: 'karaf/org.apache.sling.karaf-configs'
> > +//],
> >  [
> >  location: 'launchpad/api',
> >  jdks: ["1.8"]
> > @@ -915,7 +915,7 @@ for more details''')
> >  // job is triggered first and we may end up with a
> >  // mix of Java 7 and Java 8 artifacts for projects which
> >  // use these 2 versions
> > -def extraGoalsParams = module.extraGoalsParams ?: "" 
> > +def extraGoalsParams = module.extraGoalsParams ?: ""
> >  goals( (deploy ? "-U clean deploy" : "-U clean verify")
> > + " " + extraGoalsParams)
> >  
> >  publishers {

RE: [VOTE] Release Apache Sling Testing ResourceResolver Mock 1.1.16

[Stefan Seifert]

+1

RE: [VOTE] Release Apache Sling Commons FSClassLoader 1.0.4

[Stefan Seifert]

+1 

Re: Skipping structural/security resources from user content

[Bertrand Delacretaz]

On Tue, Dec 20, 2016 at 2:55 PM, Timothee Maret  wrote:
> ...Going the 2. route may be better, but we'd need support for specifying glob
> restrictions in repoinit

Supporting ACL restrictions in repoinit would be good,
https://issues.apache.org/jira/browse/SLING-6422 has recently been
created about that.

I have just added a suggested syntax, feedback is welcome.

-Bertrand

[jira] [Commented] (SLING-4541) Provide an extensive test suite for the JCR content loader

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-4541:


Yes I think we might close this as won't fix for now, in the meantime IIRC the 
content loader tests have been improved but maybe not up to the level that was 
envisioned here.

> Provide an extensive test suite for the JCR content loader
> --
>
> Key: SLING-4541
> URL: https://issues.apache.org/jira/browse/SLING-4541
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Affects Versions: JCR ContentLoader 2.1.10
>Reporter: Radu Cotescu
>Assignee: Petr Shypila
> Fix For: JCR ContentLoader 2.2.0
>
> Attachments: week-4-completed.patch, week-4_first_part.patch, 
> week2-part1-pathentry.patch, week2-part2-defaultcontentcreator.patch, 
> week2-part3-single-jcrmock-test.patch, week3.patch, week4-5.patch
>
>
> The JCR content loader is a sensible bundle. An extensive IT suite should be 
> written to make sure that code changes don't affect core functionality.



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

Re: Snapshot dependencies to external projects (was: svn commit: r1775432 - /sling/trunk/karaf/org.apache.sling.karaf-integration-tests/pom.xml)

[Oliver Lietz]

On Wednesday 21 December 2016 16:33:09 Robert Munteanu wrote:
> Olli,
> 
> Please, stop using dependencies to external projects in trunk. It makes
> projects not build out of the box and unable to release without doing
> work which is out of our control.
> 
> You've done this with Karaf and then with Pax-Exam.
> 
> Working on branches is a great way to allow everyone else to build and
> work on the projects until we get external releases.
> 
> If you believe that is the wrong approach, please let us know, but
> ignoring the policy is not that productive :-)

See my answer to your first mail.

O.

> Thanks,
> 
> Robert
> 
> On Wed, 2016-12-21 at 14:21 +, o...@apache.org wrote:
> > Author: olli
> > Date: Wed Dec 21 14:21:31 2016
> > New Revision: 1775432
> > 
> > URL: http://svn.apache.org/viewvc?rev=1775432=rev
> > Log:
> > SLING-6425 Update Pax Exam to 4.10
> > 
> > use 4.10.0-SNAPSHOT
> > 
> > Modified:
> > sling/trunk/karaf/org.apache.sling.karaf-integration-
> > tests/pom.xml
> > 
> > Modified: sling/trunk/karaf/org.apache.sling.karaf-integration-
> > tests/pom.xml
> > URL: http://svn.apache.org/viewvc/sling/trunk/karaf/org.apache.sling.
> > karaf-integration-
> > tests/pom.xml?rev=1775432=1775431=1775432=diff
> > =
> > =
> > --- sling/trunk/karaf/org.apache.sling.karaf-integration-
> > tests/pom.xml (original)
> > +++ sling/trunk/karaf/org.apache.sling.karaf-integration-
> > tests/pom.xml Wed Dec 21 14:21:31 2016
> > @@ -38,7 +38,7 @@
> >
> >  2.13.1 > sion>
> >  4.1.0-
> > SNAPSHOT
> > -4.9.2
> > +4.10.0-
> > SNAPSHOT
> >
> >  
> >

Re: svn commit: r1774871 - /sling/trunk/tooling/jenkins/create_jobs.groovy

[Robert Munteanu]

On Wed, 2016-12-21 at 15:46 +0100, Oliver Lietz wrote:
> On Monday 19 December 2016 11:33:54 Robert Munteanu wrote:
> > Hi Olli,
> 
> Hi Robert,
> 
> > I guess you just discovered why we don't allow SNAPSHOT
> > dependencies to
> > external projects in trunk :-)
> 
> no, I'm aware that external SNAPSHOTs are not accessible in our
> default build 
> setup and disabled all Karaf build jobs _before_ using them.

Right, that does indeed save us the trouble of being flooded by
notifications, which is appreciated.

> 
> > Rather than remove the jobs, please work on a branch if you have
> > work
> > that requires SNAPSHOT dependencies. That's what we did for the IDE
> > tooling until FileVault was released, for instance.
> > 
> > This way both the Jenkins jobs and other contributors/committers
> > besides yourself can build the Karaf integration.
> 
> Further development is blocked as Sling requires R6 Http features
> which are 
> not available with Karaf 4.0. I have to use Karaf 4.1-SNAPSHOT and
> Pax Web 
> 6.0-SNAPSHOT, please see SLING-6411.

Ack

> 
> We hadn't a release yet and there are no other Sling developers
> moving 
> Sling/Karaf forward – so I don't see a problem in disabling the build
> jobs.

Ack. My point was not about the build jobs, it's about keeping trunk in
a buildable state at all times.

I understand your argument about no release and no other contributors.
However, we don't know who is trying to build the SVN repository and
who is interested in the Karaf integration. They might try building it
only to have it fail due to missing dependencies.

I like simple rules :-) one of those is having trunk always build.

What would be the disadvantage of working with SNAPSHOTs in branches
and merging back to trunk once we have releases of the respective
projects?

Thanks,

Robert

> 
> Thanks,
> O.
> 
> > Thanks,
> > 
> > Robert
> > 
> > On Sun, 2016-12-18 at 10:15 +, o...@apache.org wrote:
> > > Author: olli
> > > Date: Sun Dec 18 10:15:02 2016
> > > New Revision: 1774871
> > > 
> > > URL: http://svn.apache.org/viewvc?rev=1774871=rev
> > > Log:
> > > SLING-6411 Upgrade Karaf to 4.1
> > > 
> > > disable Jenkins build jobs due to use of external snapshots
> > > 
> > > Modified:
> > > sling/trunk/tooling/jenkins/create_jobs.groovy
> > > 
> > > Modified: sling/trunk/tooling/jenkins/create_jobs.groovy
> > > URL: http://svn.apache.org/viewvc/sling/trunk/tooling/jenkins/cre
> > > ate_
> > > jobs.groovy?rev=1774871=1774870=1774871=diff
> > > =
> > > 
> > > =
> > > --- sling/trunk/tooling/jenkins/create_jobs.groovy (original)
> > > +++ sling/trunk/tooling/jenkins/create_jobs.groovy Sun Dec 18
> > > 10:15:02 2016
> > > @@ -32,7 +32,7 @@ def modules = [
> > >  ],
> > >  [
> > >  location: 'bundles/commons/log-webconsole'
> > > -],
> > > +],
> > >  [
> > >  location: 'bundles/commons/logservice'
> > >  ],
> > > @@ -593,24 +593,24 @@ def modules = [
> > >  [
> > >  location: "installer/providers/file"
> > >  ],
> > > -[
> > > -location: 'karaf/org.apache.sling.karaf-distribution'
> > > -],
> > > -[
> > > -location: 'karaf/org.apache.sling.karaf-features'
> > > -],
> > > -[
> > > -location: 'karaf/org.apache.sling.karaf-integration-
> > > tests'
> > > -],
> > > -[
> > > -location: 'karaf/org.apache.sling.karaf-launchpad-oak-
> > > tar-
> > > integration-tests'
> > > -],
> > > -[
> > > -location: 'karaf/org.apache.sling.karaf-repoinit'
> > > -],
> > > -[
> > > -location: 'karaf/org.apache.sling.karaf-configs'
> > > -],
> > > +//[
> > > +//location: 'karaf/org.apache.sling.karaf-distribution'
> > > +//],
> > > +//[
> > > +//location: 'karaf/org.apache.sling.karaf-features'
> > > +//],
> > > +//[
> > > +//location: 'karaf/org.apache.sling.karaf-integration-
> > > tests'
> > > +//],
> > > +//[
> > > +//location: 'karaf/org.apache.sling.karaf-launchpad-oak-
> > > tar-
> > > integration-tests'
> > > +//],
> > > +//[
> > > +//location: 'karaf/org.apache.sling.karaf-repoinit'
> > > +//],
> > > +//[
> > > +//location: 'karaf/org.apache.sling.karaf-configs'
> > > +//],
> > >  [
> > >  location: 'launchpad/api',
> > >  jdks: ["1.8"]
> > > @@ -915,7 +915,7 @@ for more details''')
> > >  // job is triggered first and we may end up with a
> > >  // mix of Java 7 and Java 8 artifacts for projects
> > > which
> > >  // use these 2 versions
> > > -def extraGoalsParams = module.extraGoalsParams ?:
> > > "" 
> > > +def extraGoalsParams = module.extraGoalsParams ?: ""
> > >  goals( (deploy ? "-U clean deploy" : "-U clean
> > > verify")
> > > + " " + extraGoalsParams)
> > >  
> > >  publishers {
> 
> 

Re: Snapshot dependencies to external projects (was: svn commit: r1775432 - /sling/trunk/karaf/org.apache.sling.karaf-integration-tests/pom.xml)

[Robert Munteanu]

On Wed, 2016-12-21 at 15:50 +0100, Oliver Lietz wrote:
> On Wednesday 21 December 2016 16:33:09 Robert Munteanu wrote:
> > Olli,
> > 
> > Please, stop using dependencies to external projects in trunk. It
> > makes
> > projects not build out of the box and unable to release without
> > doing
> > work which is out of our control.
> > 
> > You've done this with Karaf and then with Pax-Exam.
> > 
> > Working on branches is a great way to allow everyone else to build
> > and
> > work on the projects until we get external releases.
> > 
> > If you believe that is the wrong approach, please let us know, but
> > ignoring the policy is not that productive :-)
> 
> See my answer to your first mail.

Ack, let's discuss there.

  https://lists.apache.org/thread.html/f7b40d013e3edfe94bd4650a047ab3d9
6ba37128a3b570c51525e26e@%3Cdev.sling.apache.org%3E

Robert

> 
> O.
> 
> > Thanks,
> > 
> > Robert
> > 
> > On Wed, 2016-12-21 at 14:21 +, o...@apache.org wrote:
> > > Author: olli
> > > Date: Wed Dec 21 14:21:31 2016
> > > New Revision: 1775432
> > > 
> > > URL: http://svn.apache.org/viewvc?rev=1775432=rev
> > > Log:
> > > SLING-6425 Update Pax Exam to 4.10
> > > 
> > > use 4.10.0-SNAPSHOT
> > > 
> > > Modified:
> > > sling/trunk/karaf/org.apache.sling.karaf-integration-
> > > tests/pom.xml
> > > 
> > > Modified: sling/trunk/karaf/org.apache.sling.karaf-integration-
> > > tests/pom.xml
> > > URL: http://svn.apache.org/viewvc/sling/trunk/karaf/org.apache.sl
> > > ing.
> > > karaf-integration-
> > > tests/pom.xml?rev=1775432=1775431=1775432=diff
> > > =
> > > 
> > > =
> > > --- sling/trunk/karaf/org.apache.sling.karaf-integration-
> > > tests/pom.xml (original)
> > > +++ sling/trunk/karaf/org.apache.sling.karaf-integration-
> > > tests/pom.xml Wed Dec 21 14:21:31 2016
> > > @@ -38,7 +38,7 @@
> > >    
> > >  2.13.1 > > .ver
> > > sion>
> > >  4.1.0-
> > > SNAPSHOT
> > > -4.9.2 > > n>
> > > +4.10.0-
> > > SNAPSHOT
> > >    
> > >  
> > >    
> 
> 

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

[Robert Munteanu]

On Wed, 2016-12-21 at 14:41 +, Stefan Seifert wrote:
> Please vote to approve this release:

+1

Robert

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

Re: svn commit: r1774871 - /sling/trunk/tooling/jenkins/create_jobs.groovy

[Bertrand Delacretaz]

On Wed, Dec 21, 2016 at 4:02 PM, Robert Munteanu  wrote:
> ...What would be the disadvantage of working with SNAPSHOTs in branches
> and merging back to trunk once we have releases of the respective
> projects?...

IMO the problem is that this makes that work essentially "invisible"
to others as we do not usually work with svn branches.

We could use instead a Maven profile in the main pom for such modules
that require external snapshots. Disabled by default, so the trunk
builds and one can easily re-enable those modules as needed.

-Bertrand

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

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-6422:


The first step is to define a suitable syntax in the repoinit language for 
those restrictions.

So far the language only supports an optional "nodetypes" clause (see test [1]) 
which is not implemented by the JCR repoinit module, so has no effect.

I have little experience with those restrictions but as per [2] it looks like 
each restriction is expressed with a name and 1..N values. And custom 
restrictions can be created, so the syntax must be flexible.

Here's a first set of examples of what those restriction definitions could look 
like in repoinit, comments are welcome. I think it makes sense to define 
keywords for the common restriction types (nodetypes, glob, namespaces) as well 
as a generic syntax for other built-in and custom restrictions.

In these examples, {{allow ...}} represents repoinit ACL definitions with the 
existing syntax

{code}
# explicit form for common restriction types
allow ... nodetypes sling:Folder, my:Type
allow ... nodetypes nt:file glob *.jsp
allow ... glob *.jsp
allow ... namespaces http://sling.apache.org/nt glob *.html

# generic form for any restriction type
allow ... restriction(rep:glob, *.jsp, *.txt) restriction(rep:ntNames, 
sling:Folder) restriction(rep:prefixes, sling)
allow ... restriction(my:custom, "13:00UTC, 23:59UTC")
allow ... restriction(my:string, "It's \"quoted\"", "second string")
{code}

[1] 
https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/repoinit/parser/src/test/resources/testcases/test-30.txt
[2] 
http://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html

> 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)

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

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz edited comment on SLING-6422 at 12/21/16 2:47 PM:
--

The first step is to define a suitable syntax in the repoinit language for 
those restrictions.

So far the language only supports an optional "nodetypes" clause (see test [1]) 
which is not implemented by the JCR repoinit module, so has no effect.

I have little experience with those restrictions but as per [2] it looks like 
each restriction is expressed with a name and 1..N values. And custom 
restrictions can be created, so the syntax must be flexible.

Here's a first set of examples of what those restriction definitions could look 
like in repoinit, comments are welcome. I think it makes sense to define 
keywords for the common restriction types (nodetypes, glob, namespaces) as well 
as a generic syntax for other built-in and custom restrictions.

In these examples, {{allow ...}} represents repoinit ACL definitions with the 
existing syntax

{code}
# explicit form for common restriction types
allow ... nodetypes sling:Folder, my:Type
allow ... nodetypes nt:file glob *.jsp
allow ... glob *.jsp
allow ... namespaces http://sling.apache.org/nt glob *.html

# generic form for any restriction type
allow ... restriction(rep:glob, *.jsp, *.txt) restriction(rep:ntNames, 
sling:Folder) restriction(rep:prefixes, sling)
allow ... restriction(my:custom, "13:00UTC, 23:59UTC")
allow ... restriction(my:string, "It's \"quoted\"", "second string")
{code}

Note that supporting just the generic {{restriction(name, values)}} form would 
be simpler at the cost of breaking parser compatibility with the existing 
{{nodetypes}} option. However, as that option has currently no effect in the 
only implementation that we have (our repoinit JCR module), we might keep that 
{{nodetypes}} option in the language, have it do nothing as it currently does 
and log a deprecation warning when it's used.

[1] 
https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/repoinit/parser/src/test/resources/testcases/test-30.txt
[2] 
http://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html


was (Author: bdelacretaz):
The first step is to define a suitable syntax in the repoinit language for 
those restrictions.

So far the language only supports an optional "nodetypes" clause (see test [1]) 
which is not implemented by the JCR repoinit module, so has no effect.

I have little experience with those restrictions but as per [2] it looks like 
each restriction is expressed with a name and 1..N values. And custom 
restrictions can be created, so the syntax must be flexible.

Here's a first set of examples of what those restriction definitions could look 
like in repoinit, comments are welcome. I think it makes sense to define 
keywords for the common restriction types (nodetypes, glob, namespaces) as well 
as a generic syntax for other built-in and custom restrictions.

In these examples, {{allow ...}} represents repoinit ACL definitions with the 
existing syntax

{code}
# explicit form for common restriction types
allow ... nodetypes sling:Folder, my:Type
allow ... nodetypes nt:file glob *.jsp
allow ... glob *.jsp
allow ... namespaces http://sling.apache.org/nt glob *.html

# generic form for any restriction type
allow ... restriction(rep:glob, *.jsp, *.txt) restriction(rep:ntNames, 
sling:Folder) restriction(rep:prefixes, sling)
allow ... restriction(my:custom, "13:00UTC, 23:59UTC")
allow ... restriction(my:string, "It's \"quoted\"", "second string")
{code}

[1] 
https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/repoinit/parser/src/test/resources/testcases/test-30.txt
[2] 
http://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html

> 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)

[jira] [Resolved] (SLING-6426) Use Felix Configuration Admin format for all configurations

[Oliver Lietz (JIRA)]

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

Oliver Lietz resolved SLING-6426.
-
Resolution: Done

[r1775435|https://svn.apache.org/r1775435]
[r1775436|https://svn.apache.org/r1775436]
[r1775438|https://svn.apache.org/r1775438]
[r1775439|https://svn.apache.org/r1775439]
[r1775440|https://svn.apache.org/r1775440]

> Use Felix Configuration Admin format for all configurations
> ---
>
> Key: SLING-6426
> URL: https://issues.apache.org/jira/browse/SLING-6426
> Project: Sling
>  Issue Type: Task
>  Components: Karaf
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Karaf Features 0.2.0, Karaf Integration Tests 0.2.0, 
> Karaf Distribution 0.2.0, Karaf Configs 0.2.0
>
>




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

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

[Carsten Ziegeler]

+1


 

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

[jira] [Commented] (SLING-6305) LoginAdminWhitelist configuration is applied too late

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-6305:
---

bq. I would suggest that the caconfig ITs move to a config fragment as well, to 
be consistent.
did this in rev. 1775466

> LoginAdminWhitelist configuration is applied too late
> -
>
> Key: SLING-6305
> URL: https://issues.apache.org/jira/browse/SLING-6305
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Affects Versions: JCR Base 2.4.2
>Reporter: Robert Munteanu
>
> I've been getting some local failures with the launchpad/testing module, and 
> I noticed that the {{org.apache.sling.junit.scriptable}} bundle was not 
> whitelisted for loginAdministrative:
> {noformat}19.11.2016 10:40:54.063 *ERROR* [CM Event Dispatcher (Fire 
> ConfigurationEvent: 
> pid=org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)] 
> org.apache.sling.junit.scriptable 
> [org.apache.sling.junit.scriptable.ScriptableTestsProvider(204)] The activate 
> method has thrown an exception (javax.jcr.LoginException: Bundle 
> org.apache.sling.junit.scriptable is NOT whitelisted)
> javax.jcr.LoginException: Bundle org.apache.sling.junit.scriptable is NOT 
> whitelisted{noformat}
> The configuration was correct, so I added a little debug information in the 
> {{org.apache.sling.jcr.base}} bundle to print the whitelist regexp in the 
> same line as the whitelisted bundles. I noticed then that the component is 
> activated several times, with only the last one actually setting the 
> configuration
> {noformat}19.11.2016 10:40:51.630 *INFO* [CM Event Dispatcher (Fire 
> ConfigurationEvent: 
> pid=org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)] 
> org.apache.sling.jcr.base.internal.LoginAdminWhitelist bypassWhitelist=false, 
> whitelisted BSNs(17)=[org.apache.sling.discovery.base, 
> org.apache.sling.discovery.commons, org.apache.sling.discovery.oak, 
> org.apache.sling.extensions.webconsolesecurityprovider, 
> org.apache.sling.i18n, org.apache.sling.installer.provider.jcr, 
> org.apache.sling.jcr.base, org.apache.sling.jcr.contentloader, 
> org.apache.sling.jcr.davex, org.apache.sling.jcr.jackrabbit.usermanager, 
> org.apache.sling.jcr.oak.server, org.apache.sling.jcr.repoinit, 
> org.apache.sling.jcr.resource, org.apache.sling.jcr.webconsole, 
> org.apache.sling.resourceresolver, org.apache.sling.servlets.post, 
> org.apache.sling.servlets.resolver], whitelistRegexp=null
> 19.11.2016 10:40:55.150 *INFO* [CM Event Dispatcher (Fire ConfigurationEvent: 
> pid=org.apache.jackrabbit.oak.security.authentication.AuthenticationConfigurationImpl)]
>  org.apache.sling.jcr.base.internal.LoginAdminWhitelist 
> bypassWhitelist=false, whitelisted BSNs(17)=[org.apache.sling.discovery.base, 
> org.apache.sling.discovery.commons, org.apache.sling.discovery.oak, 
> org.apache.sling.extensions.webconsolesecurityprovider, 
> org.apache.sling.i18n, org.apache.sling.installer.provider.jcr, 
> org.apache.sling.jcr.base, org.apache.sling.jcr.contentloader, 
> org.apache.sling.jcr.davex, org.apache.sling.jcr.jackrabbit.usermanager, 
> org.apache.sling.jcr.oak.server, org.apache.sling.jcr.repoinit, 
> org.apache.sling.jcr.resource, org.apache.sling.jcr.webconsole, 
> org.apache.sling.resourceresolver, org.apache.sling.servlets.post, 
> org.apache.sling.servlets.resolver], whitelistRegexp=null
> 19.11.2016 10:40:56.200 *INFO* [CM Event Dispatcher (Fire ConfigurationEvent: 
> pid=org.apache.jackrabbit.oak.security.user.UserConfigurationImpl)] 
> org.apache.sling.jcr.base.internal.LoginAdminWhitelist bypassWhitelist=false, 
> whitelisted BSNs(17)=[org.apache.sling.discovery.base, 
> org.apache.sling.discovery.commons, org.apache.sling.discovery.oak, 
> org.apache.sling.extensions.webconsolesecurityprovider, 
> org.apache.sling.i18n, org.apache.sling.installer.provider.jcr, 
> org.apache.sling.jcr.base, org.apache.sling.jcr.contentloader, 
> org.apache.sling.jcr.davex, org.apache.sling.jcr.jackrabbit.usermanager, 
> org.apache.sling.jcr.oak.server, org.apache.sling.jcr.repoinit, 
> org.apache.sling.jcr.resource, org.apache.sling.jcr.webconsole, 
> org.apache.sling.resourceresolver, org.apache.sling.servlets.post, 
> org.apache.sling.servlets.resolver], whitelistRegexp=null
> 19.11.2016 10:40:57.190 *INFO* [CM Event Dispatcher (Fire ConfigurationEvent: 
> pid=org.apache.jackrabbit.oak.spi.security.user.action.DefaultAuthorizableActionProvider)]
>  org.apache.sling.jcr.base.internal.LoginAdminWhitelist 
> bypassWhitelist=false, whitelisted BSNs(17)=[org.apache.sling.discovery.base, 
> org.apache.sling.discovery.commons, org.apache.sling.discovery.oak, 
> org.apache.sling.extensions.webconsolesecurityprovider, 
> org.apache.sling.i18n, 

Re: [VOTE] Release Apache Sling Commons FSClassLoader 1.0.4

[Robert Munteanu]

On Wed, 2016-12-21 at 12:19 +0100, Carsten Ziegeler wrote:
> Please vote to approve this release:

+1

Robert

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

Re: [VOTE] Release Apache Sling Installer Console 1.0.2

[Robert Munteanu]

On Wed, 2016-12-21 at 12:18 +0100, Carsten Ziegeler wrote:
> Please vote to approve this release:

+1

Robert

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

Re: svn commit: r1774871 - /sling/trunk/tooling/jenkins/create_jobs.groovy

[Oliver Lietz]

On Wednesday 21 December 2016 16:16:36 Bertrand Delacretaz wrote:
> On Wed, Dec 21, 2016 at 4:02 PM, Robert Munteanu  wrote:
> > ...What would be the disadvantage of working with SNAPSHOTs in branches
> > and merging back to trunk once we have releases of the respective
> > projects?...
> 
> IMO the problem is that this makes that work essentially "invisible"
> to others as we do not usually work with svn branches.

Good point.

> We could use instead a Maven profile in the main pom for such modules
> that require external snapshots. Disabled by default, so the trunk
> builds and one can easily re-enable those modules as needed.

That does not work unfortunately. The Sling Karaf modules will fail with 
latest Sling releases because of missing R6 Http support.
I stopped updating some dependencies (using the Http Whiteboard, e.g. Engine, 
Rewriter, i18n) but the gap is getting bigger and bigger every day and hard to 
catch up. Other parts of Sling are also moving fast and need special attention 
(e.g. Login Admin Whitelist and system users).

I'm close again (test with Oak Mongo is broken and org.apache.sling.karaf-
launchpad-oak-tar-integration-tests has issues) at the cost of not having a 
Jenkins build until all required upstream projects are released.

O.

> -Bertrand

[jira] [Resolved] (SLING-6192) Remove workaround for KARAF-4707

[Oliver Lietz (JIRA)]

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

Oliver Lietz resolved SLING-6192.
-
Resolution: Done

> Remove workaround for KARAF-4707
> 
>
> Key: SLING-6192
> URL: https://issues.apache.org/jira/browse/SLING-6192
> Project: Sling
>  Issue Type: Task
>  Components: Karaf
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>Priority: Minor
> Fix For: Karaf Features 0.2.0, Karaf Distribution 0.2.0
>
>
> workaround added in [r1766789|https://svn.apache.org/r1766789] and 
> [r1766790|https://svn.apache.org/r1766790]



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