Re: What to do about cancelled releases in Jira?

[Julian Sedding]

+1

Regards
Julian

On Monday, November 28, 2016, Stefan Seifert  wrote:

> >My suggestion would be to:
> >
> >- move all issues from version N to version N+2
> >- delete Jira version N
>
> +1
>

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

Stefan Seifert commented on SLING-6305:
---

a good test object to test this problem seems to be this integration test:
https://github.com/apache/sling/tree/trunk/contrib/extensions/contextaware-config/integration-tests

on linux-based machines (e.g. ubuntu/trusty64) it seems to fail permanently 
with Java 8 (e.g. 1.8.0_92). error is always
"Bundle org.apache.sling.junit.core is NOT whitelisted"
although it is correctly whitelisted via regex in configuration.

on a windows 10 machine with exactly the same Java 8 version (1.8.0_92) the 
error does _not_ occur - it is always running fine there!

> 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: Launchpad stable and launchpad unstable

[Sandro Boehme]

- the launchpad maintained in trunk should always be the "stable" launchpad, 
referencing only released dependencies of the sling bundles and oft the integration tests 
project
If I checkout and build the latest trunk I would expect that the built 
projects are available at the runtime of the server. This way I can set 
breakpoints in the debugger, examine the inner workings and maybe 
provide an improvement.
If the launchpad provides only stable versions I would always first have 
to switch to the snapshot versions using the script and I currently I 
can't do that, right?


Best,

Sandro

PS: Thanks Bertrand for pointing me to this discussion!

[jira] [Created] (SLING-6338) Context-Aware Config: Properly support nested configuration classes in SPI and Mangement API

[Stefan Seifert (JIRA)]

Stefan Seifert created SLING-6338:
-

 Summary: Context-Aware Config: Properly support nested 
configuration classes in SPI and Mangement API
 Key: SLING-6338
 URL: https://issues.apache.org/jira/browse/SLING-6338
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Stefan Seifert
Assignee: Stefan Seifert
Priority: Minor
 Fix For: Context-Aware Configuration SPI 1.2.0, Context-Aware 
Configuration Impl 1.2.0


currently nested configuration classes are supported in the configuration 
resolver, but are not properly supported in the 
AnnotationClassConfigurationMetadataProvider SPI implementation and the 
Management API implementation.



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

Re: trunk build does not work // was: mountByFS does not work

[Robert Munteanu]

On Fri, 2016-11-18 at 00:22 +0100, Sandro Boehme wrote:
> Hi Julian,
> 
> I like the idea of individual Jenkins jobs for the reasons you
> pointed out!
> If we would have a "nightly" build (whatever time that would be) we 
> could link it at the Getting and building Sling page. We could write 
> there that in case the build does currently not work (e.g. because
> there 
> is some bigger work in progress or a plain oversight) they could have
> a 
> look at what revision actually does work and use that.

I've updated the building Sling docs to reflect how we expect things to
work now, see especially

  http://sling.apache.org/documentation/development/getting-and-buildin
g-sling.html#tldr-short-form-build-run-instructions

  http://sling.apache.org/documentation/development/getting-and-buildin
g-sling.html#with-the-maven-command-line-tool

Hopefully that makes more sense now.

Robert

> People who would stop trying Sling because of a non working build
> and 
> who would not ask at the mailing list would then have a chance to
> get 
> the build working anyways.
> WDYT?
> 
> Best,
> 
> Sandro
> 
> Am 17.11.16 um 14:53 schrieb Julian Sedding:
> > Hi Sandro
> > 
> > You are right. However, the full build on Jenkins failed too often.
> > Partly due to issues or flaky tests in Sling, partly due to e.g.
> > infrastructure issues. This made the Jenkins builds almost useless,
> > because chances were that it weren't your changes that made the
> > build
> > fail.
> > 
> > Therefore Robert added configurations to run each module
> > independently
> > on Jenkins. That gives us a better overview of which modules are ok
> > and which ones aren't. However, we lost the full build in the
> > process.
> > Maybe we could add it back and run it once every night. WDYT,
> > Robert?
> > 
> > Regards
> > Julian
> > 
> > 
> > 
> > On Wed, Nov 16, 2016 at 10:02 PM, Sandro Boehme  > de> wrote:
> > > > According to our Jenkins job
> > > > 
> > > >   https://builds.apache.org/job/sling-launchpad-builder-1.8/
> > > > 
> > > > the launchpad should work without issues.
> > > > 
> > > > A couple of additional questions:
> > > > 
> > > > - what Java version do you use for building and running Sling?
> > > > - what happens if you try to build the project with "-U", to
> > > > force
> > > > updating the snapshots? The command would then be mvn -U clean
> > > > verify
> > > > 
> > > > Robert
> > > 
> > > According to the "Getting and Building Sling" page [1] I just did
> > > "svn co
> > > ...", "mvn clean install" (-DskipTests) and "java -jar ..." and
> > > expected to
> > > be able to build and use Sling. But if we don't have a Jenkins
> > > job that does
> > > the same a committer will probably more easily overlook if he
> > > breaks the
> > > build for people who are trying out Sling. But I guess you know
> > > that and I
> > > have the feeling that I miss something here.
> > > 
> > > I use Java 8. I didn't try -U but Julians changes fixed the
> > > problem for me.
> > > 
> > > 
> > > [1] -
> > > http://sling.apache.org/documentation/development/getting-and-bui
> > > lding-sling.html
> > > 
> > > Best,
> > > 
> > > Sandro
> 
> 

Re: integration test fail due to LoginAdminWhitelist

[Robert Munteanu]

On Mon, 2016-11-28 at 21:23 +, Stefan Seifert wrote:
> perhaps there is a timing issue that loads the OSGi config for
> LoginAdminWhitelist too late - and for some reasons only on unix
> environments?!

That would be SLING-6305 [1] I guess. 

Any more data points about narrowing the cause down would be welcome.
For me it's Linux + Java 8 ( Java 7 works fine ) but for some reason (
different setup? faster machine? ) the launchpad/testing job works on
Jenkins.

Robert

[1]: https://issues.apache.org/jira/browse/SLING-6305

RE: integration test fail due to LoginAdminWhitelist

[Stefan Seifert]

thanks, great!

unfortuantely the integration tests are now failing again. but your changes to 
org.apache.sling.junit.core do not seem to be the reason - even when rolling 
back to the latest snapshot before it's failing. same problem as before - 
"Bundle org.apache.sling.junit.core is NOT whitelisted", although it's 
whitelisted and the regex is excaped correctly. seemed to be pure luck that it 
worked 2 times during this day, all other runs just failed on jenkins.

locally i can reproduce:
- always runs fine on windows 10/java 8
- always fails in a vagrant box with ubuntu/java 8

perhaps there is a timing issue that loads the OSGi config for 
LoginAdminWhitelist too late - and for some reasons only on unix environments?!

stefan

>-Original Message-
>From: Julian Sedding [mailto:jsedd...@gmail.com]
>Sent: Monday, November 28, 2016 6:45 PM
>To: Sling Developers List
>Subject: Re: integration test fail due to LoginAdminWhitelist
>
>Hi Stefan
>
>When analyzing the issue I noticed that the test was waiting for the
>ResourceResolverFactory service to become available. However, it is
>possible that the test starts before even all bundles in the
>repository are active (SLING-6334[0]). Thus, especially on slow
>systems, the likelihood of a timeout (10s by default) when waiting for
>a service is increased. Furthermore, the system was polled for the
>presence of the service every 50ms. In my local tests that seemed to
>slow down the service becoming available by up to 3 seconds. Waiting
>for the service can be done with a ServiceTracker instead of polling
>(SLING-6335[1]).
>
>After applying my changes, the time from when the test starts (after
>all bundles are active) and the time the ResourceResolverFactory
>becomes available went down from 10+ to ~3 seconds.
>
>Regards
>Julian
>
>[0] https://issues.apache.org/jira/browse/SLING-6334
>[1] https://issues.apache.org/jira/browse/SLING-6335
>
>
>On Mon, Nov 28, 2016 at 2:02 PM, Stefan Seifert 
>wrote:
>> this fix of my problem was finally quite simple: i just had to double the
>backslashes to escape them [1], and then it works, and the generated
>slingstart.txt contains the same string as before.
>>
>> what is still strange that on my system (windows 10 machine with java 8)
>it worked without proper escaping, whereas it failed on Jenkins and on
>julians machine.
>>
>> stefan
>>
>> [1]
>https://github.com/apache/sling/blob/trunk/contrib/extensions/contextaware-
>config/integration-tests/src/main/provisioning/sling.txt#L26
>>
>>
>>
>>>-Original Message-
>>>From: Konrad Windszus [mailto:konra...@gmx.de]
>>>Sent: Monday, November 28, 2016 1:06 PM
>>>To: dev@sling.apache.org
>>>Subject: Re: integration test fail due to LoginAdminWhitelist
>>>
>>>One last addendum:
>>>Since quoted-string in RFC 2616 has some known bugs
>>>(http://stackoverflow.com/questions/7886782/what-is-the-exact-syntax-and-
>>>semantics-of-a-quoted-string-in-the-http1-1-rfc2616) we should only refer
>>>to https://tools.ietf.org/html/rfc7230#section-3.2.6 instead (in the
>>>documentation).
>>>
 On 28 Nov 2016, at 12:45, Stefan Seifert 
>wrote:


> Your current configuration looks like this:
> whitelist.bundles.regexp="^org\.apache\.sling\.junit(\..*)?$"
>
> Inside target/slingstart.txt this becomes:
> whitelist.bundles.regexp="^org.apache.sling.junit(..*)?$"
>
> Note: all slashes have disappeared.

 this is strange, yes.
 the same escaping problem happens on my local machine - but there the
>>>integration test passes.
 you could reproduce the problem on your machine?

 as a workaround i will simplify the regex and remove the backslashes.

 i think we have currently no precise documentation of the sling
>>>provisioning file format esp. regarding escaping rules. on [1] only some
>>>details of the embedded osgi configuration format are documented.

 stefan

 [1] https://sling.apache.org/documentation/development/slingstart.html

>>>
>>
>>

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

