Re: Wiki access

[Suren Konathala]

Thanks much.

There are several topics I thought we can add. Will send my thoughts here.

-Suren
On Wed, Jun 7, 2017 at 4:37 AM Bertrand Delacretaz 
wrote:

> On Tue, Jun 6, 2017 at 7:31 PM, Suren Konathala
>  wrote:
> > ...My confluence username is "suren" ...
>
> You should now be able to create content at
> https://cwiki.apache.org/confluence/display/SLING/Index
>
> Feel free to discuss changes here.
>
> -Bertrand
>

Sling Node Type Web Console Plugin

[Andreas Schaefer Sr.]

Hi

Twice in a row was I faced with the question what Node Types are deployed in 
Sling and what is its hierarchy.

I know there is this XML web page: 
http://localhost:8080/_jcr_system/_jcr_nodeTypes.xml 


but that one is not very user friendly and hard to find.

Would you guys be interested in a Web Console Plugin that shows the installed 
Node Types with their hierarchy
in a way similar the “good-old CRX Explorer” from AEM?

Or at least a page that has anchors and links so that the user can jump through 
the hierarchy and find the necessary
data.

Cheers - Andy

[jira] [Closed] (SLING-6891) Retire xss.compat to the attic

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6891.
-

> Retire xss.compat to the attic
> --
>
> Key: SLING-6891
> URL: https://issues.apache.org/jira/browse/SLING-6891
> Project: Sling
>  Issue Type: Sub-task
>  Components: XSS Protection API
>Affects Versions: XSS Protection API Compat 1.1.0
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>
> We should probably retire the xss.compat bundle to the attic as we can't 
> release it anymore anyhow.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (SLING-6889) Retire commons.json to the attic

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6889.
-

> Retire commons.json to the attic
> 
>
> Key: SLING-6889
> URL: https://issues.apache.org/jira/browse/SLING-6889
> Project: Sling
>  Issue Type: Sub-task
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>
> When we are done using it in the trunk we should retire commons.json to the 
> attic (as we can't release it anymore anyways).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (SLING-6900) Remove commons.json from Log Tracer

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6900.
-

> Remove commons.json from Log Tracer
> ---
>
> Key: SLING-6900
> URL: https://issues.apache.org/jira/browse/SLING-6900
> Project: Sling
>  Issue Type: Sub-task
>Affects Versions: Log Tracer 1.0.2
>Reporter: Karl Pauls
>Assignee: Karl Pauls
> Fix For: Log Tracer 1.0.4
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (SLING-6898) Remove commons.json from Resource Inventory

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6898.
-

> Remove commons.json from Resource Inventory
> ---
>
> Key: SLING-6898
> URL: https://issues.apache.org/jira/browse/SLING-6898
> Project: Sling
>  Issue Type: Sub-task
>Affects Versions: Resource Inventory 1.0.6
>Reporter: Karl Pauls
>Assignee: Karl Pauls
> Fix For: Resource Inventory 1.0.8
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (SLING-6927) Fix testing.junit.core JsonRenderer

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6927.
-

> Fix testing.junit.core JsonRenderer
> ---
>
> Key: SLING-6927
> URL: https://issues.apache.org/jira/browse/SLING-6927
> Project: Sling
>  Issue Type: Sub-task
>  Components: JUnit Core
>Affects Versions: JUnit Core 1.0.24
>Reporter: Karl Pauls
>Assignee: Karl Pauls
> Fix For: JUnit Core 1.0.26
>
>
> The JsonRenderer in Junit Core is broken. It needs a flush to send out the 
> json correctly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (SLING-6905) Remove commons.json from testing http clients

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6905.
-

> Remove commons.json from testing http clients
> -
>
> Key: SLING-6905
> URL: https://issues.apache.org/jira/browse/SLING-6905
> Project: Sling
>  Issue Type: Sub-task
>  Components: Apache Sling Testing Clients
>Affects Versions: Apache Sling Testing Clients 1.0.1
>Reporter: Karl Pauls
>Assignee: Karl Pauls
> Fix For: Apache Sling Testing Clients 1.1.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (SLING-6853) Improve polling capabilities in o.a.s.testing.clients

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6853.
-

> Improve polling capabilities in o.a.s.testing.clients
> -
>
> Key: SLING-6853
> URL: https://issues.apache.org/jira/browse/SLING-6853
> Project: Sling
>  Issue Type: Improvement
>  Components: Apache Sling Testing Clients
>Affects Versions: Apache Sling Testing Clients 1.0.1
>Reporter: Valentin Olteanu
>Assignee: Andrei Dulvac
> Fix For: Apache Sling Testing Clients 1.1.0
>
>
> Polling is an important part of the testing clients, yet the current 
> implementation lacks homogeneity.
> The proposed patch ([PR#227|https://github.com/apache/sling/pull/227]):
> # defines a standard way to write {{wait}} methods: {{void wait(long timeout, 
> long delay) throws TimeoutException, InterruptedException}} 
> ** where parameters are in milliseconds
> ** that is in line with other java waiting methods (e.g. {{Timer}})
> ** Throws {{TimeoutException}} instead of returning a status
> ** Leverages {{TimeoutsProvider}}
> # brings a new poller called (uninspiredly) {{Polling}}
> ** extends {{Callable}} to follow the Single Abstract Method paradigm
> ** can make use of lambda expressions
> ** simplifies the wait logic, compared to the old Poller: repeat {{call()}} 
> with fixed delays in between, until it returns true or the timeout is reached
> # deprecates confusing methods that were waiting for resources when it was 
> not the case.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (SLING-6838) Do not use persistence connections in SCD HTTP

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6838.
-

> Do not use persistence connections in SCD HTTP
> --
>
> Key: SLING-6838
> URL: https://issues.apache.org/jira/browse/SLING-6838
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution Core 0.2.8
>
>
> In order to avoid connections to stale it'd be better to let explicitly avoid 
> persistent connections (aka keep-alive) in HTTP requests.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (SLING-6781) VltUtils only keep the last filter for a given path

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6781.
-

> VltUtils only keep the last filter for a given path
> ---
>
> Key: SLING-6781
> URL: https://issues.apache.org/jira/browse/SLING-6781
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.6
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: Content Distribution Core 0.2.8
>
>
> The utility method VltUtils#parseFilters [0] does not merge the definitions 
> for the same path. As an example providing the filters
> {code}
> new String[]{"/home/users|-.*/.tokens","/home/users|-.*/.rep:cache"}
> {code}
> will return a tree map with only one entry ({{.*/.rep:cache}}) for the path 
> {{/home/users}}).
> [0] 
> https://github.com/apache/sling/blob/trunk/contrib/extensions/distribution/core/src/main/java/org/apache/sling/distribution/serialization/impl/vlt/VltUtils.java#L305-L338
>  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (SLING-6596) Typo: "guage" instead of "gauge" in metrics module

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6596.
-

> Typo: "guage" instead of "gauge" in metrics module
> --
>
> Key: SLING-6596
> URL: https://issues.apache.org/jira/browse/SLING-6596
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Affects Versions: Commons Metrics 1.2.0
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Fix For: Commons Metrics 1.2.2
>
>
> The JSON produced by the metrics module uses "guage" instead of "gauge"



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (SLING-6907) Remove commons.json from Tooling Support Install

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6907.
-

> Remove commons.json from Tooling Support Install
> 
>
> Key: SLING-6907
> URL: https://issues.apache.org/jira/browse/SLING-6907
> Project: Sling
>  Issue Type: Sub-task
>  Components: Tooling
>Affects Versions: Tooling Support Install 1.0.2
>Reporter: Karl Pauls
>Assignee: Karl Pauls
> Fix For: Tooling Support Install 1.0.4
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (SLING-6527) Remove usage of org.json from metrics module

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6527.
-

> Remove usage of org.json from metrics module
> 
>
> Key: SLING-6527
> URL: https://issues.apache.org/jira/browse/SLING-6527
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Commons Metrics 1.2.2
>
>
> We have to replace the usage of org.json.
> In this case we can easily embed the JSONWriter from the Apache Felix Utils 
> module



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (SLING-6908) Remove commons.json from Tooling Support Source

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6908.
-