[Stefan Seifert]

+1

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

[Robert Munteanu]

On Mon, 2016-11-28 at 22:32 +0200, Robert Munteanu wrote:
> Please vote to approve this release:

+1

Robert

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

[VOTE] Release Apache Sling JCR Installer version 3.1.22

[Robert Munteanu]

Hi,

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

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

You can use this UNIX script to download the release and verify the
signatures:
http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh

Usage:
sh check_staged_release.sh 1585 /tmp/sling-staging

Please vote to approve this release:

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

This majority vote is open for at least 72 hours.

Robert

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

RE: What to do about cancelled releases in Jira?

[Stefan Seifert]

>My suggestion would be to:
>
>- move all issues from version N to version N+2
>- delete Jira version N

+1

What to do about cancelled releases in Jira?

[Robert Munteanu]

Hi,

We do not have anything written down about what happens to Jira issues
fixed in version N, where N is cancelled.

My suggestion would be to:

- move all issues from version N to version N+2
- delete Jira version N

Thoughts?

Robert

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

[Robert Munteanu (JIRA)]

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

Robert Munteanu updated SLING-5519:
---
Fix Version/s: (was: JCR Installer 3.1.20)
   JCR Installer 3.1.22

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



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

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

[Robert Munteanu (JIRA)]

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

Robert Munteanu updated SLING-5228:
---
Fix Version/s: (was: JCR Installer 3.1.20)
   JCR Installer 3.1.22

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



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

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

[Robert Munteanu (JIRA)]

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

Robert Munteanu updated SLING-6326:
---
Fix Version/s: (was: JCR Installer 3.1.20)
   JCR Installer 3.1.22

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



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

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

[Robert Munteanu (JIRA)]

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

Robert Munteanu updated SLING-6274:
---
Fix Version/s: (was: JCR Installer 3.1.20)
   JCR Installer 3.1.22

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



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

[jira] [Updated] (SLING-6104) Improve handling to avoid Oak warning

[Robert Munteanu (JIRA)]

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

Robert Munteanu updated SLING-6104:
---
Fix Version/s: (was: JCR Installer 3.1.20)
   JCR Installer 3.1.22

> Improve handling to avoid Oak warning
> -
>
> Key: SLING-6104
> URL: https://issues.apache.org/jira/browse/SLING-6104
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer, JCR
>Affects Versions: JCR Resource 2.8.0, JCR Installer 3.1.16
>Reporter: Jörg Hoh
>Assignee: Carsten Ziegeler
> Fix For: JCR Resource 2.8.2, Pipes 0.0.10, JCR Installer 3.1.22
>
>
> I often see messages like this in our logs (AEM 6.0):
> {noformat}
> WARN org.apache.jackrabbit.oak.jcr.session.ItemImpl Item#refresh invokes 
> Session#refresh!
> {noformat}
> I found that in 
> bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/JcrResourceUtil.java
>  there is one occurrences of this pattern:
> {code}
> 444 } catch (RepositoryException re) {
> 445 // we ignore this as this folder might be 
> created from a different task
> 446 node.refresh(false);
> 447 }
> {code}
> This should be changed to {code}node.getSession().refresh(false);{code} to 
> avoid this warning. From my point of view the semantic does not change.
> I found the same pattern here as well:
> * 
> installer/providers/jcr/src/main/java/org/apache/sling/installer/provider/jcr/impl/JcrUtil.java
> * 
> contrib/extensions/sling-pipes/src/main/java/org/apache/sling/pipes/PathPipe.java



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

[VOTE CANCELLED] Release Apache Sling JCR Installer version 3.1.20

[Robert Munteanu]

Released cancelled to allow the fix for SLING-6337 [1] to be included
in the release.

Robert

[1]: https://issues.apache.org/jira/browse/SLING-6337

On Fri, 2016-11-25 at 13:24 +0200, Robert Munteanu wrote:
> Hi,
> 
> We solved 5 issues in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12334867
> 
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-158
> 3
> 
> 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 1583 /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.
> 
> Thanks,
> 
> Robert

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

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-6337:


Thanks for the fix [~olli]. Note that since the vote for 3.1.20 is underway and 
will be cancelled I moved the issue to 3.1.22

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



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

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

[Robert Munteanu (JIRA)]

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

Robert Munteanu updated SLING-6337:
---
Fix Version/s: (was: JCR Installer 3.1.20)
   JCR Installer 3.1.22

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



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

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

[Robert Munteanu (JIRA)]

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

Robert Munteanu updated SLING-6337:
---
Affects Version/s: JCR Installer 3.1.20

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



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

Re: svn commit: r1771782 - /sling/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/ResourceResolverWrapper.java

[Radu Cotescu]

Hi Julian,

You're right, we should also wrap the returned resources. I've just replied
on JIRA a couple of minutes ago.

Thanks,
Radu

On Mon, 28 Nov 2016 at 19:15 Julian Sedding  wrote:

> Hi Radu
>
> I would argue that this implementation is incorrect.
>
> Consider that with this implementation resolver !=
> resolver.getResource("/foo").getResourceResolver(), which should be
> the case IMHO.
>
> I commented on the issue with two tickets, where the same feature was
> previously discussed. The tickets also have patches attached, which
> implement proper (or deep) wrapping of the ResourceResolver.
>
> Regards
> Julian
>
>
>
> On Mon, Nov 28, 2016 at 7:11 PM,   wrote:
> > Author: radu
> > Date: Mon Nov 28 18:11:34 2016
> > New Revision: 1771782
> >
> > URL: http://svn.apache.org/viewvc?rev=1771782=rev
> > Log:
> > SLING-6336 - Implement a ResourceResolverWrapper
> >
> > Added:
> >
>  
> sling/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/ResourceResolverWrapper.java
> >
> > Added:
> sling/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/ResourceResolverWrapper.java
> > URL:
> http://svn.apache.org/viewvc/sling/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/ResourceResolverWrapper.java?rev=1771782=auto
> >
> ==
> > ---
> sling/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/ResourceResolverWrapper.java
> (added)
> > +++
> sling/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/ResourceResolverWrapper.java
> Mon Nov 28 18:11:34 2016
> > @@ -0,0 +1,210 @@
> >
> +/***
> > + * Licensed to the Apache Software Foundation (ASF) under one or more
> > + * contributor license agreements.  See the NOTICE file distributed with
> > + * this work for additional information regarding copyright ownership.
> > + * The ASF licenses this file to You under the Apache License, Version
> 2.0
> > + * (the "License"); you may not use this file except in compliance with
> > + * the License.  You may obtain a copy of the License at
> > + *
> > + * http://www.apache.org/licenses/LICENSE-2.0
> > + *
> > + * Unless required by applicable law or agreed to in writing, software
> > + * distributed under the License is distributed on an "AS IS" BASIS,
> > + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> implied.
> > + * See the License for the specific language governing permissions and
> > + * limitations under the License.
> > +
> **/
> > +package org.apache.sling.api.resource;
> > +
> > +import java.util.Iterator;
> > +import java.util.Map;
> > +import javax.annotation.Nonnull;
> > +import javax.servlet.http.HttpServletRequest;
> > +
> > +import org.osgi.annotation.versioning.ConsumerType;
> > +
> > +/**
> > + * The {@code ResourceResolverWrapper} is a wrapper for any {@code
> ResourceResolver}, delegating all method calls to the wrapped resource
> > + * resolver by default. Extensions of this class may overwrite any
> method to return different values as appropriate.
> > + */
> > +@ConsumerType
> > +public class ResourceResolverWrapper implements ResourceResolver {
> > +
> > +private ResourceResolver wrapped;
> > +
> > +public ResourceResolverWrapper(ResourceResolver resolver) {
> > +wrapped = resolver;
> > +}
> > +
> > +@Nonnull
> > +@Override
> > +public Resource resolve(@Nonnull HttpServletRequest request,
> @Nonnull String absPath) {
> > +return wrapped.resolve(request, absPath);
> > +}
> > +
> > +@Nonnull
> > +@Override
> > +public Resource resolve(@Nonnull String absPath) {
> > +return wrapped.resolve(absPath);
> > +}
> > +
> > +@Nonnull
> > +@Override
> > +public Resource resolve(@Nonnull HttpServletRequest request) {
> > +return wrapped.resolve(request);
> > +}
> > +
> > +@Nonnull
> > +@Override
> > +public String map(@Nonnull String resourcePath) {
> > +return wrapped.map(resourcePath);
> > +}
> > +
> > +@Override
> > +public String map(@Nonnull HttpServletRequest request, @Nonnull
> String resourcePath) {
> > +return wrapped.map(request, resourcePath);
> > +}
> > +
> > +@Override
> > +public Resource getResource(@Nonnull String path) {
> > +return wrapped.getResource(path);
> > +}
> > +
> > +@Override
> > +public Resource getResource(Resource base, @Nonnull String path) {
> > +return wrapped.getResource(base, path);
> > +}
> > +
> > +@Nonnull
> > +@Override
> > +public String[] getSearchPath() {
> > +return wrapped.getSearchPath();
> > +}
> > +
> > +@Nonnull
> > +@Override
> > +public Iterator listChildren(@Nonnull Resource parent) {
> > +return 

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

[Oliver Lietz (JIRA)]

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

Oliver Lietz resolved SLING-6337.
-
   Resolution: Fixed
Fix Version/s: JCR Installer 3.1.20

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

> 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
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: JCR Installer 3.1.20
>
>
> brackets got lost, regular expression has to be {{.*/(install|config)$}}



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

[jira] [Commented] (SLING-6336) Implement a ResourceResolverWrapper

[Radu Cotescu (JIRA)]

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

Radu Cotescu commented on SLING-6336:
-

Thanks for the pointer! I guess I like your implementations more than what I've 
pushed in [r1771782|https://svn.apache.org/r1771782], because you also make 
sure to wrap the returned resources. In this case I wanted to implement the 
wrapper so that consumers that decide to implement their own resource resolver 
are not forced to import {{org.apache.sling.api.resource}} with a minor-limited 
import range. Such an example is the {{ScriptingResourceResolverProvider}} from 
SLING-6165 that needs to provide a slightly modified {{ResourceResolver}}.

[~fmeschbe], [~jsedding], should we revise the patches from the issues Julian 
mentioned and merge them with what I pushed?

> Implement a ResourceResolverWrapper
> ---
>
> Key: SLING-6336
> URL: https://issues.apache.org/jira/browse/SLING-6336
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: API 2.15.2
>
>
> A {{ResourceResolverWrapper}} would help consumers who implement the 
> {{ResourceResolver}} interface to not define restrictive import ranges for 
> the {{org.apache.sling.api.resource}} API package.
> The implementation should delegate all calls to the wrapped resource 
> resolver, similar to the {{ResourceWrapper}}.



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

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

[Oliver Lietz]

On Monday 28 November 2016 10:59:11 Stefan Seifert wrote:
> -1
> 
> i think there is an issue with this ticket, we should clarify it first:
> https://issues.apache.org/jira/browse/SLING-5519?focusedCommentId=15701634#c
> omment-15701634

Stefan is right. Didn't see this vote so opened SLING-6337 to fix it.

Thanks for spotting, Stefan!

O.

> stefan
> 
> 
> 
> >-Original Message-
> >From: Robert Munteanu [mailto:romb...@apache.org]
> >Sent: Friday, November 25, 2016 12:24 PM
> >To: Sling Dev
> >Subject: [VOTE] Release Apache Sling JCR Installer version 3.1.20
> >
> >Hi,
> >
> >We solved 5 issues in this release:
> >https://issues.apache.org/jira/browse/SLING/fixforversion/12334867
> >
> >
> >Staging repository:
> >https://repository.apache.org/content/repositories/orgapachesling-1583
> >
> >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 1583 /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.
> >
> >Thanks,
> >
> >Robert

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

[Oliver Lietz (JIRA)]

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

Oliver Lietz updated SLING-6337:

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

> 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
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>
> brackets got lost, regular expression has to be {{.*/(install|config)$}}



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

Re: svn commit: r1771782 - /sling/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/ResourceResolverWrapper.java

[Julian Sedding]

Hi Radu

I would argue that this implementation is incorrect.

Consider that with this implementation resolver !=
resolver.getResource("/foo").getResourceResolver(), which should be
the case IMHO.

I commented on the issue with two tickets, where the same feature was
previously discussed. The tickets also have patches attached, which
implement proper (or deep) wrapping of the ResourceResolver.

Regards
Julian



On Mon, Nov 28, 2016 at 7:11 PM,   wrote:
> Author: radu
> Date: Mon Nov 28 18:11:34 2016
> New Revision: 1771782
>
> URL: http://svn.apache.org/viewvc?rev=1771782=rev
> Log:
> SLING-6336 - Implement a ResourceResolverWrapper
>
> Added:
> 
> sling/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/ResourceResolverWrapper.java
>
> Added: 
> sling/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/ResourceResolverWrapper.java
> URL: 
> http://svn.apache.org/viewvc/sling/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/ResourceResolverWrapper.java?rev=1771782=auto
> ==
> --- 
> sling/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/ResourceResolverWrapper.java
>  (added)
> +++ 
> sling/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/ResourceResolverWrapper.java
>  Mon Nov 28 18:11:34 2016
> @@ -0,0 +1,210 @@
> +/***
> + * Licensed to the Apache Software Foundation (ASF) under one or more
> + * contributor license agreements.  See the NOTICE file distributed with
> + * this work for additional information regarding copyright ownership.
> + * The ASF licenses this file to You under the Apache License, Version 2.0
> + * (the "License"); you may not use this file except in compliance with
> + * the License.  You may obtain a copy of the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> + * See the License for the specific language governing permissions and
> + * limitations under the License.
> + 
> **/
> +package org.apache.sling.api.resource;
> +
> +import java.util.Iterator;
> +import java.util.Map;
> +import javax.annotation.Nonnull;
> +import javax.servlet.http.HttpServletRequest;
> +
> +import org.osgi.annotation.versioning.ConsumerType;
> +
> +/**
> + * The {@code ResourceResolverWrapper} is a wrapper for any {@code 
> ResourceResolver}, delegating all method calls to the wrapped resource
> + * resolver by default. Extensions of this class may overwrite any method to 
> return different values as appropriate.
> + */
> +@ConsumerType
> +public class ResourceResolverWrapper implements ResourceResolver {
> +
> +private ResourceResolver wrapped;
> +
> +public ResourceResolverWrapper(ResourceResolver resolver) {
> +wrapped = resolver;
> +}
> +
> +@Nonnull
> +@Override
> +public Resource resolve(@Nonnull HttpServletRequest request, @Nonnull 
> String absPath) {
> +return wrapped.resolve(request, absPath);
> +}
> +
> +@Nonnull
> +@Override
> +public Resource resolve(@Nonnull String absPath) {
> +return wrapped.resolve(absPath);
> +}
> +
> +@Nonnull
> +@Override
> +public Resource resolve(@Nonnull HttpServletRequest request) {
> +return wrapped.resolve(request);
> +}
> +
> +@Nonnull
> +@Override
> +public String map(@Nonnull String resourcePath) {
> +return wrapped.map(resourcePath);
> +}
> +
> +@Override
> +public String map(@Nonnull HttpServletRequest request, @Nonnull String 
> resourcePath) {
> +return wrapped.map(request, resourcePath);
> +}
> +
> +@Override
> +public Resource getResource(@Nonnull String path) {
> +return wrapped.getResource(path);
> +}
> +
> +@Override
> +public Resource getResource(Resource base, @Nonnull String path) {
> +return wrapped.getResource(base, path);
> +}
> +
> +@Nonnull
> +@Override
> +public String[] getSearchPath() {
> +return wrapped.getSearchPath();
> +}
> +
> +@Nonnull
> +@Override
> +public Iterator listChildren(@Nonnull Resource parent) {
> +return wrapped.listChildren(parent);
> +}
> +
> +@Override
> +public Resource getParent(@Nonnull Resource child) {
> +return wrapped.getParent(child);
> +}
> +
> +@Nonnull
> +@Override
> +public Iterable getChildren(@Nonnull Resource parent) {
> +return wrapped.getChildren(parent);
> +}
> +
> +@Nonnull
> +@Override
> +public Iterator findResources(@Nonnull String query, String 
> language) {
> +   

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

[Oliver Lietz (JIRA)]

Oliver Lietz created SLING-6337:
---

 Summary: Fix default folder name regular expression
 Key: SLING-6337
 URL: https://issues.apache.org/jira/browse/SLING-6337
 Project: Sling
  Issue Type: Bug
  Components: Installer
Affects Versions: JCR Installer 3.1.20
Reporter: Oliver Lietz
Assignee: Oliver Lietz


brackets got lost, regular expression has to be {{.*/(install|config)$}}



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

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

[Oliver Lietz (JIRA)]

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

Oliver Lietz commented on SLING-5519:
-

[~sseif...@pro-vision.de], you're absolutely right. Don't know how the brackets 
could get lost (it should be the same pattern as in AEM), SLING-6337.

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



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

[jira] [Commented] (SLING-6336) Implement a ResourceResolverWrapper

[Julian Sedding (JIRA)]

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

Julian Sedding commented on SLING-6336:
---

Please note that a {{ResourceResolverWrapper}} was already discussed in 
SLING-2698 and SLING-2411. Both tickets contain a patch with an implementation 
(I think it's the same implementation in both patches). Back then it was 
decided to not include a RRWrapper, but I am sure we can revisit this decision.

> Implement a ResourceResolverWrapper
> ---
>
> Key: SLING-6336
> URL: https://issues.apache.org/jira/browse/SLING-6336
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: API 2.15.2
>
>
> A {{ResourceResolverWrapper}} would help consumers who implement the 
> {{ResourceResolver}} interface to not define restrictive import ranges for 
> the {{org.apache.sling.api.resource}} API package.
> The implementation should delegate all calls to the wrapped resource 
> resolver, similar to the {{ResourceWrapper}}.



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

Re: integration test fail due to LoginAdminWhitelist

[Julian Sedding]

Hi Stefan

When analyzing the issue I noticed that the test was waiting for the
ResourceResolverFactory service to become available. However, it is
possible that the test starts before even all bundles in the
repository are active (SLING-6334[0]). Thus, especially on slow
systems, the likelihood of a timeout (10s by default) when waiting for
a service is increased. Furthermore, the system was polled for the
presence of the service every 50ms. In my local tests that seemed to
slow down the service becoming available by up to 3 seconds. Waiting
for the service can be done with a ServiceTracker instead of polling
(SLING-6335[1]).

After applying my changes, the time from when the test starts (after
all bundles are active) and the time the ResourceResolverFactory
becomes available went down from 10+ to ~3 seconds.

Regards
Julian

[0] https://issues.apache.org/jira/browse/SLING-6334
[1] https://issues.apache.org/jira/browse/SLING-6335


On Mon, Nov 28, 2016 at 2:02 PM, Stefan Seifert  wrote:
> this fix of my problem was finally quite simple: i just had to double the 
> backslashes to escape them [1], and then it works, and the generated 
> slingstart.txt contains the same string as before.
>
> what is still strange that on my system (windows 10 machine with java 8) it 
> worked without proper escaping, whereas it failed on Jenkins and on julians 
> machine.
>
> stefan
>
> [1] 
> https://github.com/apache/sling/blob/trunk/contrib/extensions/contextaware-config/integration-tests/src/main/provisioning/sling.txt#L26
>
>
>
>>-Original Message-
>>From: Konrad Windszus [mailto:konra...@gmx.de]
>>Sent: Monday, November 28, 2016 1:06 PM
>>To: dev@sling.apache.org
>>Subject: Re: integration test fail due to LoginAdminWhitelist
>>
>>One last addendum:
>>Since quoted-string in RFC 2616 has some known bugs
>>(http://stackoverflow.com/questions/7886782/what-is-the-exact-syntax-and-
>>semantics-of-a-quoted-string-in-the-http1-1-rfc2616) we should only refer
>>to https://tools.ietf.org/html/rfc7230#section-3.2.6 instead (in the
>>documentation).
>>
>>> On 28 Nov 2016, at 12:45, Stefan Seifert  wrote:
>>>
>>>
 Your current configuration looks like this:
 whitelist.bundles.regexp="^org\.apache\.sling\.junit(\..*)?$"

 Inside target/slingstart.txt this becomes:
 whitelist.bundles.regexp="^org.apache.sling.junit(..*)?$"

 Note: all slashes have disappeared.
>>>
>>> this is strange, yes.
>>> the same escaping problem happens on my local machine - but there the
>>integration test passes.
>>> you could reproduce the problem on your machine?
>>>
>>> as a workaround i will simplify the regex and remove the backslashes.
>>>
>>> i think we have currently no precise documentation of the sling
>>provisioning file format esp. regarding escaping rules. on [1] only some
>>details of the embedded osgi configuration format are documented.
>>>
>>> stefan
>>>
>>> [1] https://sling.apache.org/documentation/development/slingstart.html
>>>
>>
>
>

[jira] [Resolved] (SLING-6335) Server-Side Tests: Use ServiceTracker to wait for services rather than polling

[Julian Sedding (JIRA)]

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

Julian Sedding resolved SLING-6335.
---
   Resolution: Fixed
Fix Version/s: JUnit Core 1.0.20

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

> Server-Side Tests: Use ServiceTracker to wait for services rather than polling
> --
>
> Key: SLING-6335
> URL: https://issues.apache.org/jira/browse/SLING-6335
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: JUnit Core 1.0.18
>Reporter: Julian Sedding
>Assignee: Julian Sedding
> Fix For: JUnit Core 1.0.20
>
>
> Inside {{ServerSideTeleporter#getService}} the {{BundleContext}} is polled 
> for the presence of a service every 50ms. Instead, a {{ServiceTracker}} could 
> be used to wait for the service.



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

[jira] [Updated] (SLING-6336) Implement a ResourceResolverWrapper

[Radu Cotescu (JIRA)]

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

Radu Cotescu updated SLING-6336:

Description: 
A {{ResourceResolverWrapper}} would help consumers who implement the 
{{ResourceResolver}} interface to not define restrictive import ranges for the 
{{org.apache.sling.api.resource}} API package.

The implementation should delegate all calls to the wrapped resource resolver, 
similar to the {{ResourceWrapper}}.

  was:A {{ResourceResolverWrapper}} would help consumers who implement the 
{{ResourceResolver}} interface to not define restrictive import ranges for the 
{{org.apache.sling.api.resource}} API package.


> Implement a ResourceResolverWrapper
> ---
>
> Key: SLING-6336
> URL: https://issues.apache.org/jira/browse/SLING-6336
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: API 2.15.2
>
>
> A {{ResourceResolverWrapper}} would help consumers who implement the 
> {{ResourceResolver}} interface to not define restrictive import ranges for 
> the {{org.apache.sling.api.resource}} API package.
> The implementation should delegate all calls to the wrapped resource 
> resolver, similar to the {{ResourceWrapper}}.



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

[jira] [Created] (SLING-6336) Implement a ResourceResolverWrapper

[Radu Cotescu (JIRA)]

Radu Cotescu created SLING-6336:
---

 Summary: Implement a ResourceResolverWrapper
 Key: SLING-6336
 URL: https://issues.apache.org/jira/browse/SLING-6336
 Project: Sling
  Issue Type: Improvement
  Components: API
Reporter: Radu Cotescu
Assignee: Radu Cotescu
 Fix For: API 2.15.2


A {{ResourceResolverWrapper}} would help consumers who implement the 
{{ResourceResolver}} interface to not define restrictive import ranges for the 
{{org.apache.sling.api.resource}} API package.



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

[jira] [Resolved] (SLING-6334) Server-Side Tests: Wait until all bundles are started before running tests

[Julian Sedding (JIRA)]

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

Julian Sedding resolved SLING-6334.
---
   Resolution: Fixed
Fix Version/s: JUnit Core 1.0.20

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

> Server-Side Tests: Wait until all bundles are started before running tests
> --
>
> Key: SLING-6334
> URL: https://issues.apache.org/jira/browse/SLING-6334
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: JUnit Core 1.0.18
>Reporter: Julian Sedding
>Assignee: Julian Sedding
> Fix For: JUnit Core 1.0.20
>
>
> When running Sling server-side tests, a test may start executing before all 
> bundles on the target instance are started. This increases the chance that a  
> service required by a test does not become available in time.
> The {{TestsManagerImpl}} should wait until all bundles are started. To avoid 
> an endless wait, there should be an "inactivity timeout", which is defined as 
> the maximum time to wait between two bundles becoming active.



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

[jira] [Created] (SLING-6335) Server-Side Tests: Use ServiceTracker to wait for services rather than polling

[Julian Sedding (JIRA)]

Julian Sedding created SLING-6335:
-

 Summary: Server-Side Tests: Use ServiceTracker to wait for 
services rather than polling
 Key: SLING-6335
 URL: https://issues.apache.org/jira/browse/SLING-6335
 Project: Sling
  Issue Type: Improvement
  Components: Testing
Affects Versions: JUnit Core 1.0.18
Reporter: Julian Sedding
Assignee: Julian Sedding


Inside {{ServerSideTeleporter#getService}} the {{BundleContext}} is polled for 
the presence of a service every 50ms. Instead, a {{ServiceTracker}} could be 
used to wait for the service.



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

[jira] [Created] (SLING-6334) Server-Side Tests: Wait until all bundles are started before running tests

[Julian Sedding (JIRA)]

Julian Sedding created SLING-6334:
-

 Summary: Server-Side Tests: Wait until all bundles are started 
before running tests
 Key: SLING-6334
 URL: https://issues.apache.org/jira/browse/SLING-6334
 Project: Sling
  Issue Type: Improvement
  Components: Testing
Affects Versions: JUnit Core 1.0.18
Reporter: Julian Sedding
Assignee: Julian Sedding


When running Sling server-side tests, a test may start executing before all 
bundles on the target instance are started. This increases the chance that a  
service required by a test does not become available in time.

The {{TestsManagerImpl}} should wait until all bundles are started. To avoid an 
endless wait, there should be an "inactivity timeout", which is defined as the 
maximum time to wait between two bundles becoming active.



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

[jira] [Reopened] (SLING-6324) MonitoringDistributionPackageBuilder registering of same beans cause exception

[Tommaso Teofili (JIRA)]

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

Tommaso Teofili reopened SLING-6324:


reopening as it seems the {{MonitoringDistributionPackageBuilder}} is actually 
registering mbeans twice on sender (create() and get()) and on receiver (read() 
and install()).

> MonitoringDistributionPackageBuilder registering of same beans cause exception
> --
>
> Key: SLING-6324
> URL: https://issues.apache.org/jira/browse/SLING-6324
> Project: Sling
>  Issue Type: Bug
>  Components: Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution 0.2.0
>
> Attachments: SLING-6324.patch
>
>
> While distributing some content massively I have encountered lots of 
> stacktraces like below (on sending instance):
> {noformat}
> 24.11.2016 13:09:37.424 *INFO* [127.0.0.1 [1479989377273] POST 
> /bin/replicate.json HTTP/1.1] 
> org.apache.sling.distribution.agent.impl.SimpleDistributionAgent 
> [agent][publish] REQUEST-START DSTRQ2791: ADD 
> paths=[/content/test10K/node27/subnode90], user=replication-service
> 24.11.2016 13:09:37.425 *ERROR* 
> [sling-threadpool-7c966356-fcc8-467b-9d58-eab12551b43c-(apache-sling-job-thread-pool)-2-org_apache_sling_distribution_queue_publish_default(org/apache/sling/distribution/queue/publish/default)]
>  org.apache.aries.jmx.whiteboard.MBeanHolder register: Failure registering 
> MBean 
> org.apache.aries.jmx.util.shared.RegistrableStandardEmitterMBean@42b86d48
> javax.management.InstanceAlreadyExistsException: 
> org.apache.sling.distribution:type=distributionpackage,id="/var/sling/distribution/packages/kryo-cs/data/dstrpck-1479989376714-b79fc9b9-a3e2-4a03-a33c-e87ccd17b8dc"
>   at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
>   at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
>   at 
> org.apache.aries.jmx.whiteboard.MBeanHolder.register(MBeanHolder.java:114)
>   at 
> org.apache.aries.jmx.whiteboard.JmxWhiteboardSupport.registerMBean(JmxWhiteboardSupport.java:86)
>   at 
> org.apache.aries.jmx.whiteboard.Activator$MBeanTracker.addingService(Activator.java:102)
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941)
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870)
>   at 
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
>   at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:901)
>   at 
> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:991)
>   at 
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:839)
>   at 
> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:546)
>   at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4558)
>   at org.apache.felix.framework.Felix.registerService(Felix.java:3550)
>   at 
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:348)
>   at 
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:322)
>   at 
> org.apache.sling.distribution.monitor.impl.MonitoringDistributionPackageBuilder.registerDistributionPackageMBean(MonitoringDistributionPackageBuilder.java:109)
>   at 
> org.apache.sling.distribution.monitor.impl.MonitoringDistributionPackageBuilder.getPackage(MonitoringDistributionPackageBuilder.java:81)
>   at 
> org.apache.sling.distribution.serialization.impl.DistributionPackageBuilderFactory.getPackage(DistributionPackageBuilderFactory.java:222)
>   at 
> org.apache.sling.distribution.packaging.impl.exporter.LocalDistributionPackageExporter.getPackage(LocalDistributionPackageExporter.java:55)
>   at 
> org.apache.sling.distribution.agent.impl.SimpleDistributionAgentQueueProcessor.processQueueItem(SimpleDistributionAgentQueueProcessor.java:116)
>   at 
> 