> Remove commons.json from Tooling Support Source
> ---
>
> Key: SLING-6908
> URL: https://issues.apache.org/jira/browse/SLING-6908
> Project: Sling
>  Issue Type: Sub-task
>  Components: Tooling
>Affects Versions: Tooling Support Source 1.0.2
>Reporter: Karl Pauls
>Assignee: Karl Pauls
> Fix For: Tooling Support Source 1.0.4
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (SLING-6885) Tooling support bundles no longer work due to dependency on org.apache.sling.commons.json

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6885.
-

> Tooling support bundles no longer work due to dependency on 
> org.apache.sling.commons.json
> -
>
> Key: SLING-6885
> URL: https://issues.apache.org/jira/browse/SLING-6885
> Project: Sling
>  Issue Type: Bug
>  Components: Tooling
>Affects Versions: Tooling Support Install 1.0.2, Tooling Support Source 
> 1.0.2
>Reporter: Robert Munteanu
>Assignee: Karl Pauls
> Fix For: Tooling Support Install 1.0.4, Tooling Support Source 
> 1.0.4
>
>
> When deployed, both of these bundles fail to resolve due to importing:
> {noformat}org.apache.sling.commons.json,version=[2.0,3)
> org.apache.sling.commons.json.io,version=[2.0,3){noformat}
> Without thinking too much about it, I would venture to say the simplest way 
> to support both all versions of the Sling launchpad and other variants such 
> as AEM is to embed a JSON parser in the bundles and use that.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (SLING-6638) Vault Package Builder should not allow SHA1, MD5 digest algorithm

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6638.
-

> Vault Package Builder should not allow SHA1, MD5 digest algorithm
> -
>
> Key: SLING-6638
> URL: https://issues.apache.org/jira/browse/SLING-6638
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.6
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: Content Distribution Core 0.2.8
>
>
> The {{VaultDistributionPackageBuilderFactory}} [0] proposes the MD5, MD2 and 
> SHA-1 algorithms, for which collisions could realistically be forged.
> SCD makes use of those algorithm for error detection (like a CRC) and not for 
> security. Despite that, we should deprecate the use of those algorithms IMO.
> I propose to remove the three algorithms form the list of proposals, and 
> throw and exception if a non supported algorithm is used. The component end 
> up not being activated unless the configuration is corrected. 
> [0] 
> https://github.com/apache/sling/blob/trunk/contrib/extensions/distribution/core/src/main/java/org/apache/sling/distribution/serialization/impl/vlt/VaultDistributionPackageBuilderFactory.java#L191-L193



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (SLING-6874) sling-mock: Support tick as well as double quote when parsing JSON files

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6874.
-

> sling-mock: Support tick as well as double quote when parsing JSON files
> 
>
> Key: SLING-6874
> URL: https://issues.apache.org/jira/browse/SLING-6874
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: Testing Sling Mock 1.9.8, Testing Sling Mock 2.2.10
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: mocks
> Fix For: Testing Sling Mock 2.2.12, Testing Sling Mock 1.9.10
>
>
> apply SLING-6872 to sling mocks.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (SLING-4321) Sling JUnit Remote should depend on SLF4J with Compile Scope

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-4321.
-

> Sling JUnit Remote should depend on SLF4J with Compile Scope
> 
>
> Key: SLING-4321
> URL: https://issues.apache.org/jira/browse/SLING-4321
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: JUnit Remote Tests Runners 1.0.10
>Reporter: Konrad Windszus
> Fix For: JUnit Remote Test Runners 1.0.12
>
>
> Currently Sling JUnit Remote (org.apache.sling.junit.remote, 1.0.10) depends 
> on SLF4J with scope {{provided}}. Therefore it is not available for a Maven 
> Module (e.g. a JAR which executes the test on the remote instance), if that 
> one only depends on org.apache.sling.junit.remote.
> That JAR needs to add the dependency to SLF4J explicitly (even if the classes 
> within the JAR directly do not need that), just because the Sling Remove Test 
> Runner needs that on the classpath.
> Since that dependency may be used at runtime outside of an OSGI container 
> (why is that a bundle anyways?), e.g. by the maven-failsafe-plugin it should 
> declare all runtime dependencies with scope {{compile}} or {{runtime}}.
> Currently if the maven-failsafe-plugin is executing a test annotated with 
> SlingTestRunner and the dependency to SLF4J is not added it fails with the 
> following error:
> {code}
> java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
>   at 
> org.apache.sling.junit.remote.testrunner.SlingRemoteTestRunner.(SlingRemoteTestRunner.java:46)
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
>   at 
> org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:29)
>   at 
> org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:21)
>   at 
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
>   at 
> org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26)
>   at 
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
>   at 
> org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:26)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:262)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> Caused by: java.lang.ClassNotFoundException: org.slf4j.LoggerFactory
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:372)
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:360)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>   at 
> org.apache.sling.junit.remote.testrunner.SlingRemoteTestRunner.(SlingRemoteTestRunner.java:46)
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
>   at 
> org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:29)
>   at 
> org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:21)
>   at 
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
>   at 
> org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26)
>   at 
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
>   at 
> org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:26)
>   at 
> 

[jira] [Closed] (SLING-6848) Package level monitoring should be only enabled consciously

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6848.
-

> Package level monitoring should be only enabled consciously
> ---
>
> Key: SLING-6848
> URL: https://issues.apache.org/jira/browse/SLING-6848
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution Core 0.2.8
>
> Attachments: SLING-6848.0.patch
>
>
> I have noticed that by default all {{DistributionPackages}} get an MBean 
> registered by {{MonitoringDistributionPackageBuilder}}. 
> While that's fine for monitoring purposes, I think that slows down a 
> distribution request a bit, therefore I was wondering if it wouldn't be 
> better to set the default _monitored package size_ to 0 (currently it's 100) 
> and do MBean registration only if that value is higher than 0.
> [~simone.tripodi] what do you think ?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (SLING-5952) Add support for configurable SO and connection timeouts

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-5952.
-

> Add support for configurable SO and connection timeouts
> ---
>
> Key: SLING-5952
> URL: https://issues.apache.org/jira/browse/SLING-5952
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Timothee Maret
>Assignee: Tommaso Teofili
> Fix For: Content Distribution Core 0.2.8
>
> Attachments: SLING-SLING-5952.0.patch
>
>
> Currently the SDC transport is using the default HTTP client timeouts
> 1. Connection Timeout (by default it is infinite)
> 2. SO Socket Timeout (by default it is infinite)
> Allowing to configure a bounded timeouts is needed in most deployments in 
> order to avoid leaving a resource stuck.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (SLING-6906) Remove commons.json from testing junit remote

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6906.
-

> Remove commons.json from testing junit remote
> -
>
> Key: SLING-6906
> URL: https://issues.apache.org/jira/browse/SLING-6906
> Project: Sling
>  Issue Type: Sub-task
>  Components: Testing
>Affects Versions: JUnit Remote Tests Runners 1.0.10
>Reporter: Karl Pauls
>Assignee: Karl Pauls
> Fix For: JUnit Remote Test Runners 1.0.12
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (SLING-6892) Remove commons.json from Content Distribution Core

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6892.
-

> Remove commons.json from Content Distribution Core
> --
>
> Key: SLING-6892
> URL: https://issues.apache.org/jira/browse/SLING-6892
> Project: Sling
>  Issue Type: Sub-task
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.6
>Reporter: Karl Pauls
>Assignee: Karl Pauls
> Fix For: Content Distribution Core 0.2.8
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (SLING-6611) Improve FileVaultContentSerializer performance

[Karl Pauls (JIRA)]

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

Karl Pauls closed SLING-6611.
-

> Improve FileVaultContentSerializer performance
> --
>
> Key: SLING-6611
> URL: https://issues.apache.org/jira/browse/SLING-6611
> Project: Sling
>  Issue Type: Improvement
>  Components: Content Distribution
>Reporter: Tommaso Teofili
>Assignee: Timothee Maret
> Fix For: Content Distribution Core 0.2.8
>
>
> It would be good if we could improve FileVault serializer performance by 
> avoiding writing several (temp) files on FS and avoid compressing binaries 
> that are already compressed (e.g. images like jpg, png, etc.).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (SLING-6939) sling distribution leaks jcr sessions

[Timothee Maret (JIRA)]

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

Timothee Maret resolved SLING-6939.
---
Resolution: Fixed

> sling distribution leaks jcr sessions
> -
>
> Key: SLING-6939
> URL: https://issues.apache.org/jira/browse/SLING-6939
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.6
>Reporter: Will McGauley
>Assignee: Timothee Maret
>Priority: Blocker
> Fix For: Content Distribution Core 0.2.10
>
> Attachments: SLING_6939.patch
>
>
> The code for acquiring a ResourceResolver in sling distribution core leaks a 
> JCR Session.  In tests I was running 50,000 sessions were leaked.
> The code in DistributionUtils.getResourceResolver() creates a Session, then 
> passes it to the ResourceResolver.getServiceResolver in the map with the key 
> "user.jcr.credentials".  This means the Session passed in is ignored (the 
> correct key would have been "user.jcr.session"), and a new session is created 
> for the service user configured - resulting in a new session.  When the 
> Resource Resolver is cleaned up the associated session is not the same as the 
> abandoned session, meaning the original session (created on line number 89 of 
> DistributionUtils) is never closed.
> Please see attached patch for a possible solution which specifies the session 
> in the ResourceResolverFactory correctly.  I have tested this locally and it 
> appears to work correctly, however it does change the behaviour because a 
> different user is not used (the caller).  I did not run any automated tests.
> Also please be aware that it appears that the method "process" of the class 
> ImportingDistributionPackageProcessor appears to never close the 
> ResourceResolver acquired from the DistributionUtils.getResourceResolver() 
> utility, please have a look.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (SLING-848) Support getting versioned resources by using uri path parameters

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek edited comment on SLING-848 at 6/7/17 7:34 PM:
-

[~cziegeler] {quote}Looking at the quoted example, this really looks like a 
test string. So I'm wondering how likely this is to happen in real world.{quote}
Yes, it's a test string, and I agree it should be pretty rare.

*However*, my experience tells me that especially at such a fundamental layer 
as the resource API, rare or not rare is not something you can decide as the 
framework provider and it might even change over time. What if someone actually 
stores names with such parameters deliberately as resources for some 
meta-reason? There is also no other restriction that the resource API imposes 
on names (other than slashes as path delimiters) as far as I know, and this 
case seems not strong enough to start imposing a limit after the API has 
existed for ~7 years (before this change). Hence I think these names should be 
safely supported.

Furthermore, it isn't even clearly documented anywhere, and as the discussion 
shows, we don't have an exact description of the format and what an "invalid" 
resource path would be, assuming nothing is changed.

I would look at option 2 and see if that works (after the general questions are 
answered).

Although I think it's still a problem of mixing URLs (where these parameters 
come in) and the resource namespace, which came in by sharing the same 
implementation (getResourceInternal) between resolve() and getResource(), while 
it should probably be separated, so the parameter parsing happens for resolve() 
only and other means given to retrieve things with parameter if you are a 
client using getResource() semantics.