RE: integration test fail due to LoginAdminWhitelist

[Stefan Seifert]

this fix of my problem was finally quite simple: i just had to double the 
backslashes to escape them [1], and then it works, and the generated 
slingstart.txt contains the same string as before.

what is still strange that on my system (windows 10 machine with java 8) it 
worked without proper escaping, whereas it failed on Jenkins and on julians 
machine.

stefan

[1] 
https://github.com/apache/sling/blob/trunk/contrib/extensions/contextaware-config/integration-tests/src/main/provisioning/sling.txt#L26



>-Original Message-
>From: Konrad Windszus [mailto:konra...@gmx.de]
>Sent: Monday, November 28, 2016 1:06 PM
>To: dev@sling.apache.org
>Subject: Re: integration test fail due to LoginAdminWhitelist
>
>One last addendum:
>Since quoted-string in RFC 2616 has some known bugs
>(http://stackoverflow.com/questions/7886782/what-is-the-exact-syntax-and-
>semantics-of-a-quoted-string-in-the-http1-1-rfc2616) we should only refer
>to https://tools.ietf.org/html/rfc7230#section-3.2.6 instead (in the
>documentation).
>
>> On 28 Nov 2016, at 12:45, Stefan Seifert  wrote:
>>
>>
>>> Your current configuration looks like this:
>>> whitelist.bundles.regexp="^org\.apache\.sling\.junit(\..*)?$"
>>>
>>> Inside target/slingstart.txt this becomes:
>>> whitelist.bundles.regexp="^org.apache.sling.junit(..*)?$"
>>>
>>> Note: all slashes have disappeared.
>>
>> this is strange, yes.
>> the same escaping problem happens on my local machine - but there the
>integration test passes.
>> you could reproduce the problem on your machine?
>>
>> as a workaround i will simplify the regex and remove the backslashes.
>>
>> i think we have currently no precise documentation of the sling
>provisioning file format esp. regarding escaping rules. on [1] only some
>details of the embedded osgi configuration format are documented.
>>
>> stefan
>>
>> [1] https://sling.apache.org/documentation/development/slingstart.html
>>
>

Re: integration test fail due to LoginAdminWhitelist

[Konrad Windszus]

One last addendum:
Since quoted-string in RFC 2616 has some known bugs 
(http://stackoverflow.com/questions/7886782/what-is-the-exact-syntax-and-semantics-of-a-quoted-string-in-the-http1-1-rfc2616)
 we should only refer to https://tools.ietf.org/html/rfc7230#section-3.2.6 
instead (in the documentation).

> On 28 Nov 2016, at 12:45, Stefan Seifert  wrote:
> 
> 
>> Your current configuration looks like this:
>> whitelist.bundles.regexp="^org\.apache\.sling\.junit(\..*)?$"
>> 
>> Inside target/slingstart.txt this becomes:
>> whitelist.bundles.regexp="^org.apache.sling.junit(..*)?$"
>> 
>> Note: all slashes have disappeared.
> 
> this is strange, yes.
> the same escaping problem happens on my local machine - but there the 
> integration test passes.
> you could reproduce the problem on your machine?
> 
> as a workaround i will simplify the regex and remove the backslashes.
> 
> i think we have currently no precise documentation of the sling provisioning 
> file format esp. regarding escaping rules. on [1] only some details of the 
> embedded osgi configuration format are documented.
> 
> stefan
> 
> [1] https://sling.apache.org/documentation/development/slingstart.html
> 

Re: integration test fail due to LoginAdminWhitelist

[Konrad Windszus]

To figure out how the escaping exactly works, you can leverage the JCR 
Installer write back feature (which gives out .config files in the repository)

> On 28 Nov 2016, at 12:54, Konrad Windszus  wrote:
> 
> Currently we have more or less the same documentation at 
> https://sling.apache.org/documentation/bundles/configuration-installer-factory.html#configuration-files-config
>  and 
> https://sling.apache.org/documentation/development/slingstart.html#default-configuration-format.
>  I would be in favor of getting rid of the description in the latter page and 
> just link to the former.
> In the former page the escaping rules should be further clarified.
> Konrad
> 
>> On 28 Nov 2016, at 12:45, Stefan Seifert  wrote:
>> 
>> 
>>> Your current configuration looks like this:
>>> whitelist.bundles.regexp="^org\.apache\.sling\.junit(\..*)?$"
>>> 
>>> Inside target/slingstart.txt this becomes:
>>> whitelist.bundles.regexp="^org.apache.sling.junit(..*)?$"
>>> 
>>> Note: all slashes have disappeared.
>> 
>> this is strange, yes.
>> the same escaping problem happens on my local machine - but there the 
>> integration test passes.
>> you could reproduce the problem on your machine?
>> 
>> as a workaround i will simplify the regex and remove the backslashes.
>> 
>> i think we have currently no precise documentation of the sling provisioning 
>> file format esp. regarding escaping rules. on [1] only some details of the 
>> embedded osgi configuration format are documented.
>> 
>> stefan
>> 
>> [1] https://sling.apache.org/documentation/development/slingstart.html
>> 
> 

Re: integration test fail due to LoginAdminWhitelist

[Konrad Windszus]

Currently we have more or less the same documentation at 
https://sling.apache.org/documentation/bundles/configuration-installer-factory.html#configuration-files-config
 and 
https://sling.apache.org/documentation/development/slingstart.html#default-configuration-format.
 I would be in favor of getting rid of the description in the latter page and 
just link to the former.
In the former page the escaping rules should be further clarified.
Konrad

> On 28 Nov 2016, at 12:45, Stefan Seifert  wrote:
> 
> 
>> Your current configuration looks like this:
>> whitelist.bundles.regexp="^org\.apache\.sling\.junit(\..*)?$"
>> 
>> Inside target/slingstart.txt this becomes:
>> whitelist.bundles.regexp="^org.apache.sling.junit(..*)?$"
>> 
>> Note: all slashes have disappeared.
> 
> this is strange, yes.
> the same escaping problem happens on my local machine - but there the 
> integration test passes.
> you could reproduce the problem on your machine?
> 
> as a workaround i will simplify the regex and remove the backslashes.
> 
> i think we have currently no precise documentation of the sling provisioning 
> file format esp. regarding escaping rules. on [1] only some details of the 
> embedded osgi configuration format are documented.
> 
> stefan
> 
> [1] https://sling.apache.org/documentation/development/slingstart.html
> 

RE: integration test fail due to LoginAdminWhitelist

[Stefan Seifert]

>Your current configuration looks like this:
>whitelist.bundles.regexp="^org\.apache\.sling\.junit(\..*)?$"
>
>Inside target/slingstart.txt this becomes:
>whitelist.bundles.regexp="^org.apache.sling.junit(..*)?$"
>
>Note: all slashes have disappeared.

this is strange, yes.
the same escaping problem happens on my local machine - but there the 
integration test passes.
you could reproduce the problem on your machine?

as a workaround i will simplify the regex and remove the backslashes.

i think we have currently no precise documentation of the sling provisioning 
file format esp. regarding escaping rules. on [1] only some details of the 
embedded osgi configuration format are documented.

stefan

[1] https://sling.apache.org/documentation/development/slingstart.html

Re: integration test fail due to LoginAdminWhitelist

[Julian Sedding]

Sorry, forget the last bit about tests passing. I fooled my self when
I only built the "package" phase.

The tests also don't pass with regexp=junit.

Regards
Julian

On Mon, Nov 28, 2016 at 12:36 PM, Julian Sedding  wrote:
> Hi Stefan
>
> I just had a look and noticed the following:
>
> Your current configuration looks like this:
> whitelist.bundles.regexp="^org\.apache\.sling\.junit(\..*)?$"
>
> Inside target/slingstart.txt this becomes:
> whitelist.bundles.regexp="^org.apache.sling.junit(..*)?$"
>
> Note: all slashes have disappeared.
>
> When I escape the slashes, i.e.
> whitelist.bundles.regexp="^org\\.apache\\.sling\\.junit(\\..*)?$"
>
> target/slingstart.txt remains the same:
> whitelist.bundles.regexp="^org\\.apache\\.sling\\.junit(\\..*)?$"
>
> I believe there may be a bug in the escaping of provisioning models.
> Unless someone can advise how to preserve the single back-slashes from
> the original configuration.
>
> Note that if I set the regexp to "junit" the tests pass.
>
> Regards
> Julian
>
>
> On Mon, Nov 28, 2016 at 11:40 AM, Stefan Seifert  
> wrote:
>> for some time the caconfig integration tests are failing because the 
>> org.apache.sling.junit.core is not whitelisted in LoginAdminWhitelist (see 
>> [1]).
>>
>> but it is whitelisted via regexp (using the same merge-fix as robert for the 
>> launchpad tests - see [2]).
>>
>> the resulting slingstart.txt in the build does contain the correct whitelist 
>> information see [3]
>>
>> on my local machine the integration tests are running fine. on Jenkins they 
>> fail. has anyone an idea what is going wrong? can someone reproduce the 
>> failure locally?
>>
>> stefan
>>
>> [1] 
>> https://builds.apache.org/job/sling-contrib-extensions-contextaware-config-integration-tests-1.8/201/console
>>
>> [2] 
>> https://github.com/apache/sling/blob/trunk/contrib/extensions/contextaware-config/integration-tests/src/main/provisioning/sling.txt
>>
>> [3] 
>> https://builds.apache.org/job/sling-contrib-extensions-contextaware-config-integration-tests-1.8/ws/target/slingstart.txt
>>
>>

Re: integration test fail due to LoginAdminWhitelist

[Julian Sedding]

Hi Stefan

I just had a look and noticed the following:

Your current configuration looks like this:
whitelist.bundles.regexp="^org\.apache\.sling\.junit(\..*)?$"

Inside target/slingstart.txt this becomes:
whitelist.bundles.regexp="^org.apache.sling.junit(..*)?$"

Note: all slashes have disappeared.

When I escape the slashes, i.e.
whitelist.bundles.regexp="^org\\.apache\\.sling\\.junit(\\..*)?$"

target/slingstart.txt remains the same:
whitelist.bundles.regexp="^org\\.apache\\.sling\\.junit(\\..*)?$"

I believe there may be a bug in the escaping of provisioning models.
Unless someone can advise how to preserve the single back-slashes from
the original configuration.

Note that if I set the regexp to "junit" the tests pass.

Regards
Julian


On Mon, Nov 28, 2016 at 11:40 AM, Stefan Seifert  wrote:
> for some time the caconfig integration tests are failing because the 
> org.apache.sling.junit.core is not whitelisted in LoginAdminWhitelist (see 
> [1]).
>
> but it is whitelisted via regexp (using the same merge-fix as robert for the 
> launchpad tests - see [2]).
>
> the resulting slingstart.txt in the build does contain the correct whitelist 
> information see [3]
>
> on my local machine the integration tests are running fine. on Jenkins they 
> fail. has anyone an idea what is going wrong? can someone reproduce the 
> failure locally?
>
> stefan
>
> [1] 
> https://builds.apache.org/job/sling-contrib-extensions-contextaware-config-integration-tests-1.8/201/console
>
> [2] 
> https://github.com/apache/sling/blob/trunk/contrib/extensions/contextaware-config/integration-tests/src/main/provisioning/sling.txt
>
> [3] 
> https://builds.apache.org/job/sling-contrib-extensions-contextaware-config-integration-tests-1.8/ws/target/slingstart.txt
>
>

Re: How to handle minor version updates in API for provider bundles?

[Konrad Windszus]

Yes, I did, just look at the mentioned commits in ticket 
https://issues.apache.org/jira/browse/SLING-6327.
Konrad

> On 28 Nov 2016, at 10:14, Bertrand Delacretaz  wrote:
> 
> On Mon, Nov 28, 2016 at 9:50 AM, Konrad Windszus  wrote:
>> ...There were no tests which had to be adjusted for the change, but in fact 
>> there is a semantical change...
> 
> hmm...hmm...hmm...that vague feeling that the test coverage is not
> what it should be ;-)
> 
> Did you add tests that demonstrate the new behavior?
> 
> -Bertrand