was (Author: alexander.klimetschek):
[~cziegeler] {quote}Looking at the quoted example, this really looks like a 
test string. So I'm wondering how likely this is to happen in real world.{quote}
Yes, it's a test string, and I agree it should be pretty rare.

*However*, my experience tells me that especially at such a fundamental layer 
as the resource API, rare or not rare is not something you can decide as the 
framework provider and it might even change over time. What if someone actually 
stores names with such parameters deliberately as resources for some 
meta-reason? There is also no other restriction that the resource API imposes 
on names (other than slashes as path delimiters) as far as I know, and this 
case seems not strong enough to start imposing a limit after the API has 
existed for ~7 years (before this change). Hence I think these names should be 
safely supported.

Furthermore, it isn't even clearly documented anywhere, and as the discussion 
shows, we don't have an exact description of the format and what an "invalid" 
resource path would be, assuming nothing is changed.

I would look at option 2 and see if that works (after the general questions are 
answered). Although I think it's still a problem of mixing URLs (where these 
parameters come in) and the resource namespace, which came in by sharing the 
same implementation (getResourceInternal) between resolve() and getResource(), 
while it should probably be separated, so the parameter parsing happens for 
resolve() only and other means given to retrieve things with parameter if you 
are a client using getResource() semantics.

> Support getting versioned resources by using uri path parameters
> 
>
> Key: SLING-848
> URL: https://issues.apache.org/jira/browse/SLING-848
> Project: Sling
>  Issue Type: New Feature
>  Components: API, JCR, ResourceResolver
>Affects Versions: JCR Resource 2.0.2
>Reporter: Carsten Ziegeler
>Assignee: Tomek Rękawek
> Fix For: JCR Resource 2.5.0, API 2.9.0, Resource Resolver 1.2.0
>
> Attachments: SLING-848-metadata.patch
>
>
> Getting versioned content should be support thorough uri path parameters, 
> like /something/hello;v=1.1
> For jcr based resources the value of the version should either point to a 
> version name or label.
> In order to not change our existing apis, we introduce a new utility method 
> which removes all uri path parameters
> and returns a map of these. Every resource provider could use this utility 
> method and then decide to act on these
> parameters.
> If a requested version does not exists, a 404 is returned.
> If the requested node does not directly point to a versionable node, the 
> algorithm checks the parent hierarchy until a versionable node is found, and 
> tries to get the version of this node and then goes down the path again. If 
> the versionable node does not have the requested version or the child, a 404 
> is returned.



--
This message was sent 

[jira] [Comment Edited] (SLING-848) Support getting versioned resources by using uri path parameters

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek edited comment on SLING-848 at 6/7/17 7:34 PM:
-

[~cziegeler] {quote}Looking at the quoted example, this really looks like a 
test string. So I'm wondering how likely this is to happen in real world.{quote}
Yes, it's a test string, and I agree it should be pretty rare.

*However*, my experience tells me that especially at such a fundamental layer 
as the resource API, rare or not rare is not something you can decide as the 
framework provider and it might even change over time. What if someone actually 
stores names with such parameters deliberately as resources for some 
meta-reason? There is also no other restriction that the resource API imposes 
on names (other than slashes as path delimiters) as far as I know, and this 
case seems not strong enough to start imposing a limit after the API has 
existed for ~7 years (before this change). Hence I think these names should be 
safely supported.

Furthermore, it isn't even clearly documented anywhere, and as the discussion 
shows, we don't have an exact description of the format and what an "invalid" 
resource path would be, assuming nothing is changed.

I would look at option 2 and see if that works (after the general questions are 
answered). Although I think it's still a problem of mixing URLs (where these 
parameters come in) and the resource namespace, which came in by sharing the 
same implementation (getResourceInternal) between resolve() and getResource(), 
while it should probably be separated, so the parameter parsing happens for 
resolve() only and other means given to retrieve things with parameter if you 
are a client using getResource() semantics.


was (Author: alexander.klimetschek):
[~cziegeler] {quote}Looking at the quoted example, this really looks like a 
test string. So I'm wondering how likely this is to happen in real world.{quote}
Yes, it's a test string, and I agree it should be pretty rare.

*However*, my experience tells me that especially at such a fundamental layer 
as the resource API, rare or not rare is not something you can decide as the 
framework provider and it might even change over time. What if someone actually 
stores names with such parameters deliberately as resources for some 
meta-reason? There is also no other restriction that the resource API imposes 
on names (other than slashes as path delimiters) as far as I know, and this 
case seems not strong enough to start imposing a limit after the API has 
existed for ~7 years (before this change). Hence I think these names should be 
safely supported.

Furthermore, it isn't even clearly documented anywhere, and as the discussion 
shows, we don't have an exact description of the format and what an "invalid" 
resource path would be, assuming nothing is changed.

I would look at option 2 and see if that works (after the general questions are 
answered).

> Support getting versioned resources by using uri path parameters
> 
>
> Key: SLING-848
> URL: https://issues.apache.org/jira/browse/SLING-848
> Project: Sling
>  Issue Type: New Feature
>  Components: API, JCR, ResourceResolver
>Affects Versions: JCR Resource 2.0.2
>Reporter: Carsten Ziegeler
>Assignee: Tomek Rękawek
> Fix For: JCR Resource 2.5.0, API 2.9.0, Resource Resolver 1.2.0
>
> Attachments: SLING-848-metadata.patch
>
>
> Getting versioned content should be support thorough uri path parameters, 
> like /something/hello;v=1.1
> For jcr based resources the value of the version should either point to a 
> version name or label.
> In order to not change our existing apis, we introduce a new utility method 
> which removes all uri path parameters
> and returns a map of these. Every resource provider could use this utility 
> method and then decide to act on these
> parameters.
> If a requested version does not exists, a 404 is returned.
> If the requested node does not directly point to a versionable node, the 
> algorithm checks the parent hierarchy until a versionable node is found, and 
> tries to get the version of this node and then goes down the path again. If 
> the versionable node does not have the requested version or the child, a 404 
> is returned.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (SLING-6939) sling distribution leaks jcr sessions