[jira] [Updated] (SLING-6332) Configurations with same PID but different features/run modes in provisioning model are ignored

[Robert Munteanu (JIRA)]

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

Robert Munteanu updated SLING-6332:
---
Description: 
I have the following scenario:

# {{launchpad/builder}} defines an OSGi config for 
{{org.apache.sling.jcr.base.internal.LoginAdminWhitelist}}, setting the 
{{whitelist.bundles.additional}} property
# {{launchpad/testing}} depends on {{launchpad/builder}} and defines an the 
same config with {{[mode=merge]}} and sets the {{whitelist.bundles.regexp}} 
property

When building {{launchpad/testing}}, the configuration from this project is 
ignored completely and the one from {{launchpad/builder}} is picked up.

  was:
I have a the following scenario:

# {{launchpad/builder}} defines an OSGi config for 
{{org.apache.sling.jcr.base.internal.LoginAdminWhitelist}}, setting the 
{{whitelist.bundles.additional}} property
# {{launchpad/testing}} depends on {{launchpad/builder}} and defines an the 
same config with {{[mode=merge]}} and sets the {{whitelist.bundles.regexp}} 
property

When building {{launchpad/testing}}, the configuration from this project is 
ignored completely and the one from {{launchpad/builder}} is picked up.


> Configurations with same PID but different features/run modes in provisioning 
> model are ignored 
> 
>
> Key: SLING-6332
> URL: https://issues.apache.org/jira/browse/SLING-6332
> Project: Sling
>  Issue Type: Bug
>  Components: Tooling
>Reporter: Robert Munteanu
> Fix For: Sling Provisioning Model 1.8.0
>
>
> I have the following scenario:
> # {{launchpad/builder}} defines an OSGi config for 
> {{org.apache.sling.jcr.base.internal.LoginAdminWhitelist}}, setting the 
> {{whitelist.bundles.additional}} property
> # {{launchpad/testing}} depends on {{launchpad/builder}} and defines an the 
> same config with {{[mode=merge]}} and sets the {{whitelist.bundles.regexp}} 
> property
> When building {{launchpad/testing}}, the configuration from this project is 
> ignored completely and the one from {{launchpad/builder}} is picked up.



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

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

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on SLING-6165:
--

Note, that Sling indeed does not do that. This is the task of the Http Service 
implementation integrating with the actual Servlet Container implementation. So 
in the default Sling Launchpad this would be the Felix Http Service.

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



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

RE: [VOTE] Release Apache Sling Commons Metrics 1.2.0

[Stefan Seifert]

+1

RE: [VOTE] Release Apache Sling JCR Installer version 3.1.20

[Stefan Seifert]

-1

i think there is an issue with this ticket, we should clarify it first:
https://issues.apache.org/jira/browse/SLING-5519?focusedCommentId=15701634#comment-15701634

stefan


>-Original Message-
>From: Robert Munteanu [mailto:romb...@apache.org]
>Sent: Friday, November 25, 2016 12:24 PM
>To: Sling Dev
>Subject: [VOTE] Release Apache Sling JCR Installer version 3.1.20
>
>Hi,
>
>We solved 5 issues in this release:
>https://issues.apache.org/jira/browse/SLING/fixforversion/12334867
>
>
>Staging repository:
>https://repository.apache.org/content/repositories/orgapachesling-1583
>
>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 1583 /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.
>
>Thanks,
>
>Robert

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

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-5519:
---

is the regex {{.*/install|config$}} correct?
i suppose it should be {{.*/(install|config)$}}?

i tested the regex with a path link {{/apps/myapp/config}} and it does not seem 
to match.
we should add/extend unit tests that tests this new path as well.

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



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

integration test fail due to LoginAdminWhitelist

[Stefan Seifert]

for some time the caconfig integration tests are failing because the 
org.apache.sling.junit.core is not whitelisted in LoginAdminWhitelist (see [1]).

but it is whitelisted via regexp (using the same merge-fix as robert for the 
launchpad tests - see [2]).

the resulting slingstart.txt in the build does contain the correct whitelist 
information see [3]

on my local machine the integration tests are running fine. on Jenkins they 
fail. has anyone an idea what is going wrong? can someone reproduce the failure 
locally?

stefan

[1] 
https://builds.apache.org/job/sling-contrib-extensions-contextaware-config-integration-tests-1.8/201/console

[2] 
https://github.com/apache/sling/blob/trunk/contrib/extensions/contextaware-config/integration-tests/src/main/provisioning/sling.txt

[3] 
https://builds.apache.org/job/sling-contrib-extensions-contextaware-config-integration-tests-1.8/ws/target/slingstart.txt

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

[Radu Cotescu (JIRA)]

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

Radu Cotescu updated SLING-6165:

Fix Version/s: (was: Scripting Core 2.0.42)
   (was: Scripting API 2.1.10)

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



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

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

[Radu Cotescu (JIRA)]

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

Radu Cotescu updated SLING-6165:

Fix Version/s: Scripting Core 2.0.44
   Scripting API 2.1.12

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



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

[CANCELLED][VOTE] Release Apache Sling Scripting API 2.1.10, Apache Sling Scripting Core 2.0.42

[Radu Cotescu]

I've had to reopen SLING-6165 [0]. Will provide a fix and re-start the
release.

[0] -
https://issues.apache.org/jira/browse/SLING-6165?focusedCommentId=15701545=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15701545

On Sat, 26 Nov 2016 at 13:55 Oliver Lietz  wrote:

> On Thursday 24 November 2016 16:23:18 Radu Cotescu wrote:
> > Hi,
> >
> > We solved 1 issue for these releases:
> > https://issues.apache.org/jira/browse/SLING/fixforversion/12333078
>
> +1
>
> > https://issues.apache.org/jira/browse/SLING/fixforversion/12338542
>
> +1
>
> Though ScriptingResourceResolverProvider uses BND annotation instead of
> OSGi
> annotation and we have to do a version increase from 1.0.0 to 1.0.1 later
> (@Radu sorry, didn't notice earlier).
>
> O.
>
>

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

[Radu Cotescu (JIRA)]

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

Radu Cotescu commented on SLING-6165:
-

I've had to reopen this issue since Sling doesn't actually dispatch Servlet 
Request Events, which might lead to stale resource resolvers associated with 
some threads and also {{ThreadLocal}} contexts that do not get cleaned properly.

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



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

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

[Radu Cotescu (JIRA)]

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

Radu Cotescu reopened SLING-6165:
-

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



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

Re: [VOTE] Release Apache Sling Commons Metrics 1.2.0

[Chetan Mehrotra]

+1
Chetan Mehrotra


On Mon, Nov 28, 2016 at 3:33 PM, Stefan Egli  wrote:
> +1
>
> Cheers,
> Stefan
>
> On 28/11/16 10:42, "Chetan Mehrotra"  wrote:
>
>>Hi,
>>
>>We solved 5 issues in this release:
>>https://issues.apache.org/jira/browse/SLING/fixforversion/12334646
>>
>>Staging repository:
>>https://repository.apache.org/content/repositories/orgapachesling-1584
>>
>>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 1584 /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,
>>Chetan Mehrotra
>>
>>** Bug
>>* [SLING-5424] - MBeanServer reference in MetricServiceImpl should
>>be made optional
>>* [SLING-5899] - "Guages" Typo in Sling metrics console
>>
>>** Improvement
>>* [SLING-5443] - Review the naming conventions used by JMXReporter
>>to register the Metric MBeans
>>* [SLING-5693] - Add support for exporting MetricRegistry data as JSON
>>
>>** New Feature
>>* [SLING-5966] - Add Gauge support to metrics
>
>

Re: [VOTE] Release Apache Sling Commons Metrics 1.2.0

[Stefan Egli]

+1

Cheers,
Stefan

On 28/11/16 10:42, "Chetan Mehrotra"  wrote:

>Hi,
>
>We solved 5 issues in this release:
>https://issues.apache.org/jira/browse/SLING/fixforversion/12334646
>
>Staging repository:
>https://repository.apache.org/content/repositories/orgapachesling-1584
>
>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 1584 /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,
>Chetan Mehrotra
>
>** Bug
>* [SLING-5424] - MBeanServer reference in MetricServiceImpl should
>be made optional
>* [SLING-5899] - "Guages" Typo in Sling metrics console
>
>** Improvement
>* [SLING-5443] - Review the naming conventions used by JMXReporter
>to register the Metric MBeans
>* [SLING-5693] - Add support for exporting MetricRegistry data as JSON
>
>** New Feature
>* [SLING-5966] - Add Gauge support to metrics

[VOTE] Release Apache Sling Commons Metrics 1.2.0

[Chetan Mehrotra]

Hi,

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

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

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 1584 /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,
Chetan Mehrotra

** Bug
* [SLING-5424] - MBeanServer reference in MetricServiceImpl should
be made optional
* [SLING-5899] - "Guages" Typo in Sling metrics console

** Improvement
* [SLING-5443] - Review the naming conventions used by JMXReporter
to register the Metric MBeans
* [SLING-5693] - Add support for exporting MetricRegistry data as JSON

** New Feature
* [SLING-5966] - Add Gauge support to metrics

[jira] [Resolved] (SLING-5966) Add Gauge support to metrics

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra resolved SLING-5966.

Resolution: Fixed

> Add Gauge support to metrics
> 
>
> Key: SLING-5966
> URL: https://issues.apache.org/jira/browse/SLING-5966
> Project: Sling
>  Issue Type: New Feature
>  Components: Commons
>Affects Versions: Commons Metrics 1.0.0
>Reporter: Stefan Egli
>Assignee: Chetan Mehrotra
>  Labels: docs-impacting
> Fix For: Commons Metrics 1.2.0
>
>
> It would be useful to have support for {{Gauge}} in Sling Commons Metrics 
> (the same way as is done for the four other supported metrics types)



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

Re: How to handle minor version updates in API for provider bundles?

[Bertrand Delacretaz]

On Mon, Nov 28, 2016 at 9:50 AM, Konrad Windszus  wrote:
> ...There were no tests which had to be adjusted for the change, but in fact 
> there is a semantical change...

hmm...hmm...hmm...that vague feeling that the test coverage is not
what it should be ;-)

Did you add tests that demonstrate the new behavior?

-Bertrand

Re: How to handle minor version updates in API for provider bundles?

[Felix Meschberger]

> Am 28.11.2016 um 09:50 schrieb Konrad Windszus :
> @Felix: Regarding backwards compatibility: There were not tests which had to 
> be adjusted for the change, but in fact there is a semantical change. Please 
> look at https://issues.apache.org/jira/browse/SLING-6327 for further details.

Ok, technically it looks like it is breaking. But I have the impression, this 
makes sense and is more consistent with RR.getResource.

Thanks
Felix

> Konrad
> 
>> On 28 Nov 2016, at 09:42, Felix Meschberger  wrote:
>> 
>> Hi Konrad
>> 
>> Hmm, are these changed semantics backwards compatible ?
>> 
>> I.e. what do existing callers have to expect ?
>> 
>> Regards
>> Felix
>> 
>>> Am 26.11.2016 um 17:18 schrieb Konrad Windszus :
>>> 
>>> Moving the Util methods somewhere else (and even making that Util private) 
>>> is fine with me, but would not change anything about the minor version 
>>> number increase in the o.a.s.resource package.
>>> With the change in SLING-6327 the behaviour of Resource.isResourceType and 
>>> ResourceResolver.isResourceType has been changed (semantically) and 
>>> therefore requires at least a minor version upgrade to allow consumers to 
>>> specify a minimal version of that package (in case they rely on the new 
>>> semantics of those methods).
>>> Konrad
>>> 
 Am 26.11.2016 um 16:17 schrieb Julian Sedding :
 
 Thinking about this some more. I don't think the added method is
 generally useful for an API user, because the search-paths are
 normally not available. So I could imagine creating a ResourceTypeUtil
 class in the resourceresolver project to hold these new methods. We
 would thus not touch the Sling API and the utility could start out in
 a private package until we identify other places where we would need
 it.
 
 WDYT?
 
 Regards
 Julian
 
 
 On Fri, Nov 25, 2016 at 6:51 PM, Julian Sedding  wrote:
> I think the core problem is that we have provider-type classes and
> consumer-type classes mixed in packages of sling.api. Maybe we should
> start thinking about how to improve the situation there?
> 
> For now, I think what we normally do is update everything to snapshots
> that needs it and then start releasing.
> 
> Alternatively, we could stick with the lower dependency and duplicate
> the method you added until we want to update everything to the new
> api.
> 
> Regards
> Julian
> 
> On Fri, Nov 25, 2016 at 6:34 PM, Konrad Windszus
>  wrote:
>> With https://issues.apache.org/jira/browse/SLING-6327 I increased the 
>> minor version of o.a.s.resource from 2.9.0 to 2.10.0 (because of added 
>> methods to a ResourceUtil). That means that all provider bundles for 
>> this package (namely o.a.s.jcr.resource and o.a.s.resourceresolver) need 
>> to be recompiled with an updated dependency to the latest API snapshot, 
>> to make the latest SNAPSHOTs of all bundles compatible with each other 
>> (and generate the correct import-package version range in the provider 
>> bundles).
>> What is the suggested approach for doing that?
>> Just increase the dependency to the latest API snapshot again in all 
>> provider bundles for the according packages (although this will be 
>> prevent those provider bundles from being easily releasable, because API 
>> would need to be released first) or are there any other suggestions?
>> Thanks,
>> Konrad
>>> 
>> 
> 

Re: How to handle minor version updates in API for provider bundles?

[Julian Sedding]

Thanks Konrad for moving the implementation.

As I understand this issue, we *clarify* the semantics of
RR.isResourceType and fix the implementation to be fully aligned with
the fully defined semantics.

AFAIU, Konrad reported the issue, because the impl didn't match his
expectations. Bertrand and I agreed with this perception. So I am not
sure if we require a minor version increment or not. I believe an
equally valid argument could be made for either case - changed
semantics and implementation OR clarified semantics and fixed
implementation. I guess it boils down to a semantic difference ;)

I would lean towards no minor version increment, but have no strong
feelings either way.

Regards
Julian



On Mon, Nov 28, 2016 at 9:50 AM, Konrad Windszus  wrote:
> I moved the new util methods regarding the resource type comparison to a 
> private util class into the resource resolver bundle (in r1771688).
> The package version change still is necessary IMHO.
>
> @Felix: Regarding backwards compatibility: There were not tests which had to 
> be adjusted for the change, but in fact there is a semantical change. Please 
> look at https://issues.apache.org/jira/browse/SLING-6327 for further details.
> Konrad
>
>> On 28 Nov 2016, at 09:42, Felix Meschberger  wrote:
>>
>> Hi Konrad
>>
>> Hmm, are these changed semantics backwards compatible ?
>>
>> I.e. what do existing callers have to expect ?
>>
>> Regards
>> Felix
>>
>>> Am 26.11.2016 um 17:18 schrieb Konrad Windszus :
>>>
>>> Moving the Util methods somewhere else (and even making that Util private) 
>>> is fine with me, but would not change anything about the minor version 
>>> number increase in the o.a.s.resource package.
>>> With the change in SLING-6327 the behaviour of Resource.isResourceType and 
>>> ResourceResolver.isResourceType has been changed (semantically) and 
>>> therefore requires at least a minor version upgrade to allow consumers to 
>>> specify a minimal version of that package (in case they rely on the new 
>>> semantics of those methods).
>>> Konrad
>>>
 Am 26.11.2016 um 16:17 schrieb Julian Sedding :

 Thinking about this some more. I don't think the added method is
 generally useful for an API user, because the search-paths are
 normally not available. So I could imagine creating a ResourceTypeUtil
 class in the resourceresolver project to hold these new methods. We
 would thus not touch the Sling API and the utility could start out in
 a private package until we identify other places where we would need
 it.

 WDYT?

 Regards
 Julian


 On Fri, Nov 25, 2016 at 6:51 PM, Julian Sedding  wrote:
> I think the core problem is that we have provider-type classes and
> consumer-type classes mixed in packages of sling.api. Maybe we should
> start thinking about how to improve the situation there?
>
> For now, I think what we normally do is update everything to snapshots
> that needs it and then start releasing.
>
> Alternatively, we could stick with the lower dependency and duplicate
> the method you added until we want to update everything to the new
> api.
>
> Regards
> Julian
>
> On Fri, Nov 25, 2016 at 6:34 PM, Konrad Windszus
>  wrote:
>> With https://issues.apache.org/jira/browse/SLING-6327 I increased the 
>> minor version of o.a.s.resource from 2.9.0 to 2.10.0 (because of added 
>> methods to a ResourceUtil). That means that all provider bundles for 
>> this package (namely o.a.s.jcr.resource and o.a.s.resourceresolver) need 
>> to be recompiled with an updated dependency to the latest API snapshot, 
>> to make the latest SNAPSHOTs of all bundles compatible with each other 
>> (and generate the correct import-package version range in the provider 
>> bundles).
>> What is the suggested approach for doing that?
>> Just increase the dependency to the latest API snapshot again in all 
>> provider bundles for the according packages (although this will be 
>> prevent those provider bundles from being easily releasable, because API 
>> would need to be released first) or are there any other suggestions?
>> Thanks,
>> Konrad
>>>
>>
>

[jira] [Comment Edited] (SLING-6327) ResourceResolverImpl.isResourceType() should compare relative resource types (and ignore any search path prefixes)

[Konrad Windszus (JIRA)]

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

Konrad Windszus edited comment on SLING-6327 at 11/28/16 8:51 AM:
--

After some discussion in 
http://www.mail-archive.com/dev@sling.apache.org/msg62468.html I moved the util 
methods for the resource type to the resource resolver  in 
[r1771688|https://svn.apache.org/r1771688] (and therefore do no longer publicly 
exposd those in {{ResourceUtil}}). The minor version change of package 
{{o.a.s.resource}} is still necessary because the semantics of 
{{Resource.isResourceType(...)}} and {{ResourceResolver.isResourceType(...)}} 
as well as {{ResourceUtil.isA()}} changed slightly, although we assume that 
this does not break existing code. To make it possible for new code to 
explicitly rely on this new semantics a minor version increase is still 
necessary.