[Timothee Maret (JIRA)]

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

Timothee Maret edited comment on SLING-6939 at 6/7/17 7:32 PM:
---

Fixed in r1797982 ({{DistributionUtils}})  & r1797988 
({{ImportingDistributionPackageProcessor}})


was (Author: marett):
Fixed in r1797982, 
https://github.com/apache/sling/commit/7da0325bb6e9936f24f01d13846515960f48f171

> sling distribution leaks jcr sessions
> -
>
> Key: SLING-6939
> URL: https://issues.apache.org/jira/browse/SLING-6939
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.6
>Reporter: Will McGauley
>Assignee: Timothee Maret
>Priority: Blocker
> Fix For: Content Distribution Core 0.2.10
>
> Attachments: SLING_6939.patch
>
>
> The code for acquiring a ResourceResolver in sling distribution core leaks a 
> JCR Session.  In tests I was running 50,000 sessions were leaked.
> The code in DistributionUtils.getResourceResolver() creates a Session, then 
> passes it to the ResourceResolver.getServiceResolver in the map with the key 
> "user.jcr.credentials".  This means the Session passed in is ignored (the 
> correct key would have been "user.jcr.session"), and a new session is created 
> for the service user configured - resulting in a new session.  When the 
> Resource Resolver is cleaned up the associated session is not the same as the 
> abandoned session, meaning the original session (created on line number 89 of 
> DistributionUtils) is never closed.
> Please see attached patch for a possible solution which specifies the session 
> in the ResourceResolverFactory correctly.  I have tested this locally and it 
> appears to work correctly, however it does change the behaviour because a 
> different user is not used (the caller).  I did not run any automated tests.
> Also please be aware that it appears that the method "process" of the class 
> ImportingDistributionPackageProcessor appears to never close the 
> ResourceResolver acquired from the DistributionUtils.getResourceResolver() 
> utility, please have a look.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek commented on SLING-848:
-

[~cziegeler] {quote}Looking at the quoted example, this really looks like a 
test string. So I'm wondering how likely this is to happen in real world.{quote}
Yes, it's a test string, and I agree it should be pretty rare.

*However*, my experience tells me that especially at such a fundamental layer 
as the resource API, rare or not rare is not something you can decide as the 
framework provider and it might even change over time. What if someone actually 
stores names with such parameters deliberately as resources for some 
meta-reason? There is also no other restriction that the resource API imposes 
on names (other than slashes as path delimiters) as far as I know, and this 
case seems not strong enough to start imposing a limit after the API has 
existed for ~7 years (before this change). Hence I think these names should be 
safely supported.

Furthermore, it isn't even clearly documented anywhere, and as the discussion 
shows, we don't have an exact description of the format and what an "invalid" 
resource path would be, assuming nothing is changed.

I would look at option 2 and see if that works (after the general questions are 
answered).

> Support getting versioned resources by using uri path parameters
> 
>
> Key: SLING-848
> URL: https://issues.apache.org/jira/browse/SLING-848
> Project: Sling
>  Issue Type: New Feature
>  Components: API, JCR, ResourceResolver
>Affects Versions: JCR Resource 2.0.2
>Reporter: Carsten Ziegeler
>Assignee: Tomek Rękawek
> Fix For: JCR Resource 2.5.0, API 2.9.0, Resource Resolver 1.2.0
>
> Attachments: SLING-848-metadata.patch
>
>
> Getting versioned content should be support thorough uri path parameters, 
> like /something/hello;v=1.1
> For jcr based resources the value of the version should either point to a 
> version name or label.
> In order to not change our existing apis, we introduce a new utility method 
> which removes all uri path parameters
> and returns a map of these. Every resource provider could use this utility 
> method and then decide to act on these
> parameters.
> If a requested version does not exists, a 404 is returned.
> If the requested node does not directly point to a versionable node, the 
> algorithm checks the parent hierarchy until a versionable node is found, and 
> tries to get the version of this node and then goes down the path again. If 
> the versionable node does not have the requested version or the child, a 404 
> is returned.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6939) sling distribution leaks jcr sessions

[Timothee Maret (JIRA)]

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

Timothee Maret commented on SLING-6939:
---

Fixed in r1797982, 
https://github.com/apache/sling/commit/7da0325bb6e9936f24f01d13846515960f48f171

> sling distribution leaks jcr sessions
> -
>
> Key: SLING-6939
> URL: https://issues.apache.org/jira/browse/SLING-6939
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.6
>Reporter: Will McGauley
>Assignee: Timothee Maret
>Priority: Blocker
> Fix For: Content Distribution Core 0.2.10
>
> Attachments: SLING_6939.patch
>
>
> The code for acquiring a ResourceResolver in sling distribution core leaks a 
> JCR Session.  In tests I was running 50,000 sessions were leaked.
> The code in DistributionUtils.getResourceResolver() creates a Session, then 
> passes it to the ResourceResolver.getServiceResolver in the map with the key 
> "user.jcr.credentials".  This means the Session passed in is ignored (the 
> correct key would have been "user.jcr.session"), and a new session is created 
> for the service user configured - resulting in a new session.  When the 
> Resource Resolver is cleaned up the associated session is not the same as the 
> abandoned session, meaning the original session (created on line number 89 of 
> DistributionUtils) is never closed.
> Please see attached patch for a possible solution which specifies the session 
> in the ResourceResolverFactory correctly.  I have tested this locally and it 
> appears to work correctly, however it does change the behaviour because a 
> different user is not used (the caller).  I did not run any automated tests.
> Also please be aware that it appears that the method "process" of the class 
> ImportingDistributionPackageProcessor appears to never close the 
> ResourceResolver acquired from the DistributionUtils.getResourceResolver() 
> utility, please have a look.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6942) DistributionUtils#getResourceResolver should use the user session

[Timothee Maret (JIRA)]

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

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