was (Author: kwin):
After some discussion in 
http://www.mail-archive.com/dev@sling.apache.org/msg62468.html I moved the util 
methods for the resource type to the resource resolver (and therefore no longer 
publicly exposed those {{ResourceUtil}}) in 
[r1771688|https://svn.apache.org/r1771688]. The minor version change of package 
{{o.a.s.resource}} is still necessary because the semantics of 
{{Resource.isResourceType(...)}} and {{ResourceResolver.isResourceType(...)}} 
as well as {{ResourceUtil.isA()}} changed slightly, although we assume that 
this does not break code. To make it possible for new code to explicitly rely 
on this new semantics a minor version increase is still necessary.

> ResourceResolverImpl.isResourceType() should compare relative resource types 
> (and ignore any search path prefixes)
> --
>
> Key: SLING-6327
> URL: https://issues.apache.org/jira/browse/SLING-6327
> Project: Sling
>  Issue Type: Improvement
>  Components: ResourceResolver
>Affects Versions: API 2.15.0, Resource Resolver 1.5.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: API 2.15.2, Resource Resolver 1.5.6
>
> Attachments: SLING-6327-v01.patch
>
>
> Currently the following two expressions return false
> {{ResourceResolverImpl.isResourceType( resourceType="sling/some/type">, "/libs/sling/some/type"}}
> {{ResourceResolverImpl.isResourceType( resourceType="/libs/sling/some/type">, "sling/some/type"}}
> Since it cannot always be influenced whether the given resource is absolute 
> or relative (because both usually works from a rendering perspective when you 
> talk about the current request's resource), both cases should actually return 
> {{true}}.
> See also the related discussion at 
> http://www.mail-archive.com/dev@sling.apache.org/msg62351.html



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

Re: How to handle minor version updates in API for provider bundles?

[Konrad Windszus]

I moved the new util methods regarding the resource type comparison to a 
private util class into the resource resolver bundle (in r1771688).
The package version change still is necessary IMHO.

@Felix: Regarding backwards compatibility: There were not tests which had to be 
adjusted for the change, but in fact there is a semantical change. Please look 
at https://issues.apache.org/jira/browse/SLING-6327 for further details.
Konrad

> On 28 Nov 2016, at 09:42, Felix Meschberger  wrote:
> 
> Hi Konrad
> 
> Hmm, are these changed semantics backwards compatible ?
> 
> I.e. what do existing callers have to expect ?
> 
> Regards
> Felix
> 
>> Am 26.11.2016 um 17:18 schrieb Konrad Windszus :
>> 
>> Moving the Util methods somewhere else (and even making that Util private) 
>> is fine with me, but would not change anything about the minor version 
>> number increase in the o.a.s.resource package.
>> With the change in SLING-6327 the behaviour of Resource.isResourceType and 
>> ResourceResolver.isResourceType has been changed (semantically) and 
>> therefore requires at least a minor version upgrade to allow consumers to 
>> specify a minimal version of that package (in case they rely on the new 
>> semantics of those methods).
>> Konrad
>> 
>>> Am 26.11.2016 um 16:17 schrieb Julian Sedding :
>>> 
>>> Thinking about this some more. I don't think the added method is
>>> generally useful for an API user, because the search-paths are
>>> normally not available. So I could imagine creating a ResourceTypeUtil
>>> class in the resourceresolver project to hold these new methods. We
>>> would thus not touch the Sling API and the utility could start out in
>>> a private package until we identify other places where we would need
>>> it.
>>> 
>>> WDYT?
>>> 
>>> Regards
>>> Julian
>>> 
>>> 
>>> On Fri, Nov 25, 2016 at 6:51 PM, Julian Sedding  wrote:
 I think the core problem is that we have provider-type classes and
 consumer-type classes mixed in packages of sling.api. Maybe we should
 start thinking about how to improve the situation there?
 
 For now, I think what we normally do is update everything to snapshots
 that needs it and then start releasing.
 
 Alternatively, we could stick with the lower dependency and duplicate
 the method you added until we want to update everything to the new
 api.
 
 Regards
 Julian
 
 On Fri, Nov 25, 2016 at 6:34 PM, Konrad Windszus
  wrote:
> With https://issues.apache.org/jira/browse/SLING-6327 I increased the 
> minor version of o.a.s.resource from 2.9.0 to 2.10.0 (because of added 
> methods to a ResourceUtil). That means that all provider bundles for this 
> package (namely o.a.s.jcr.resource and o.a.s.resourceresolver) need to be 
> recompiled with an updated dependency to the latest API snapshot, to make 
> the latest SNAPSHOTs of all bundles compatible with each other (and 
> generate the correct import-package version range in the provider 
> bundles).
> What is the suggested approach for doing that?
> Just increase the dependency to the latest API snapshot again in all 
> provider bundles for the according packages (although this will be 
> prevent those provider bundles from being easily releasable, because API 
> would need to be released first) or are there any other suggestions?
> Thanks,
> Konrad
>> 
> 

[jira] [Commented] (SLING-6327) ResourceResolverImpl.isResourceType() should compare relative resource types (and ignore any search path prefixes)

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-6327:


After some discussion in 
http://www.mail-archive.com/dev@sling.apache.org/msg62468.html I moved the util 
methods for the resource type to the resource resolver (and therefore no longer 
publicly exposed those {{ResourceUtil}}) in 
[r1771688|https://svn.apache.org/r1771688]. The minor version change of package 
{{o.a.s.resource}} is still necessary because the semantics of 
{{Resource.isResourceType(...)}} and {{ResourceResolver.isResourceType(...)}} 
as well as {{ResourceUtil.isA()}} changed slightly, although we assume that 
this does not break code. To make it possible for new code to explicitly rely 
on this new semantics a minor version increase is still necessary.

> ResourceResolverImpl.isResourceType() should compare relative resource types 
> (and ignore any search path prefixes)
> --
>
> Key: SLING-6327
> URL: https://issues.apache.org/jira/browse/SLING-6327
> Project: Sling
>  Issue Type: Improvement
>  Components: ResourceResolver
>Affects Versions: API 2.15.0, Resource Resolver 1.5.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: API 2.15.2, Resource Resolver 1.5.6
>
> Attachments: SLING-6327-v01.patch
>
>
> Currently the following two expressions return false
> {{ResourceResolverImpl.isResourceType( resourceType="sling/some/type">, "/libs/sling/some/type"}}
> {{ResourceResolverImpl.isResourceType( resourceType="/libs/sling/some/type">, "sling/some/type"}}
> Since it cannot always be influenced whether the given resource is absolute 
> or relative (because both usually works from a rendering perspective when you 
> talk about the current request's resource), both cases should actually return 
> {{true}}.
> See also the related discussion at 
> http://www.mail-archive.com/dev@sling.apache.org/msg62351.html



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

Re: How to handle minor version updates in API for provider bundles?

[Felix Meschberger]

Hi Konrad

Hmm, are these changed semantics backwards compatible ?

I.e. what do existing callers have to expect ?

Regards
Felix

> Am 26.11.2016 um 17:18 schrieb Konrad Windszus :
> 
> Moving the Util methods somewhere else (and even making that Util private) is 
> fine with me, but would not change anything about the minor version number 
> increase in the o.a.s.resource package.
> With the change in SLING-6327 the behaviour of Resource.isResourceType and 
> ResourceResolver.isResourceType has been changed (semantically) and therefore 
> requires at least a minor version upgrade to allow consumers to specify a 
> minimal version of that package (in case they rely on the new semantics of 
> those methods).
> Konrad
> 
>> Am 26.11.2016 um 16:17 schrieb Julian Sedding :
>> 
>> Thinking about this some more. I don't think the added method is
>> generally useful for an API user, because the search-paths are
>> normally not available. So I could imagine creating a ResourceTypeUtil
>> class in the resourceresolver project to hold these new methods. We
>> would thus not touch the Sling API and the utility could start out in
>> a private package until we identify other places where we would need
>> it.
>> 
>> WDYT?
>> 
>> Regards
>> Julian
>> 
>> 
>> On Fri, Nov 25, 2016 at 6:51 PM, Julian Sedding  wrote:
>>> I think the core problem is that we have provider-type classes and
>>> consumer-type classes mixed in packages of sling.api. Maybe we should
>>> start thinking about how to improve the situation there?
>>> 
>>> For now, I think what we normally do is update everything to snapshots
>>> that needs it and then start releasing.
>>> 
>>> Alternatively, we could stick with the lower dependency and duplicate
>>> the method you added until we want to update everything to the new
>>> api.
>>> 
>>> Regards
>>> Julian
>>> 
>>> On Fri, Nov 25, 2016 at 6:34 PM, Konrad Windszus
>>>  wrote:
 With https://issues.apache.org/jira/browse/SLING-6327 I increased the 
 minor version of o.a.s.resource from 2.9.0 to 2.10.0 (because of added 
 methods to a ResourceUtil). That means that all provider bundles for this 
 package (namely o.a.s.jcr.resource and o.a.s.resourceresolver) need to be 
 recompiled with an updated dependency to the latest API snapshot, to make 
 the latest SNAPSHOTs of all bundles compatible with each other (and 
 generate the correct import-package version range in the provider bundles).
 What is the suggested approach for doing that?
 Just increase the dependency to the latest API snapshot again in all 
 provider bundles for the according packages (although this will be prevent 
 those provider bundles from being easily releasable, because API would 
 need to be released first) or are there any other suggestions?
 Thanks,
 Konrad
> 

Re: trunk build does not work // was: mountByFS does not work

[Bertrand Delacretaz]

Hi Sandro,

On Sun, Nov 27, 2016 at 11:39 PM, Sandro Boehme  wrote:
> ...Is there a launchpad version somewhere that compiles the latest
> snapshots to the standalone jar?...

We've been discussing generating that [1] along with a "stable"
launchpad but that's not done yet.

-Bertrand

[1] 
https://cwiki.apache.org/confluence/display/SLING/Moving+the+Sling+Launchpad+to+use+released+artifacts+only

Re: How to handle minor version updates in API for provider bundles?

[Bertrand Delacretaz]

On Sat, Nov 26, 2016 at 5:18 PM, Konrad Windszus  wrote:
> ...With the change in SLING-6327 the behaviour of Resource.isResourceType and 
> ResourceResolver.isResourceType
> has been changed (semantically) and therefore requires at least a minor 
> version upgrade to allow consumers to specify
> a minimal version of that package (in case they rely on the new semantics of 
> those methods)...

+1 and also +1 to avoid exposing new methods unless absolutely needed.

-Bertrand