The cause seems to be that 
{{ResourceResolverFactory#getServiceResourceResolver}} rightfully (per API [0]) 
does not honour the {{user.jcr.session}} parameter.

Attaching a patch to solve the issue.

[0] 
https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/ResourceResolverFactory.java#L162-L189

> DistributionUtils#getResourceResolver should use the user session
> -
>
> Key: SLING-6942
> URL: https://issues.apache.org/jira/browse/SLING-6942
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.1.12
>Reporter: Timothee Maret
> Attachments: SLING-6942.patch
>
>
> According to SLING-5281, the resource resolver should use the user session 
> when no subservice user is configured. Currently, this is not the case. See 
> also SLING-6939.
> cc [~teofili]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6939) sling distribution leaks jcr sessions

[Timothee Maret (JIRA)]

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

Timothee Maret commented on SLING-6939:
---

Thanks [~wmcgaule] for your patch. It does indeed fix the leaking user session 
obtained via {{#impersonateFromService}}. 

However, it seems there is another issue in [0]. Indeed, the resource resolver 
returned is attached to a session belonging to either {{defaultAgentService}} 
sub service user or the {{subServiceName}} sub service user, but never to the 
user session.

According to SLING-5281, the user session should be used when no 
{{subServiceName}} is not configured.
I have opened SLING-6942 to track that issue.

[0] 
https://github.com/apache/sling/blob/trunk/contrib/extensions/distribution/core/src/main/java/org/apache/sling/distribution/util/impl/DistributionUtils.java#L79

> sling distribution leaks jcr sessions
> -
>
> Key: SLING-6939
> URL: https://issues.apache.org/jira/browse/SLING-6939
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.6
>Reporter: Will McGauley
>Assignee: Timothee Maret
>Priority: Blocker
> Fix For: Content Distribution Core 0.2.10
>
> Attachments: SLING_6939.patch
>
>
> The code for acquiring a ResourceResolver in sling distribution core leaks a 
> JCR Session.  In tests I was running 50,000 sessions were leaked.
> The code in DistributionUtils.getResourceResolver() creates a Session, then 
> passes it to the ResourceResolver.getServiceResolver in the map with the key 
> "user.jcr.credentials".  This means the Session passed in is ignored (the 
> correct key would have been "user.jcr.session"), and a new session is created 
> for the service user configured - resulting in a new session.  When the 
> Resource Resolver is cleaned up the associated session is not the same as the 
> abandoned session, meaning the original session (created on line number 89 of 
> DistributionUtils) is never closed.
> Please see attached patch for a possible solution which specifies the session 
> in the ResourceResolverFactory correctly.  I have tested this locally and it 
> appears to work correctly, however it does change the behaviour because a 
> different user is not used (the caller).  I did not run any automated tests.
> Also please be aware that it appears that the method "process" of the class 
> ImportingDistributionPackageProcessor appears to never close the 
> ResourceResolver acquired from the DistributionUtils.getResourceResolver() 
> utility, please have a look.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (SLING-6942) DistributionUtils#getResourceResolver should use the user session

[Timothee Maret (JIRA)]

Timothee Maret created SLING-6942:
-

 Summary: DistributionUtils#getResourceResolver should use the user 
session
 Key: SLING-6942
 URL: https://issues.apache.org/jira/browse/SLING-6942
 Project: Sling
  Issue Type: Bug
  Components: Content Distribution
Affects Versions: Content Distribution Core 0.1.12
Reporter: Timothee Maret


According to SLING-5281, the resource resolver should use the user session when 
no subservice user is configured. Currently, this is not the case. See also 
SLING-6939.

cc [~teofili]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [VOTE] Release Apache Sling Launchpad Application Builder 9, Apache Sling Launchpad Testing 9, Apache Sling Launchpad Testing WAR version 9, Apache Sling Launchpad Testing Fragment Bundle 2.0.12,

[Daniel Klco]

+1

On Wed, Jun 7, 2017 at 8:51 AM, Karl Pauls  wrote:

> +1
>
> regards,
>
> Karl
>
> On Wed, Jun 7, 2017 at 11:14 AM, Carsten Ziegeler 
> wrote:
> > +1
> >
> >
> >
> > --
> > Carsten Ziegeler
> > Adobe Research Switzerland
> > cziege...@apache.org
>
>
>
> --
> Karl Pauls
> karlpa...@gmail.com
>

[jira] [Assigned] (SLING-6855) Create ResultRegistry to provide health check behavior for executing code that does not want a HealthCheck

[Georg Henzler (JIRA)]

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

Georg Henzler reassigned SLING-6855:


Assignee: Georg Henzler

> Create ResultRegistry to provide health check behavior for executing code 
> that does not want a HealthCheck
> --
>
> Key: SLING-6855
> URL: https://issues.apache.org/jira/browse/SLING-6855
> Project: Sling
>  Issue Type: New Feature
>  Components: Health Check
>Reporter: Clinton H Goudie-Nice
>Assignee: Georg Henzler
>
> I want to provide a Registry service that can be leveraged to provide health 
> check results.
> These results can be for a period of time through an expiration, until the 
> JVM is restarted, or added and later removed.
> This can be useful when code observes a specific (possibly bad) state, and 
> wants to alert through the health check API that this state has taken place.
>  Some examples: 
>  An event pool has filled, and some events will be thrown away.
>   This is a failure case that requires a restart of the instance.
>   It would be appropriate to trigger a permanent failure.
>
>  A quota has been tripped. This quota may immediately recover, but it is 
> sensible to alert for 30 minutes that the quota has been tripped.
>  If you expect the failure will clear itself within a certain window, setting 
> the expiration to that window can be ideal.
> GHPR to follow



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: ResultRegistry for Health Checks -> StickyResults instead?

[Bertrand Delacretaz]

On Wed, Jun 7, 2017 at 2:55 PM, Georg Henzler  wrote:
> ...I'm happy to implement this later this evening if you have not started
> yet...

I haven't started so feel free to go for it!

I think that should cover Clint's SLING-6855 use case as well.

-Bertrand

Re: ResultRegistry for Health Checks -> StickyResults instead?

[Georg Henzler]

Hi Bertrand,

sounds great, I like your suggestions.


Do we need logic to make sure only the worst sticky result is kept? It
might not be convenient to keep all sticky results, that would make
the above log very long.


I would keep one last result for WARN/CRITICAL/HEALTH_CHECK_ERROR per HC 
instance and log them if they are within hc.warningsStickForMinutes...


I'm happy to implement this later this evening if you have not started 
yet...


Regards
Georg

On 2017-06-07 11:26, Bertrand Delacretaz wrote:

Hi Georg,

On Wed, Jun 7, 2017 at 1:01 AM, Georg Henzler  
wrote:

...We could introduce a HC property "hc.keepWarnStickyForMin" (and
"hc.keepCriticalStickyForMin") - this can be entirely implemented in 
the

impl package and would not require a new API


Ok, so you'd have to implement an HC (or configure one) for each
sticky alarm that you want to declare. If Clint still needs a generic
HC as in his current patch, that can also be implemented without API
changes.

That sounds ok to me, and with the out-of-the-box HCs that we have
(including taking JMX data as input) that should cover all cases.

I'd use a single property however, hc.warningsStickForMinutes maybe,
and define that it applies to warn and higher levels - I don't think
we need to be more granular than that.

...

INFO Checking Event Queue...
INFO Event Queue is currently fine.
WARN --- Sticky result from 2017-06-07 11:49 ---
INFO Checking Event Queue...
WARN Event Queue overloaded!...


So the lines following WARN are historic sticky results? That would
work for me, I 'd just say "stick result...follows" to make that
clearer.

Do we need logic to make sure only the worst sticky result is kept? It
might not be convenient to keep all sticky results, that would make
the above log very long.

-Bertrand

Re: [VOTE] Release Apache Sling Launchpad Application Builder 9, Apache Sling Launchpad Testing 9, Apache Sling Launchpad Testing WAR version 9, Apache Sling Launchpad Testing Fragment Bundle 2.0.12,

[Karl Pauls]

+1

regards,

Karl

On Wed, Jun 7, 2017 at 11:14 AM, Carsten Ziegeler  wrote:
> +1
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org



-- 
Karl Pauls
karlpa...@gmail.com

[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters

[Roy T. Fielding (JIRA)]

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

Roy T. Fielding commented on SLING-848:
---

To hopefully clarify, a path segment is each part between slash characters. I 
don't know if Sling has any use for parameters on hierarchical segments (e.g., 
versioned folders), but it would be odd for Sling to disallow them on parts of 
the URI it might not control.

IOW, rule 1 might be OK but is overly restrictive for segments we don't own; 2 
is just plain weird (if that is desired, use selectors instead of parameters); 
and both 3 and 4 are horribly ugly and unlikely to interop because many 
reference parsers will stop on single-quotes.

Instead of single-quotes, it is better to append parameters and encode specific 
characters that we think might confuse data with delimiters. In general, URIs 
are meant to be LR parsed without any look-ahead for matching 
brackets/parens/quotes.

> Support getting versioned resources by using uri path parameters
> 
>
> Key: SLING-848
> URL: https://issues.apache.org/jira/browse/SLING-848
> Project: Sling
>  Issue Type: New Feature
>  Components: API, JCR, ResourceResolver
>Affects Versions: JCR Resource 2.0.2
>Reporter: Carsten Ziegeler
>Assignee: Tomek Rękawek
> Fix For: JCR Resource 2.5.0, API 2.9.0, Resource Resolver 1.2.0
>
> Attachments: SLING-848-metadata.patch
>
>
> Getting versioned content should be support thorough uri path parameters, 
> like /something/hello;v=1.1
> For jcr based resources the value of the version should either point to a 
> version name or label.
> In order to not change our existing apis, we introduce a new utility method 
> which removes all uri path parameters
> and returns a map of these. Every resource provider could use this utility 
> method and then decide to act on these
> parameters.
> If a requested version does not exists, a 404 is returned.
> If the requested node does not directly point to a versionable node, the 
> algorithm checks the parent hierarchy until a versionable node is found, and 
> tries to get the version of this node and then goes down the path again. If 
> the versionable node does not have the requested version or the child, a 404 
> is returned.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters

[JIRA]

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

Tomek Rękawek commented on SLING-848:
-

The current state is as follows:

*1. Parameters has to be put at the end of the path*

Valid:
{noformat}
/content/mysite/page;foo=bar
{noformat}

Invalid:
{noformat}
/content/mysite;foo=bar/page
{noformat}

*2. Parameters can be put before or after extension*
{noformat}
/content/mysite/page;foo=bar.html
/content/mysite/page.html;foo=bar
{noformat}

*3. Single-quotes can be used to escape values*
{noformat}
/content/mysite/page;foo='bar'
/content/mysite/page;foo=bar
{noformat}

*4. Single-quotes has to be used to escape values containing dots, if the 
parameters are specified before extension*
Valid:
{noformat}
/content/mysite/page.html;v=1.0
/content/mysite/page;v='1.0'.html
{noformat}

Invalid:
{noformat}
/content/mysite/page.html;v=1.0.html
{noformat}

If I understand correctly, the rule 1 is OK, but 2, 3 and 4 controversial and 
[~fielding] suggestion is to get rid of them. In other words:

* parameters can only be put after extension,
* single-quotes can't be used to escape the parameter value,
* the path should be resolved in a "smart" way, so if there's a node matching 
the path (even containing parameters), it should be used directly.

Is this right?

> Support getting versioned resources by using uri path parameters
> 
>
> Key: SLING-848
> URL: https://issues.apache.org/jira/browse/SLING-848
> Project: Sling
>  Issue Type: New Feature
>  Components: API, JCR, ResourceResolver
>Affects Versions: JCR Resource 2.0.2
>Reporter: Carsten Ziegeler
>Assignee: Tomek Rękawek
> Fix For: JCR Resource 2.5.0, API 2.9.0, Resource Resolver 1.2.0
>
> Attachments: SLING-848-metadata.patch
>
>
> Getting versioned content should be support thorough uri path parameters, 
> like /something/hello;v=1.1
> For jcr based resources the value of the version should either point to a 
> version name or label.
> In order to not change our existing apis, we introduce a new utility method 
> which removes all uri path parameters
> and returns a map of these. Every resource provider could use this utility 
> method and then decide to act on these
> parameters.
> If a requested version does not exists, a 404 is returned.
> If the requested node does not directly point to a versionable node, the 
> algorithm checks the parent hierarchy until a versionable node is found, and 
> tries to get the version of this node and then goes down the path again. If 
> the versionable node does not have the requested version or the child, a 404 
> is returned.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6939) sling distribution leaks jcr sessions

[Timothee Maret (JIRA)]

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

Timothee Maret updated SLING-6939:
--
Fix Version/s: Content Distribution Core 0.2.10

> sling distribution leaks jcr sessions
> -
>
> Key: SLING-6939
> URL: https://issues.apache.org/jira/browse/SLING-6939
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.6
>Reporter: Will McGauley
>Assignee: Timothee Maret
>Priority: Blocker
> Fix For: Content Distribution Core 0.2.10
>
> Attachments: SLING_6939.patch
>
>
> The code for acquiring a ResourceResolver in sling distribution core leaks a 
> JCR Session.  In tests I was running 50,000 sessions were leaked.
> The code in DistributionUtils.getResourceResolver() creates a Session, then 
> passes it to the ResourceResolver.getServiceResolver in the map with the key 
> "user.jcr.credentials".  This means the Session passed in is ignored (the 
> correct key would have been "user.jcr.session"), and a new session is created 
> for the service user configured - resulting in a new session.  When the 
> Resource Resolver is cleaned up the associated session is not the same as the 
> abandoned session, meaning the original session (created on line number 89 of 
> DistributionUtils) is never closed.
> Please see attached patch for a possible solution which specifies the session 
> in the ResourceResolverFactory correctly.  I have tested this locally and it 
> appears to work correctly, however it does change the behaviour because a 
> different user is not used (the caller).  I did not run any automated tests.
> Also please be aware that it appears that the method "process" of the class 
> ImportingDistributionPackageProcessor appears to never close the 
> ResourceResolver acquired from the DistributionUtils.getResourceResolver() 
> utility, please have a look.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Wiki access

[Bertrand Delacretaz]

On Tue, Jun 6, 2017 at 7:31 PM, Suren Konathala
 wrote:
> ...My confluence username is "suren" ...

You should now be able to create content at
https://cwiki.apache.org/confluence/display/SLING/Index

Feel free to discuss changes here.

-Bertrand

Re: ResultRegistry for Health Checks -> StickyResults instead?

[Bertrand Delacretaz]

Hi Georg,

On Wed, Jun 7, 2017 at 1:01 AM, Georg Henzler  wrote:
> ...We could introduce a HC property "hc.keepWarnStickyForMin" (and
> "hc.keepCriticalStickyForMin") - this can be entirely implemented in the
> impl package and would not require a new API

Ok, so you'd have to implement an HC (or configure one) for each
sticky alarm that you want to declare. If Clint still needs a generic
HC as in his current patch, that can also be implemented without API
changes.

That sounds ok to me, and with the out-of-the-box HCs that we have
(including taking JMX data as input) that should cover all cases.

I'd use a single property however, hc.warningsStickForMinutes maybe,
and define that it applies to warn and higher levels - I don't think
we need to be more granular than that.

...
> INFO Checking Event Queue...
> INFO Event Queue is currently fine.
> WARN --- Sticky result from 2017-06-07 11:49 ---
> INFO Checking Event Queue...
> WARN Event Queue overloaded!...

So the lines following WARN are historic sticky results? That would
work for me, I 'd just say "stick result...follows" to make that
clearer.

Do we need logic to make sure only the worst sticky result is kept? It
might not be convenient to keep all sticky results, that would make
the above log very long.

-Bertrand

[jira] [Assigned] (SLING-6939) sling distribution leaks jcr sessions

[Timothee Maret (JIRA)]

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

Timothee Maret reassigned SLING-6939:
-

Assignee: Timothee Maret

> sling distribution leaks jcr sessions
> -
>
> Key: SLING-6939
> URL: https://issues.apache.org/jira/browse/SLING-6939
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.6
>Reporter: Will McGauley
>Assignee: Timothee Maret
>Priority: Blocker
> Attachments: SLING_6939.patch
>
>
> The code for acquiring a ResourceResolver in sling distribution core leaks a 
> JCR Session.  In tests I was running 50,000 sessions were leaked.
> The code in DistributionUtils.getResourceResolver() creates a Session, then 
> passes it to the ResourceResolver.getServiceResolver in the map with the key 
> "user.jcr.credentials".  This means the Session passed in is ignored (the 
> correct key would have been "user.jcr.session"), and a new session is created 
> for the service user configured - resulting in a new session.  When the 
> Resource Resolver is cleaned up the associated session is not the same as the 
> abandoned session, meaning the original session (created on line number 89 of 
> DistributionUtils) is never closed.
> Please see attached patch for a possible solution which specifies the session 
> in the ResourceResolverFactory correctly.  I have tested this locally and it 
> appears to work correctly, however it does change the behaviour because a 
> different user is not used (the caller).  I did not run any automated tests.
> Also please be aware that it appears that the method "process" of the class 
> ImportingDistributionPackageProcessor appears to never close the 
> ResourceResolver acquired from the DistributionUtils.getResourceResolver() 
> utility, please have a look.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [VOTE] Release Apache Sling Launchpad Application Builder 9, Apache Sling Launchpad Testing 9, Apache Sling Launchpad Testing WAR version 9, Apache Sling Launchpad Testing Fragment Bundle 2.0.12,

[Carsten Ziegeler]

+1

 

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

Re: [VOTE] Release Apache Sling Launchpad Application Builder 9, Apache Sling Launchpad Testing 9, Apache Sling Launchpad Testing WAR version 9, Apache Sling Launchpad Testing Fragment Bundle 2.0.12,

[Robert Munteanu]

On Wed, 2017-06-07 at 11:40 +0300, Robert Munteanu wrote:
> Please vote to approve this release:

+1

Robert

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

[jira] [Resolved] (SLING-5763) ClassFormatException when using java 8 lambda expressions

[Andrey Bardashevsky (JIRA)]

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

Andrey Bardashevsky resolved SLING-5763.

Resolution: Fixed

> ClassFormatException when using java 8 lambda expressions
> -
>
> Key: SLING-5763
> URL: https://issues.apache.org/jira/browse/SLING-5763
> Project: Sling
>  Issue Type: Bug
>  Components: Maven Plugins and Archetypes
>Affects Versions: Maven JSPC Plugin 2.0.8
>Reporter: Andrey Bardashevsky
>
> When i try to jsp:useBean with Java 8 lambda expression jspc plugin throws 
> following exception:
> {code}
> org.eclipse.jdt.internal.compiler.classfmt.ClassFormatException
>   at 
> org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader.(ClassFileReader.java:329)
>   at 
> org.apache.sling.scripting.jsp.jasper.compiler.JDTCompiler$1.findType(JDTCompiler.java:204)
>   at 
> org.apache.sling.scripting.jsp.jasper.compiler.JDTCompiler$1.findType(JDTCompiler.java:176)
>   at 
> org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:123)
>   at 
> org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:178)
>   at 
> org.eclipse.jdt.internal.compiler.lookup.Scope.getPackage(Scope.java:2046)
>   at 
> org.eclipse.jdt.internal.compiler.ast.QualifiedTypeReference.getTypeBinding(QualifiedTypeReference.java:69)
>   at 
> org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveType(TypeReference.java:130)
>   at 
> org.eclipse.jdt.internal.compiler.ast.LocalDeclaration.resolve(LocalDeclaration.java:138)
>   at 
> org.eclipse.jdt.internal.compiler.ast.Block.resolveUsing(Block.java:115)
>   at 
> org.eclipse.jdt.internal.compiler.ast.TryStatement.resolve(TryStatement.java:751)
>   at 
> org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolveStatements(AbstractMethodDeclaration.java:432)
>   at 
> org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.resolveStatements(MethodDeclaration.java:190)
>   at 
> org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve(AbstractMethodDeclaration.java:403)
>   at 
> org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1047)
>   at 
> org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1094)
>   at 
> org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:353)
>   at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:596)
>   at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:411)
>   at 
> org.apache.sling.scripting.jsp.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:410)
>   at 
> org.apache.sling.scripting.jsp.jasper.compiler.Compiler.compile(Compiler.java:313)
>   at org.apache.sling.maven.jspc.JspcMojo.processFile(JspcMojo.java:367)
>   at 
> org.apache.sling.maven.jspc.JspcMojo.executeInternal(JspcMojo.java:321)
>   at org.apache.sling.maven.jspc.JspcMojo.execute(JspcMojo.java:240)
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
>   at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
>   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
>   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
>   at 

[jira] [Commented] (SLING-5763) ClassFormatException when using java 8 lambda expressions

[Andrey Bardashevsky (JIRA)]

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

Andrey Bardashevsky commented on SLING-5763:


[~tripod] thank you, issue resolved inlatest SNAPSHOT 
(maven-jspc-plugin-2.0.9-20170602.130204-1726)

> ClassFormatException when using java 8 lambda expressions
> -
>
> Key: SLING-5763
> URL: https://issues.apache.org/jira/browse/SLING-5763
> Project: Sling
>  Issue Type: Bug
>  Components: Maven Plugins and Archetypes
>Affects Versions: Maven JSPC Plugin 2.0.8
>Reporter: Andrey Bardashevsky
>
> When i try to jsp:useBean with Java 8 lambda expression jspc plugin throws 
> following exception:
> {code}
> org.eclipse.jdt.internal.compiler.classfmt.ClassFormatException
>   at 
> org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader.(ClassFileReader.java:329)
>   at 
> org.apache.sling.scripting.jsp.jasper.compiler.JDTCompiler$1.findType(JDTCompiler.java:204)
>   at 
> org.apache.sling.scripting.jsp.jasper.compiler.JDTCompiler$1.findType(JDTCompiler.java:176)
>   at 
> org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:123)
>   at 
> org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:178)
>   at 
> org.eclipse.jdt.internal.compiler.lookup.Scope.getPackage(Scope.java:2046)
>   at 
> org.eclipse.jdt.internal.compiler.ast.QualifiedTypeReference.getTypeBinding(QualifiedTypeReference.java:69)
>   at 
> org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveType(TypeReference.java:130)
>   at 
> org.eclipse.jdt.internal.compiler.ast.LocalDeclaration.resolve(LocalDeclaration.java:138)
>   at 
> org.eclipse.jdt.internal.compiler.ast.Block.resolveUsing(Block.java:115)
>   at 
> org.eclipse.jdt.internal.compiler.ast.TryStatement.resolve(TryStatement.java:751)
>   at 
> org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolveStatements(AbstractMethodDeclaration.java:432)
>   at 
> org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.resolveStatements(MethodDeclaration.java:190)
>   at 
> org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve(AbstractMethodDeclaration.java:403)
>   at 
> org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1047)
>   at 
> org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1094)
>   at 
> org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:353)
>   at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:596)
>   at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:411)
>   at 
> org.apache.sling.scripting.jsp.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:410)
>   at 
> org.apache.sling.scripting.jsp.jasper.compiler.Compiler.compile(Compiler.java:313)
>   at org.apache.sling.maven.jspc.JspcMojo.processFile(JspcMojo.java:367)
>   at 
> org.apache.sling.maven.jspc.JspcMojo.executeInternal(JspcMojo.java:321)
>   at org.apache.sling.maven.jspc.JspcMojo.execute(JspcMojo.java:240)
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
>   at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
>   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
>   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at 

[VOTE] Release Apache Sling Launchpad Application Builder 9, Apache Sling Launchpad Testing 9, Apache Sling Launchpad Testing WAR version 9, Apache Sling Launchpad Testing Fragment Bundle 2.0.12, Apac

[Robert Munteanu]

Hi,

Time to push Sling 9 out the door :-)

We solved 96 issues in these release:
https://issues.apache.org/jira/browse/SLING/fixforversion/12317575
https://issues.apache.org/jira/browse/SLING/fixforversion/12332461
https://issues.apache.org/jira/browse/SLING/fixforversion/12333868

Note that not all modules are tracked in Jira, so only 3 fix versions.

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

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 1739 /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-848) Support getting versioned resources by using uri path parameters

[Roy T. Fielding (JIRA)]

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

Roy T. Fielding commented on SLING-848:
---

Note that the semicolon-delimited syntax for path segment parameters was 
defined in RFC1808 because I wanted a reserved syntax to support versions.  
These parameters are supposed to be supplied at the end of a path segment, not 
arbitrarily in the middle. They are not specifically defined in RFC3986 because 
they are not needed for the generic syntax (scheme-independent parsing), but 
semicolons are reserved for this purpose. In other words, a path that contains 
a semicolon is supposed to be percent-encoded if it is not being used as a 
parameter delimiter. An "=" is not necessary (e.g., VMS files used a name;NN 
syntax).

Of course, that is not going to help us for existing deployments if we are not 
automatically percent-encoding pathnames containing ";". We should have been 
doing that all along.

I think the problem here is that the resolver is assuming that ";" indicates 
path parameters and then removes them from the path resolution. What it should 
be doing is either manage the segment names properly (meaning that a 
non-encoded ";" is impossible) or be smarter about matching the resource 
resolution so that ";" is allowable in unencoded form. IOW, what Alex said 
above.

Also, filename extensions do not need to be at the end of path segments, and I 
certainly hope we aren't using single-quotes around parameter values because 
that isn't supported by any syntax.

> Support getting versioned resources by using uri path parameters
> 
>
> Key: SLING-848
> URL: https://issues.apache.org/jira/browse/SLING-848
> Project: Sling
>  Issue Type: New Feature
>  Components: API, JCR, ResourceResolver
>Affects Versions: JCR Resource 2.0.2
>Reporter: Carsten Ziegeler
>Assignee: Tomek Rękawek
> Fix For: JCR Resource 2.5.0, API 2.9.0, Resource Resolver 1.2.0
>
> Attachments: SLING-848-metadata.patch
>
>
> Getting versioned content should be support thorough uri path parameters, 
> like /something/hello;v=1.1
> For jcr based resources the value of the version should either point to a 
> version name or label.
> In order to not change our existing apis, we introduce a new utility method 
> which removes all uri path parameters
> and returns a map of these. Every resource provider could use this utility 
> method and then decide to act on these
> parameters.
> If a requested version does not exists, a 404 is returned.
> If the requested node does not directly point to a versionable node, the 
> algorithm checks the parent hierarchy until a versionable node is found, and 
> tries to get the version of this node and then goes down the path again. If 
> the versionable node does not have the requested version or the child, a 404 
> is returned.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (SLING-3240) Unable to run tests from launchpad/testing-war: launchpad/testing-war/src/main/config does not exist

[Robert Munteanu (JIRA)]

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

Robert Munteanu resolved SLING-3240.

Resolution: Fixed

This was fixed at some point

> Unable to run tests from launchpad/testing-war: 
> launchpad/testing-war/src/main/config does not exist
> 
>
> Key: SLING-3240
> URL: https://issues.apache.org/jira/browse/SLING-3240
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Reporter: Robert Munteanu
> Fix For: Launchpad Testing 7
>
> Attachments: build-failure-class-not-found.log, 
> build-failure-config-dir-not-found.log
>
>
> The launchpad/test-war project fails, apparently due to a missing 
> configuration directory ( src/main/config ). However, once that directory is 
> created the build still fails, since it fails to find the 
> org.apache.sling.commons.testing.integration.HttpTest class.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (SLING-2903) launchpad/testing TestSuite fails with JUnit 4 tests

[Robert Munteanu (JIRA)]

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

Robert Munteanu resolved SLING-2903.

Resolution: Fixed
  Assignee: Bertrand Delacretaz

This is no longer an issue

> launchpad/testing TestSuite fails with JUnit 4 tests
> 
>
> Key: SLING-2903
> URL: https://issues.apache.org/jira/browse/SLING-2903
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
> Fix For: Launchpad Testing 7
>
>
> I changed the ServerSideScriptsTest to JUnit 4 style yesterday and failed to 
> notice that this breaks the launchpad/testing test suite:
> junit.framework.AssertionFailedError: 
> org.apache.sling.launchpad.webapp.integrationtest.ServerSideScriptsTest.ScriptableTest
>  does not extend TestCase
>   at junit.framework.Assert.fail(Assert.java:50)
> ...
>   at junit.framework.TestSuite.runTest(TestSuite.java:243)
>   at 
> org.apache.sling.launchpad.testing.LoggingSuite.runTest(LoggingSuite.java:77)
>   at junit.framework.TestSuite.run(TestSuite.java:238)
>   at 
> org.apache.sling.launchpad.testing.LoggingSuite.run(LoggingSuite.java:65)
> ...



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (SLING-3426) Remove src/main/config when switching to maven-launchpad-plugin 2.2.2

[Robert Munteanu (JIRA)]

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

Robert Munteanu resolved SLING-3426.

Resolution: Fixed

This was fixed at some point

> Remove src/main/config when switching to maven-launchpad-plugin 2.2.2
> -
>
> Key: SLING-3426
> URL: https://issues.apache.org/jira/browse/SLING-3426
> Project: Sling
>  Issue Type: Sub-task
>  Components: Launchpad, Testing
>Reporter: Stefan Egli
>Priority: Trivial
> Fix For: Launchpad Testing 7
>
>
> Remove src/main/config when switching to maven-launchpad-plugin 2.2.2 (as 
> SLING-2843 tests for non-existence of that directory)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (SLING-5604) Upgrade Commons Collections to 4.1

[Robert Munteanu (JIRA)]

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

Robert Munteanu resolved SLING-5604.

Resolution: Fixed
  Assignee: Oliver Lietz

> Upgrade Commons Collections to 4.1
> --
>
> Key: SLING-5604
> URL: https://issues.apache.org/jira/browse/SLING-5604
> Project: Sling
>  Issue Type: Task
>  Components: Launchpad
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Launchpad Builder 9
>
>
> use Commons Collections {{4.1}} and phase out older versions e.g. {{3.0}}, 
> {{3.1}}, {{3.2.1}}
> see also COLLECTIONS-580



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (SLING-6941) RepositoryInitializer should be configurable through multiple configurations

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-6941.
-
Resolution: Fixed

Rev 1797888 :
Added a factory configuration for
org.apache.sling.jcr.repoinit.RepositoryInitializer
In addition, the bundle now provides a capability, other bundles can rely on to 
make sure that the above configuration is processed


> RepositoryInitializer should be configurable through multiple configurations
> 
>
> Key: SLING-6941
> URL: https://issues.apache.org/jira/browse/SLING-6941
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Repoinit JCR 1.1.6
>
>
> The RepositoryInitializer allows only one single global configuration 
> pointing to repoinit files.
> In an assembled environment where features are added from various sources, 
> each feature can have it's own repoinit. Therefore a single global 
> configuration does not work



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (SLING-6941) RepositoryInitializer should be configurable through multiple configurations

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler reassigned SLING-6941:
---

Assignee: Carsten Ziegeler

> RepositoryInitializer should be configurable through multiple configurations
> 
>
> Key: SLING-6941
> URL: https://issues.apache.org/jira/browse/SLING-6941
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Repoinit JCR 1.1.6
>
>
> The RepositoryInitializer allows only one single global configuration 
> pointing to repoinit files.
> In an assembled environment where features are added from various sources, 
> each feature can have it's own repoinit. Therefore a single global 
> configuration does not work



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (SLING-6941) RepositoryInitializer should be configurable through multiple configurations

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created SLING-6941:
---

 Summary: RepositoryInitializer should be configurable through 
multiple configurations
 Key: SLING-6941
 URL: https://issues.apache.org/jira/browse/SLING-6941
 Project: Sling
  Issue Type: Improvement
  Components: JCR
Reporter: Carsten Ziegeler
 Fix For: Repoinit JCR 1.1.6


The RepositoryInitializer allows only one single global configuration pointing 
to repoinit files.
In an assembled environment where features are added from various sources, each 
feature can have it's own repoinit. Therefore a single global configuration 
does not work



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Release: maven-jspc-plugin-2.0.9 ?

[Tobias Bocanegra]

 
> Sure, I think we should release the plugin as 2.1.0.  
ok

> I'm also fine with changing the artifact id now to fit the maven rules.  
> If people want to use the new version, they have to change their  
> dependency and instead of just bumping the version number, it needs a  
> change in the artifact id as well.  
ok

> What about SLING-6936 ? 
it could still be useful, although for my current work, it is not needed 
anymore :-)
we can defer or close it - but I could also create a patch for the sake of 
completeness.

regards, toby

[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-848:


I personally think it is very unlike that one really has a node in the 
repository which contains both a semicolon and an equals sign..this sounds like 
a really terrible name to me. Looking at the quoted example, this really looks 
like a test string. So I'm wondering how likely this is to happen in real world.

A new method just for the use case to pass in the version info has been 
discarded before and as you note, adding it now, doesn't really help as it will 
break current usage.

I was thinking about your second solution as well, not sure if it is a good 
idea.

But before we continue, can someone verify, that using a semicolon and equals 
sign in a url really works?

> Support getting versioned resources by using uri path parameters
> 
>
> Key: SLING-848
> URL: https://issues.apache.org/jira/browse/SLING-848
> Project: Sling
>  Issue Type: New Feature
>  Components: API, JCR, ResourceResolver
>Affects Versions: JCR Resource 2.0.2
>Reporter: Carsten Ziegeler
>Assignee: Tomek Rękawek
> Fix For: JCR Resource 2.5.0, API 2.9.0, Resource Resolver 1.2.0
>
> Attachments: SLING-848-metadata.patch
>
>
> Getting versioned content should be support thorough uri path parameters, 
> like /something/hello;v=1.1
> For jcr based resources the value of the version should either point to a 
> version name or label.
> In order to not change our existing apis, we introduce a new utility method 
> which removes all uri path parameters
> and returns a map of these. Every resource provider could use this utility 
> method and then decide to act on these
> parameters.
> If a requested version does not exists, a 404 is returned.
> If the requested node does not directly point to a versionable node, the 
> algorithm checks the parent hierarchy until a versionable node is found, and 
> tries to get the version of this node and then goes down the path again. If 
> the versionable node does not have the requested version or the child, a 404 
> is returned.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Release: maven-jspc-plugin-2.0.9 ?

[Carsten Ziegeler]

Sure, I think we should release the plugin as 2.1.0.

I'm also fine with changing the artifact id now to fit the maven rules.
If people want to use the new version, they have to change their
dependency and instead of just bumping the version number, it needs a
change in the artifact id as well.

What about SLING-6936 ?

Regards
Carsten

Tobias Bocanegra wrote
> Hi,
> 
> With the fix of [0] the jspc plugin uses the latest sling jsp scripting 
> backend and supports java 1.8.
> Would it be possible to release it?
> 
> thanks.
> regards, toby
> 
> ps: the plugin violates the maven plugin convention, as it starts with 
> "maven-":
> 
> ---
> [INFO] --- maven-plugin-plugin:3.4:helpmojo (help-goal) @ maven-jspc-plugin 
> ---
> [ERROR]
> 
> Artifact Ids of the format maven-___-plugin are reserved for
> plugins in the Group Id org.apache.maven.plugins
> Please change your artifactId to the format ___-maven-plugin
> In the future this error will break the build.
> ---
> 
> So it probably should be renamed some time soon
> I created an issue [1]
> 
> 
> [0] https://issues.apache.org/jira/browse/SLING-6923
> [1] https://issues.apache.org/jira/browse/SLING-6940
> 


 

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