Re: [VOTE] Release Apache Sling Repoinit JCR 1.1.48
+1 On Sat, 25 May 2024 at 11:54, Julian Sedding wrote: > Please vote to approve this release: > > [ ] +1 Approve the release > [ ]0 Don't care > [ ] -1 Don't release, because ...
[jira] [Closed] (SLING-12320) Add support for retrieving a service resource resolver with impersonation without requiring extra configuration
[ https://issues.apache.org/jira/browse/SLING-12320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu closed SLING-12320. > Add support for retrieving a service resource resolver with impersonation > without requiring extra configuration > --- > > Key: SLING-12320 > URL: https://issues.apache.org/jira/browse/SLING-12320 > Project: Sling > Issue Type: Improvement > Components: JCR >Reporter: Radu Cotescu > Assignee: Radu Cotescu >Priority: Major > Fix For: JCR Resource 3.3.2 > > > SLING-4888 simplified retrieving impersonated sessions from service users, > however the JCR Resource Provider seems to still use the approach before this > improvement. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[RESULT] [VOTE] Release Apache Sling JCR Resource 3.3.2
Hi, The vote has passed with the following result: +1 (binding): Radu Cotescu, Robert Munteanu, Stefan Seifert, Joerg Hoh +1 (non-binding): none I will copy this release to the Sling dist directory and promote the artifacts to the central Maven repository. Regards, Radu Cotescu
Re: [VOTE] Release Apache Sling JCR Resource 3.3.2
+1 On Mon, 20 May 2024 at 18:03, Radu Cotescu wrote: > > 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, > Radu Cotescu
[VOTE] Release Apache Sling JCR Resource 3.3.2
Hi, We solved 1 issue in this release: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310710=12354675=Text Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2861/ You can use this UNIX script to download the release and verify the signatures: https://raw.githubusercontent.com/apache/sling-tooling-release/master/check_staged_release.sh Usage: sh check_staged_release.sh 2861 /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, Radu Cotescu
[jira] [Resolved] (SLING-12320) Add support for retrieving a service resource resolver with impersonation without requiring extra configuration
[ https://issues.apache.org/jira/browse/SLING-12320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu resolved SLING-12320. -- Resolution: Fixed > Add support for retrieving a service resource resolver with impersonation > without requiring extra configuration > --- > > Key: SLING-12320 > URL: https://issues.apache.org/jira/browse/SLING-12320 > Project: Sling > Issue Type: Improvement > Components: JCR >Reporter: Radu Cotescu > Assignee: Radu Cotescu >Priority: Major > Fix For: JCR Resource 3.3.2 > > > SLING-4888 simplified retrieving impersonated sessions from service users, > however the JCR Resource Provider seems to still use the approach before this > improvement. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12320) Add support for retrieving a service resource resolver with impersonation without requiring extra configuration
Radu Cotescu created SLING-12320: Summary: Add support for retrieving a service resource resolver with impersonation without requiring extra configuration Key: SLING-12320 URL: https://issues.apache.org/jira/browse/SLING-12320 Project: Sling Issue Type: Improvement Components: JCR Reporter: Radu Cotescu Fix For: JCR Resource 3.3.2 SLING-4888 simplified retrieving impersonated sessions from service users, however the JCR Resource Provider seems to still use the approach before this improvement. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12094) Use GitHub for the Maven scm.url value
[ https://issues.apache.org/jira/browse/SLING-12094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-12094: - Fix Version/s: (was: JCR Resource 3.3.0) > Use GitHub for the Maven scm.url value > -- > > Key: SLING-12094 > URL: https://issues.apache.org/jira/browse/SLING-12094 > Project: Sling > Issue Type: Improvement > Components: Build and Source Control >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > > Currently, the "Browsing URL" in the POMs is pointing to GitBox. Those > URLs are used by various tooling and humans. > We should switch it directly to GitHub to easy the discovery process > The Source Code URLs used for Release Process stick with GitBox -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [VOTE] Release Apache Sling JCR Resource 3.3.0
Ah, I didn't realise. I'll remove the fix version. Thanks for that! On Tue, 14 May 2024 at 12:02, Robert Munteanu wrote: > Because it affected all Sling modules, not just this one.
[jira] [Closed] (SLING-12092) Build fails with Java 11
[
https://issues.apache.org/jira/browse/SLING-12092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu closed SLING-12092.
> Build fails with Java 11
>
>
> Key: SLING-12092
> URL: https://issues.apache.org/jira/browse/SLING-12092
> Project: Sling
> Issue Type: Improvement
> Components: JCR
>Affects Versions: JCR Resource 3.2.4
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: JCR Resource 3.3.0
>
>
> From
> [https://ci-builds.apache.org/blue/rest/organizations/jenkins/pipelines/Sling/pipelines/modules/pipelines/sling-org-apache-sling-jcr-resource/branches/master/runs/216/nodes/60/steps/105/log/?start=0:]
> {code}
> [ERROR]
> org.apache.sling.jcr.resource.internal.JcrResourceListenerTest.testSimpleOperations
> Time elapsed: 0.095 s <<< ERROR!
> java.lang.ExceptionInInitializerError
> at
> org.mockito.cglib.core.KeyFactory$Generator.generateClass(KeyFactory.java:167)
> at
> org.mockito.cglib.core.DefaultGeneratorStrategy.generate(DefaultGeneratorStrategy.java:25)
> at
> org.mockito.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:217)
> at
> org.mockito.cglib.core.KeyFactory$Generator.create(KeyFactory.java:145)
> at org.mockito.cglib.core.KeyFactory.create(KeyFactory.java:117)
> at org.mockito.cglib.core.KeyFactory.create(KeyFactory.java:109)
> at org.mockito.cglib.core.KeyFactory.create(KeyFactory.java:105)
> at org.mockito.cglib.proxy.Enhancer.(Enhancer.java:70)
> at
> org.mockito.internal.creation.jmock.ClassImposterizer.createProxyClass(ClassImposterizer.java:85)
> at
> org.mockito.internal.creation.jmock.ClassImposterizer.imposterise(ClassImposterizer.java:62)
> at
> org.mockito.internal.creation.jmock.ClassImposterizer.imposterise(ClassImposterizer.java:56)
> at
> org.mockito.internal.creation.CglibMockMaker.createMock(CglibMockMaker.java:23)
> at org.mockito.internal.util.MockUtil.createMock(MockUtil.java:26)
> at org.mockito.internal.MockitoCore.mock(MockitoCore.java:51)
> at org.mockito.Mockito.mock(Mockito.java:1243)
> at org.mockito.Mockito.mock(Mockito.java:1120)
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.SlingRepositoryProvider.getFakeContext(SlingRepositoryProvider.java:56)
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.SlingRepositoryProvider.getRepository(SlingRepositoryProvider.java:41)
> at
> org.apache.sling.jcr.resource.internal.JcrResourceListenerTest.setUp(JcrResourceListenerTest.java:74)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.RunBefores.invokeMethod(RunBefores.java:33)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at
> org.apache.m
[jira] [Closed] (SLING-12076) ResourceListener should expose the JCR observation's user data
[ https://issues.apache.org/jira/browse/SLING-12076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu closed SLING-12076. > ResourceListener should expose the JCR observation's user data > -- > > Key: SLING-12076 > URL: https://issues.apache.org/jira/browse/SLING-12076 > Project: Sling > Issue Type: Improvement > Components: JCR >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: JCR Resource 3.3.0 > > > The ResourceChange > (https://github.com/apache/sling-org-apache-sling-api/blob/f58111baf07b6ae525aec2c6792e949786df7beb/src/main/java/org/apache/sling/api/resource/observation/ResourceChange.java#L50) > should optionally expose a context (arbitrary String). In the case of the > JCR Resource Provider this should be populated by the JCR Event's User Data > (https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/12_Observation.html#12.3.5%20User%20Data). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[
https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu closed SLING-12300.
> Provide a way to retrieve a JCR backed resource by its node identifier
> --
>
> Key: SLING-12300
> URL: https://issues.apache.org/jira/browse/SLING-12300
> Project: Sling
> Issue Type: New Feature
> Components: JCR
> Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: JCR Resource 3.3.0
>
>
> Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would
> be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}}
> property for referenceable nodes or the path. In systems that would like to
> use UUID addressing, this would reduce the need for executing JCR queries for
> resource retrieval and would avoid double-reads via the JCR and then Sling
> API to obtain the resource.
> In order to provide a unified behaviour, paths starting with the {{/jcr:id/}}
> prefix should use the resource retrieval by node identifier.
> [0] -
> https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier()
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[RESULT] [VOTE] Release Apache Sling JCR Resource 3.3.0
Hi, The vote has passed with the following result: +1 (binding): Radu Cotescu, Joerg Hoh, Robert Munteanu +1 (non-binding): none I will copy this release to the Sling dist directory and promote the artifacts to the central Maven repository. Regards, Radu Cotescu
Re: [VOTE] Release Apache Sling JCR Resource 3.3.0
Hi Robert, On Tue, 7 May 2024 at 10:57, Robert Munteanu wrote: > > FWIW, you probably did not want to tag > https://issues.apache.org/jira/browse/SLING-12094 as being fixed for > this release. > Why not? It was committed in https://github.com/apache/sling-org-apache-sling-jcr-resource/commit/1849e113a0ae94ca4484b1a766b97149959a06cc. Thanks, Radu
Re: [VOTE] Release Apache Sling JCR Resource 3.3.0
+1 On Mon, 6 May 2024 at 18:20, Radu Cotescu wrote: > > 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, > Radu Cotescu
[VOTE] Release Apache Sling JCR Resource 3.3.0
Hi, We solved 4 issues in this release: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310710=12354599=Text Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2860/ You can use this UNIX script to download the release and verify the signatures: https://raw.githubusercontent.com/apache/sling-tooling-release/master/check_staged_release.sh Usage: sh check_staged_release.sh 2860 /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, Radu Cotescu
[jira] [Updated] (SLING-12076) ResourceListener should expose the JCR observation's user data
[ https://issues.apache.org/jira/browse/SLING-12076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-12076: - Fix Version/s: JCR Resource 3.3.0 (was: JCR Resource 3.2.6) > ResourceListener should expose the JCR observation's user data > -- > > Key: SLING-12076 > URL: https://issues.apache.org/jira/browse/SLING-12076 > Project: Sling > Issue Type: Improvement > Components: JCR >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: JCR Resource 3.3.0 > > > The ResourceChange > (https://github.com/apache/sling-org-apache-sling-api/blob/f58111baf07b6ae525aec2c6792e949786df7beb/src/main/java/org/apache/sling/api/resource/observation/ResourceChange.java#L50) > should optionally expose a context (arbitrary String). In the case of the > JCR Resource Provider this should be populated by the JCR Event's User Data > (https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/12_Observation.html#12.3.5%20User%20Data). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12094) Use GitHub for the Maven scm.url value
[ https://issues.apache.org/jira/browse/SLING-12094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-12094: - Fix Version/s: JCR Resource 3.3.0 > Use GitHub for the Maven scm.url value > -- > > Key: SLING-12094 > URL: https://issues.apache.org/jira/browse/SLING-12094 > Project: Sling > Issue Type: Improvement > Components: Build and Source Control >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > Fix For: JCR Resource 3.3.0 > > > Currently, the "Browsing URL" in the POMs is pointing to GitBox. Those > URLs are used by various tooling and humans. > We should switch it directly to GitHub to easy the discovery process > The Source Code URLs used for Release Process stick with GitBox -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12092) Build fails with Java 11
[
https://issues.apache.org/jira/browse/SLING-12092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-12092:
-
Fix Version/s: JCR Resource 3.3.0
(was: JCR Resource 3.2.6)
> Build fails with Java 11
>
>
> Key: SLING-12092
> URL: https://issues.apache.org/jira/browse/SLING-12092
> Project: Sling
> Issue Type: Improvement
> Components: JCR
>Affects Versions: JCR Resource 3.2.4
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: JCR Resource 3.3.0
>
>
> From
> [https://ci-builds.apache.org/blue/rest/organizations/jenkins/pipelines/Sling/pipelines/modules/pipelines/sling-org-apache-sling-jcr-resource/branches/master/runs/216/nodes/60/steps/105/log/?start=0:]
> {code}
> [ERROR]
> org.apache.sling.jcr.resource.internal.JcrResourceListenerTest.testSimpleOperations
> Time elapsed: 0.095 s <<< ERROR!
> java.lang.ExceptionInInitializerError
> at
> org.mockito.cglib.core.KeyFactory$Generator.generateClass(KeyFactory.java:167)
> at
> org.mockito.cglib.core.DefaultGeneratorStrategy.generate(DefaultGeneratorStrategy.java:25)
> at
> org.mockito.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:217)
> at
> org.mockito.cglib.core.KeyFactory$Generator.create(KeyFactory.java:145)
> at org.mockito.cglib.core.KeyFactory.create(KeyFactory.java:117)
> at org.mockito.cglib.core.KeyFactory.create(KeyFactory.java:109)
> at org.mockito.cglib.core.KeyFactory.create(KeyFactory.java:105)
> at org.mockito.cglib.proxy.Enhancer.(Enhancer.java:70)
> at
> org.mockito.internal.creation.jmock.ClassImposterizer.createProxyClass(ClassImposterizer.java:85)
> at
> org.mockito.internal.creation.jmock.ClassImposterizer.imposterise(ClassImposterizer.java:62)
> at
> org.mockito.internal.creation.jmock.ClassImposterizer.imposterise(ClassImposterizer.java:56)
> at
> org.mockito.internal.creation.CglibMockMaker.createMock(CglibMockMaker.java:23)
> at org.mockito.internal.util.MockUtil.createMock(MockUtil.java:26)
> at org.mockito.internal.MockitoCore.mock(MockitoCore.java:51)
> at org.mockito.Mockito.mock(Mockito.java:1243)
> at org.mockito.Mockito.mock(Mockito.java:1120)
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.SlingRepositoryProvider.getFakeContext(SlingRepositoryProvider.java:56)
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.SlingRepositoryProvider.getRepository(SlingRepositoryProvider.java:41)
> at
> org.apache.sling.jcr.resource.internal.JcrResourceListenerTest.setUp(JcrResourceListenerTest.java:74)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.RunBefores.invokeMethod(RunBefores.java:33)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
&g
[jira] [Resolved] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[
https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu resolved SLING-12300.
--
Resolution: Fixed
> Provide a way to retrieve a JCR backed resource by its node identifier
> --
>
> Key: SLING-12300
> URL: https://issues.apache.org/jira/browse/SLING-12300
> Project: Sling
> Issue Type: New Feature
> Components: JCR
> Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: JCR Resource 3.3.0
>
>
> Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would
> be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}}
> property for referenceable nodes or the path. In systems that would like to
> use UUID addressing, this would reduce the need for executing JCR queries for
> resource retrieval and would avoid double-reads via the JCR and then Sling
> API to obtain the resource.
> In order to provide a unified behaviour, paths starting with the {{/jcr:id/}}
> prefix should use the resource retrieval by node identifier.
> [0] -
> https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier()
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[
https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840756#comment-17840756
]
Radu Cotescu commented on SLING-12300:
--
I've updated the PR to include a configuration flag. Let me know what you
think. I'd like to get this merged by the end of next week.
> Provide a way to retrieve a JCR backed resource by its node identifier
> --
>
> Key: SLING-12300
> URL: https://issues.apache.org/jira/browse/SLING-12300
> Project: Sling
> Issue Type: New Feature
> Components: JCR
> Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: JCR Resource 3.3.0
>
>
> Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would
> be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}}
> property for referenceable nodes or the path. In systems that would like to
> use UUID addressing, this would reduce the need for executing JCR queries for
> resource retrieval and would avoid double-reads via the JCR and then Sling
> API to obtain the resource.
> In order to provide a unified behaviour, paths starting with the {{/jcr:id/}}
> prefix should use the resource retrieval by node identifier.
> [0] -
> https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier()
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[
https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840164#comment-17840164
]
Radu Cotescu commented on SLING-12300:
--
I’m perfectly fine to have this feature disabled by default, behind a
configuration toggle. I’ll update the PR as soon as I find some time to come
back to this issue. Thanks!
> Provide a way to retrieve a JCR backed resource by its node identifier
> --
>
> Key: SLING-12300
> URL: https://issues.apache.org/jira/browse/SLING-12300
> Project: Sling
> Issue Type: New Feature
> Components: JCR
> Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: JCR Resource 3.3.0
>
>
> Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would
> be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}}
> property for referenceable nodes or the path. In systems that would like to
> use UUID addressing, this would reduce the need for executing JCR queries for
> resource retrieval and would avoid double-reads via the JCR and then Sling
> API to obtain the resource.
> In order to provide a unified behaviour, paths starting with the {{/jcr:id/}}
> prefix should use the resource retrieval by node identifier.
> [0] -
> https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier()
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[
https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840065#comment-17840065
]
Radu Cotescu commented on SLING-12300:
--
Let's compare the three options we have:
||1. Augmenting the JCR Resource Provider - {{/jcr:id/}}||2. Creating a new
Resource Provider for ID addressing||3. Extending the Resource API||
|Pros:
* simple, low effort implementation
* can be implemented behind a configuration toggle|Pros:
* isolates providers and allows for separate configurations
* since a provider has a mount path, the root for ID addressing is
configurable|Pros:
* brings the IDs as first class citizens to the Resource API
* allows resource retrieval by ID or path without providing any special
prefixes|
|Cons:
* adds a path prefix into the resource tree
* might require setting explicit authentication configurations to not allow
any HTTP browsing under {{/jcr:id}} for unauthenticated users|Cons:
* adds a path prefix into the resource tree (via its mount path)
* might require setting explicit authentication configurations to not allow
any HTTP browsing under its root
* duplicates functionality, since this would also be a JCR provider|Cons:
* must ensure ID uniqueness across Resource Providers
* difficult to implement since the Resource API has a large footprint|
This shows clearly that 2 is not really a different option compared to 1. 3 is
interesting, but I don't think we can solve the uniqueness requirement.
> Provide a way to retrieve a JCR backed resource by its node identifier
> --
>
> Key: SLING-12300
> URL: https://issues.apache.org/jira/browse/SLING-12300
> Project: Sling
> Issue Type: New Feature
> Components: JCR
> Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: JCR Resource 3.3.0
>
>
> Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would
> be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}}
> property for referenceable nodes or the path. In systems that would like to
> use UUID addressing, this would reduce the need for executing JCR queries for
> resource retrieval and would avoid double-reads via the JCR and then Sling
> API to obtain the resource.
> In order to provide a unified behaviour, paths starting with the {{/jcr:id/}}
> prefix should use the resource retrieval by node identifier.
> [0] -
> https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier()
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[
https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839511#comment-17839511
]
Radu Cotescu edited comment on SLING-12300 at 4/22/24 7:01 AM:
---
[~enorman], nobody trivialised your concerns. I’m not sure if everyone is
familiarised with the UUIDv4 standard that Oak uses for the {{jcr:uuid}}
property and I was just trying to explain the problem space. In addition, you
expressed that there would be security issues by implementing this feature, but
didn’t explain which. Predictability is not a security concern IMO if you
correctly use ACLs.
[~paul.bjorkstrand], for my use-case I only need those resources addressable by
ID at the Java API level. The application that is built on top controls the URL
space, but I wanted to use the Sling API for accessing the resource tree. You
could ask why the contradiction: update the JCR resource provider to use a
feature exposed only by JCR, but consume it via Sling?! Well, the Sling API is
just easier to use and simpler to understand for developers than the JCR one.
Adding a new Resource Provider could also be an option, but in the end it would
perform the same function in the same way: it would offer a way to retrieve
resources by ID from its mount root, whichever that will be.
I also thought about extending the Sling Resource API, but given that right now
only one commonly used provider generates IDs for the resources it creates I
thought it would be too complex and not provide so many gains.
I will obviously not push something that the Sling community doesn’t agree
with, but I would like that we discuss the alternatives and pick the solution
that makes the most sense in terms of effort/benefits.
was (Author: radu.cotescu):
[~enorman], nobody trivialised your concerns. I’m not sure if everyone is
familiarised with the UUIDv4 standard that Oak uses for the {{jcr:uuid}}
property and I was just trying to explain the problem space. In addition, you
expressed that there would be security issues by implementing this feature, but
didn’t explain which. Predictability is not a security concern IMO if you
correctly use ACLs.
[~paul.bjorkstrand], for my use-case I only need those resources addressable by
ID at the Java API level. The application that is built on top controls the URL
space, but I wanted to use the Sling API for accessing the resource tree. You
could ask why the contradiction: update the JCR resource provider to use a
feature exposed only by JCR, but consume it via Sling?! Well, the Sling API is
just easier to use and simpler to understand for developers than the JCR one.
Adding a new Resource Provider could also be an option, but in the end it would
perform the same function in the same way: it would offer a way to retrieve
resources by ID from its mount root, whichever that will be.
I also thought about extending the Sling Resource API, but given that right now
only one commonly use provider generates IDs for the resources it creates I
thought it would be too complex and not provide so many gains.
I will obviously not push something that the Sling community doesn’t agree
with, but I would like that we discuss the alternatives and pick the solution
that makes the most sense in terms of effort/benefits.
> Provide a way to retrieve a JCR backed resource by its node identifier
> --
>
> Key: SLING-12300
> URL: https://issues.apache.org/jira/browse/SLING-12300
> Project: Sling
> Issue Type: New Feature
> Components: JCR
> Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: JCR Resource 3.3.0
>
>
> Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would
> be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}}
> property for referenceable nodes or the path. In systems that would like to
> use UUID addressing, this would reduce the need for executing JCR queries for
> resource retrieval and would avoid double-reads via the JCR and then Sling
> API to obtain the resource.
> In order to provide a unified behaviour, paths starting with the {{/jcr:id/}}
> prefix should use the resource retrieval by node identifier.
> [0] -
> https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier()
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[
https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839511#comment-17839511
]
Radu Cotescu commented on SLING-12300:
--
[~enorman], nobody trivialised your concerns. I’m not sure if everyone is
familiarised with the UUIDv4 standard that Oak uses for the {{jcr:uuid}}
property and I was just trying to explain the problem space. In addition, you
expressed that there would be security issues by implementing this feature, but
didn’t explain which. Predictability is not a security concern IMO if you
correctly use ACLs.
[~paul.bjorkstrand], for my use-case I only need those resources addressable by
ID at the Java API level. The application that is built on top controls the URL
space, but I wanted to use the Sling API for accessing the resource tree. You
could ask why the contradiction: update the JCR resource provider to use a
feature exposed only by JCR, but consume it via Sling?! Well, the Sling API is
just easier to use and simpler to understand for developers than the JCR one.
Adding a new Resource Provider could also be an option, but in the end it would
perform the same function in the same way: it would offer a way to retrieve
resources by ID from its mount root, whichever that will be.
I also thought about extending the Sling Resource API, but given that right now
only one commonly use provider generates IDs for the resources it creates I
thought it would be too complex and not provide so many gains.
I will obviously not push something that the Sling community doesn’t agree
with, but I would like that we discuss the alternatives and pick the solution
that makes the most sense in terms of effort/benefits.
> Provide a way to retrieve a JCR backed resource by its node identifier
> --
>
> Key: SLING-12300
> URL: https://issues.apache.org/jira/browse/SLING-12300
> Project: Sling
> Issue Type: New Feature
> Components: JCR
> Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: JCR Resource 3.3.0
>
>
> Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would
> be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}}
> property for referenceable nodes or the path. In systems that would like to
> use UUID addressing, this would reduce the need for executing JCR queries for
> resource retrieval and would avoid double-reads via the JCR and then Sling
> API to obtain the resource.
> In order to provide a unified behaviour, paths starting with the {{/jcr:id/}}
> prefix should use the resource retrieval by node identifier.
> [0] -
> https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier()
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[
https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839166#comment-17839166
]
Radu Cotescu commented on SLING-12300:
--
In case you were to build an application that provided web resources identified
by UUIDs, this would allow for efficient resource-by-id retrieval compared to
what you'd have to do without this support at the Resource Provider level.
> Provide a way to retrieve a JCR backed resource by its node identifier
> --
>
> Key: SLING-12300
> URL: https://issues.apache.org/jira/browse/SLING-12300
> Project: Sling
> Issue Type: New Feature
> Components: JCR
> Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: JCR Resource 3.3.0
>
>
> Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would
> be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}}
> property for referenceable nodes or the path. In systems that would like to
> use UUID addressing, this would reduce the need for executing JCR queries for
> resource retrieval and would avoid double-reads via the JCR and then Sling
> API to obtain the resource.
> In order to provide a unified behaviour, paths starting with the {{/jcr:id/}}
> prefix should use the resource retrieval by node identifier.
> [0] -
> https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier()
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[
https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839151#comment-17839151
]
Radu Cotescu commented on SLING-12300:
--
{quote}
I could get a match on the first try if I get lucky. Basically, I'm not
putting a server on the public internet with predictable addresses.
{quote}
We're talking about UUIDs in this case, which are anything but predictable.
Paths are definitely more predictable if we were to compare the two. But even
so, the resources are either protected by ACLs or public, both making the
security discussion moot.
> Provide a way to retrieve a JCR backed resource by its node identifier
> --
>
> Key: SLING-12300
> URL: https://issues.apache.org/jira/browse/SLING-12300
> Project: Sling
> Issue Type: New Feature
> Components: JCR
> Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: JCR Resource 3.3.0
>
>
> Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would
> be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}}
> property for referenceable nodes or the path. In systems that would like to
> use UUID addressing, this would reduce the need for executing JCR queries for
> resource retrieval and would avoid double-reads via the JCR and then Sling
> API to obtain the resource.
> In order to provide a unified behaviour, paths starting with the {{/jcr:id/}}
> prefix should use the resource retrieval by node identifier.
> [0] -
> https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier()
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[
https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839137#comment-17839137
]
Radu Cotescu commented on SLING-12300:
--
{quote}That seems to be a security hole where someone could just do a brute
force attack to try all the possible values and find paths that exist.
{quote}
They'd only have to try 2{^}122{^} combinations. In all seriousness now, the
same ACLs apply. I don't see how the addressing mode introduces a security hole.
> Provide a way to retrieve a JCR backed resource by its node identifier
> --
>
> Key: SLING-12300
> URL: https://issues.apache.org/jira/browse/SLING-12300
> Project: Sling
> Issue Type: New Feature
> Components: JCR
> Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: JCR Resource 3.3.0
>
>
> Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would
> be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}}
> property for referenceable nodes or the path. In systems that would like to
> use UUID addressing, this would reduce the need for executing JCR queries for
> resource retrieval and would avoid double-reads via the JCR and then Sling
> API to obtain the resource.
> In order to provide a unified behaviour, paths starting with the {{/jcr:id/}}
> prefix should use the resource retrieval by node identifier.
> [0] -
> https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier()
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[
https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839133#comment-17839133
]
Radu Cotescu commented on SLING-12300:
--
{quote}
If I were to add in something that provides resources under the path
{{/jcr:id/*}}, it almost seems like it should be from a provider that services
that path.
{quote}
Don't forget that the JCR provider is mounted on {{/}}. So technically
{{/jcr:id}} in this case is a resource provided by this provider. If you were
to reconfigure the provider on let's say {{/oak}}, then the "magic" path for
identifier based retrieval would be {{/oak/jcr:id/}}.
> Provide a way to retrieve a JCR backed resource by its node identifier
> --
>
> Key: SLING-12300
> URL: https://issues.apache.org/jira/browse/SLING-12300
> Project: Sling
> Issue Type: New Feature
> Components: JCR
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: JCR Resource 3.3.0
>
>
> Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would
> be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}}
> property for referenceable nodes or the path. In systems that would like to
> use UUID addressing, this would reduce the need for executing JCR queries for
> resource retrieval and would avoid double-reads via the JCR and then Sling
> API to obtain the resource.
> In order to provide a unified behaviour, paths starting with the {{/jcr:id/}}
> prefix should use the resource retrieval by node identifier.
> [0] -
> https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier()
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[
https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839129#comment-17839129
]
Radu Cotescu commented on SLING-12300:
--
[~joerghoh], how can your two asserts be true at the same time for a
referenceable node?! A JCR node's identifier is its path or, if it has the
{{mix:referenceable}} applied, its {{jcr:uuid}} property, like mentioned in the
issue's description.
In the PR I have provided some tests that show the path behaviour, namely the
path will always be the node's path, regardless of how the resource was
retrieved.
While writing a new Resource Provider might provide better isolation, it would
duplicate everything the JCR Provider does right now and it wouldn't provide
much value compared to the current solution. Accessing a resource like
{{http://localhost:8080/jcr:id/.json}} will be identical to
{{http://localhost:8080/.json}}.
> Provide a way to retrieve a JCR backed resource by its node identifier
> --
>
> Key: SLING-12300
> URL: https://issues.apache.org/jira/browse/SLING-12300
> Project: Sling
> Issue Type: New Feature
> Components: JCR
> Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: JCR Resource 3.3.0
>
>
> Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would
> be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}}
> property for referenceable nodes or the path. In systems that would like to
> use UUID addressing, this would reduce the need for executing JCR queries for
> resource retrieval and would avoid double-reads via the JCR and then Sling
> API to obtain the resource.
> In order to provide a unified behaviour, paths starting with the {{/jcr:id/}}
> prefix should use the resource retrieval by node identifier.
> [0] -
> https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier()
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[
https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-12300:
-
Description:
Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would be
{{Resource}} retrieval by node id, which could be its {{jcr:uuid}} property for
referenceable nodes or the path. In systems that would like to use UUID
addressing, this would reduce the need for executing JCR queries for resource
retrieval and would avoid double-reads via the JCR and then Sling API to obtain
the resource.
In order to provide a unified behaviour, paths starting with the {{/jcr:id/}}
prefix should use the resource retrieval by node identifier.
[0] -
https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier()
was:
Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would be
{{Resource}} retrieval by node id, which could be its {{jcr:uuid}} property for
referenceable nodes or the path. In systems that would like to use UUID
addressing, this would reduce the need for executing JCR queries for resource
retrieval and would avoid double-reads via the JCR and then Sling API to obtain
the resource.
[0] -
https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier()
> Provide a way to retrieve a JCR backed resource by its node identifier
> --
>
> Key: SLING-12300
> URL: https://issues.apache.org/jira/browse/SLING-12300
> Project: Sling
> Issue Type: New Feature
> Components: JCR
> Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: JCR Resource 3.3.0
>
>
> Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would
> be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}}
> property for referenceable nodes or the path. In systems that would like to
> use UUID addressing, this would reduce the need for executing JCR queries for
> resource retrieval and would avoid double-reads via the JCR and then Sling
> API to obtain the resource.
> In order to provide a unified behaviour, paths starting with the {{/jcr:id/}}
> prefix should use the resource retrieval by node identifier.
> [0] -
> https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier()
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
Radu Cotescu created SLING-12300:
Summary: Provide a way to retrieve a JCR backed resource by its
node identifier
Key: SLING-12300
URL: https://issues.apache.org/jira/browse/SLING-12300
Project: Sling
Issue Type: New Feature
Components: JCR
Reporter: Radu Cotescu
Assignee: Radu Cotescu
Fix For: JCR Resource 3.3.0
Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would be
{{Resource}} retrieval by node id, which could be its {{jcr:uuid}} property for
referenceable nodes or the path. In systems that would like to use UUID
addressing, this would reduce the need for executing JCR queries for resource
retrieval and would avoid double-reads via the JCR and then Sling API to obtain
the resource.
[0] -
https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier()
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [VOTE] Release Apache Sling Rewriter 1.4.0
+1 On Thu, 18 Apr 2024 at 18:36, Carsten Ziegeler wrote: > > Please vote to approve this release: > >[ ] +1 Approve the release >[ ] 0 Don't care >[ ] -1 Don't release, because ... >
Re: [VOTE] Release Apache Sling Testing Sling Mock Oak 3.2.0-1.22.15
+1 On Wed, 17 Apr 2024 at 20:32, Stefan Seifert wrote: > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... >
Re: [VOTE] Release Apache Sling Testing Sling Mock 3.5.0, Sling Mock Oak 4.0.0-1.62.0
+1 On Wed, 17 Apr 2024 at 20:32, Stefan Seifert wrote: > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... >
Re: [VOTE] Release Apache Sling Tenant 1.1.8
+1 On Thu, 11 Apr 2024 at 15:35, Robert Munteanu wrote: > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... >
Re: [VOTE] Release Apache Sling JUnit Tests Teleporter 1.0.26
+1 On Wed, 17 Apr 2024 at 12:03, Robert Munteanu wrote: > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... >
Re: [VOTE] Release Apache Sling Resource Observation Annotations 1.0.0
+1 On Fri, 1 Mar 2024 at 13:19, Konrad Windszus wrote: > > 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.
Re: [VOTE] Release Apache Sling Content-Package to Feature Model Converter 1.3.6
+1 On Thu, 29 Feb 2024 at 15:29, Robert Munteanu wrote: > 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. >
Re: [VOTE] Release Apache Sling Servlets Resolver version 2.11.2
+1 On Wed, 21 Feb 2024 at 14:28, Jörg Hoh wrote: > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... >
[jira] [Updated] (SLING-10901) Allow terminating a GraphQL query after a configured timeout
[ https://issues.apache.org/jira/browse/SLING-10901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-10901: - Fix Version/s: GraphQL Core 0.0.32 (was: GraphQL Core 0.0.30) > Allow terminating a GraphQL query after a configured timeout > > > Key: SLING-10901 > URL: https://issues.apache.org/jira/browse/SLING-10901 > Project: Sling > Issue Type: Improvement > Components: GraphQL > Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: GraphQL Core 0.0.32 > > > Since expensive GraphQL queries could lead to a DoS attack, it would be worth > allowing a system administrator to configure the maximum execution time of a > query. When a long running query is interrupted, the returned error should be > transparent for the GraphQL engine, so that the client knows exactly why the > query failed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12221) Upgrade grahpql-java version to 20.3
[ https://issues.apache.org/jira/browse/SLING-12221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu closed SLING-12221. > Upgrade grahpql-java version to 20.3 > > > Key: SLING-12221 > URL: https://issues.apache.org/jira/browse/SLING-12221 > Project: Sling > Issue Type: Bug > Components: GraphQL >Affects Versions: GraphQL Core 0.0.26 >Reporter: Lenard Palko > Assignee: Radu Cotescu >Priority: Minor > Fix For: GraphQL Core 0.0.30 > > > The version of graphql-java currently used is 20.1, but version 20.3 offers > the possibility to configure also MAX_QUERY_CHARACTERS, in addition to > MAX_QUERY_TOKENS and MAX_WHITESPACE_TOKENS. > [https://github.com/graphql-java/graphql-java/blob/v20.3/src/main/java/graphql/parser/ParserOptions.java#L24] > This would allow to configure the full query length in case the already > existing configurations limits are hit. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[RESULT] [VOTE] Release Apache Sling GraphQL Core 0.0.30
Hi, The vote has passed with the following result: +1 (binding): Robert Munteanu, Carsten Ziegeler, Joerg Hoh +1 (non-binding): none I will copy this release to the Sling dist directory and promote the artifacts to the central Maven repository. Regards, Radu Cotescu
[VOTE] Release Apache Sling GraphQL Core 0.0.30
Hi, We solved 1 issue in this release: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310710=12354075=Text Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2838/ You can use this UNIX script to download the release and verify the signatures: https://raw.githubusercontent.com/apache/sling-tooling-release/master/check_staged_release.sh Usage: sh check_staged_release.sh 2838 /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, Radu Cotescu
[jira] [Resolved] (SLING-12221) Upgrade grahpql-java version to 20.3
[ https://issues.apache.org/jira/browse/SLING-12221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu resolved SLING-12221. -- Fix Version/s: GraphQL Core 0.0.30 Resolution: Fixed > Upgrade grahpql-java version to 20.3 > > > Key: SLING-12221 > URL: https://issues.apache.org/jira/browse/SLING-12221 > Project: Sling > Issue Type: Bug > Components: GraphQL >Affects Versions: GraphQL Core 0.0.26 >Reporter: Lenard Palko > Assignee: Radu Cotescu >Priority: Minor > Fix For: GraphQL Core 0.0.30 > > > The version of graphql-java currently used is 20.1, but version 20.3 offers > the possibility to configure also MAX_QUERY_CHARACTERS, in addition to > MAX_QUERY_TOKENS and MAX_WHITESPACE_TOKENS. > [https://github.com/graphql-java/graphql-java/blob/v20.3/src/main/java/graphql/parser/ParserOptions.java#L24] > This would allow to configure the full query length in case the already > existing configurations limits are hit. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12198) Extending sling.graphql.engine to allow passing custom graphql ParserOptions while executing GraphQL queries
[ https://issues.apache.org/jira/browse/SLING-12198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu closed SLING-12198. > Extending sling.graphql.engine to allow passing custom graphql ParserOptions > while executing GraphQL queries > > > Key: SLING-12198 > URL: https://issues.apache.org/jira/browse/SLING-12198 > Project: Sling > Issue Type: Improvement > Components: GraphQL >Affects Versions: GraphQL Core 0.0.24 >Reporter: Andrzej Kubas >Assignee: Bertrand Delacretaz >Priority: Major > Fix For: GraphQL Core 0.0.28 > > > The graphql-java crates default ParserOptions(if not passed with > ExecutionInput#graphQLContext) while executing GraphQL query. > [https://github.com/graphql-java/graphql-java/blob/v20.3/src/main/java/graphql/ParseAndValidate.java#L67] > [https://github.com/graphql-java/graphql-java/blob/v20.3/src/main/java/graphql/parser/ParserOptions.java#L35] > That could lead to 'Denial Of Service' InvalidSyntax error while executing > GraphQL complex queries. > > However, there should be a way to set graphql-java execution up with custom > values of ParserOprions. > [https://github.com/apache/sling-org-apache-sling-graphql-core/blob/org.apache.sling.graphql.core-0.0.24/src/main/java/org/apache/sling/graphql/core/engine/DefaultQueryExecutor.java#L208] > [https://github.com/apache/sling-org-apache-sling-graphql-core/blob/org.apache.sling.graphql.core-0.0.24/src/main/java/org/apache/sling/graphql/core/engine/DefaultQueryExecutor.java#L202] > https://github.com/apache/sling-org-apache-sling-graphql-core/blob/org.apache.sling.graphql.core-0.0.24/src/main/java/org/apache/sling/graphql/core/engine/DefaultQueryExecutor.java#L155 > > That should help to orchestrate custom graphql-java executions for complex > GraphQL queries. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12200) sling-org-apache-sling-graphql-core unnecessarily uses the shaded guava from graphql-java
[ https://issues.apache.org/jira/browse/SLING-12200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu closed SLING-12200. > sling-org-apache-sling-graphql-core unnecessarily uses the shaded guava from > graphql-java > - > > Key: SLING-12200 > URL: https://issues.apache.org/jira/browse/SLING-12200 > Project: Sling > Issue Type: Improvement > Components: GraphQL >Affects Versions: GraphQL Core 0.0.26 >Reporter: Manfred Baedke >Assignee: Bertrand Delacretaz >Priority: Trivial > Fix For: GraphQL Core 0.0.28 > > > AFAIK shaded Guava is no longer part part of recent releases of graphql-java. > The only usage is > https://github.com/apache/sling-org-apache-sling-graphql-core/blob/30babad3caab0da0dc85bc0d645f76ca6784ef67/src/main/java/org/apache/sling/graphql/core/engine/SelectedFieldWrapper.java#L181, > which is trivial to replace with JavaSE. > cc [~reschke] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[RESULT] [VOTE] Release Apache Sling GraphQL Core 0.0.28
Hi, The vote has passed with the following result: +1 (binding): Carsten Ziegeler, Robert Munteanu, Bertrand Delacretaz +1 (non-binding): none I will copy this release to the Sling dist directory and promote the artifacts to the central Maven repository. Regards, Radu Cotescu
[jira] [Assigned] (SLING-12221) Upgrade grahpql-java version to 20.3
[ https://issues.apache.org/jira/browse/SLING-12221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu reassigned SLING-12221: Assignee: Radu Cotescu > Upgrade grahpql-java version to 20.3 > > > Key: SLING-12221 > URL: https://issues.apache.org/jira/browse/SLING-12221 > Project: Sling > Issue Type: Bug > Components: GraphQL >Affects Versions: GraphQL Core 0.0.26 >Reporter: Lenard Palko > Assignee: Radu Cotescu >Priority: Minor > > The version of graphql-java currently used is 20.1, but version 20.3 offers > the possibility to configure also MAX_QUERY_CHARACTERS, in addition to > MAX_QUERY_TOKENS and MAX_WHITESPACE_TOKENS. > [https://github.com/graphql-java/graphql-java/blob/v20.3/src/main/java/graphql/parser/ParserOptions.java#L24] > This would allow to configure the full query length in case the already > existing configurations limits are hit. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[VOTE] Release Apache Sling GraphQL Core 0.0.28
Hi, We solved 2 issues in this release: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310710=12354026=Text Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2826 You can use this UNIX script to download the release and verify the signatures: https://raw.githubusercontent.com/apache/sling-tooling-release/master/check_staged_release.sh Usage: sh check_staged_release.sh 2826 /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, Radu Cotescu
Re: [VOTE] Release Apache Sling Provider Type Checker Bnd Plugin 1.0.0
Hi Konrad, > On 13 Dec 2023, at 11:28, Konrad Windszus wrote: > > I sent it: https://lists.apache.org/thread/znrmbfkkx092fqtg2js6fo7jh4bg55sp. Sorry, my email client played a trick on me. > It is just not appearing in the VOTE email thread. I was not expecting it anyways there, usually we start another thread for the result email. Thanks, Radu
Re: Unable to create a release
Hi Carsten, I had similar issues whenever my external IP address had changed during the release process. I suspect you had the same problem? Regards, Radu > On 6 Dec 2023, at 14:05, Carsten Ziegeler wrote: > > Just realized that this might be due to my network setup. Will later try again > > Thanks > Carsten
Re: [VOTE] Release Apache Sling Provider Type Checker Bnd Plugin 1.0.0
Hi Konrad, Have you forgotten to send the result email? Thanks, Radu > On 9 Dec 2023, at 17:20, Konrad Windszus wrote: > > Here is my +1. > Konrad > >> On 5. Dec 2023, at 17:35, Konrad Windszus wrote: >> >> Hi, >> We solved 1 issue in this release: >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310710=12354002=Text >> Staging repository: >> https://repository.apache.org/content/repositories/orgapachesling-2811/ >> You can use this UNIX script to download the release and verify the >> signatures: >> https://raw.githubusercontent.com/apache/sling-tooling-release/master/check_staged_release.sh >> Usage: sh check_staged_release.sh 2811 /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 in advance for voting, >> Konrad >
Re: [VOTE] Release Apache Sling Context-Aware Configuration Mock Plugin 1.5.4
+1 > On 11 Dec 2023, at 16:15, Stefan Seifert > wrote: > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ...
Re: [VOTE] Release Apache Sling GraphQL 0.0.26
+1 > On 13 Dec 2023, at 07:13, Carsten Ziegeler wrote: > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ...
[jira] [Commented] (SLING-12027) GraphQL core fails to build with Java 17
[ https://issues.apache.org/jira/browse/SLING-12027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768749#comment-17768749 ] Radu Cotescu commented on SLING-12027: -- [~andysch], could it be that the tests are running with relatively old Sling Engine and Sling Servlet Resolver bundles? Have you tried updating those? > GraphQL core fails to build with Java 17 > > > Key: SLING-12027 > URL: https://issues.apache.org/jira/browse/SLING-12027 > Project: Sling > Issue Type: Bug > Components: GraphQL >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > Fix For: GraphQL Core 0.0.26 > > > 1. Mockito fails to create mocks, probably due to old version > 2. Pax-Exam tests time out -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12014) GraphQL Core needs to support additional fields from GraphQL Java
[ https://issues.apache.org/jira/browse/SLING-12014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-12014: - Summary: GraphQL Core needs to support additional fields from GraphQL Java (was: GraphQL Core needs to Support Addition Fields from GraphQL Java) > GraphQL Core needs to support additional fields from GraphQL Java > - > > Key: SLING-12014 > URL: https://issues.apache.org/jira/browse/SLING-12014 > Project: Sling > Issue Type: Improvement >Reporter: Andreas Schaefer >Assignee: Andreas Schaefer >Priority: Major > > There is a need to have additional fields from the GraphQL Java's Selected > Field. For example there is a need to separate fields with the same name but > different parent through the Fully Qualified Name. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12003) The RequestDispatcher should flush the buffer on forward only if the buffer hasn't already been closed
[
https://issues.apache.org/jira/browse/SLING-12003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu closed SLING-12003.
> The RequestDispatcher should flush the buffer on forward only if the buffer
> hasn't already been closed
> --
>
> Key: SLING-12003
> URL: https://issues.apache.org/jira/browse/SLING-12003
> Project: Sling
> Issue Type: Improvement
> Components: Engine
>Affects Versions: Engine 2.2.10
> Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Engine 2.15.6
>
>
> The {{SlingRequestDispatcher#forward}} call [0] attempts to close the
> response buffer even if this has already been closed by the servlet to which
> the request was originally forwarded. The Servlet Specification [1] mentions
> the following in section 9.4:
> {quote}Before the forward method of the RequestDispatcher interface returns
> without exception, the response content must be sent and committed, and
> closed by the servlet container, unless the request was put into the
> asynchronous mode.
> {quote}
> As such, the {{RequestDispatcher#forward}} implementation should indeed make
> sure the response is committed, but it's not necessarily the only one that
> must commit the response. Jetty seems to have the same understanding [2],
> where the close is performed only if the response hasn't already been
> committed and the request is not async.
> [0] -
> [https://github.com/apache/sling-org-apache-sling-engine/blob/368690a2a81fd8a121e62767fcd32b63936a65b8/src/main/java/org/apache/sling/engine/impl/request/SlingRequestDispatcher.java#L125-L128]
> [1] -
> [https://download.oracle.com/otn-pub/jcp/servlet-3_1-fr-spec/servlet-3_1-final.pdf]
> [2] -
> [https://github.com/eclipse/jetty.project/blob/jetty-11.0.x/jetty-server/src/main/java/org/eclipse/jetty/server/Dispatcher.java#L218]
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[RESULT] [VOTE] Release Apache Sling Engine 2.15.6
Hi, The vote has passed with the following result: +1 (binding): Carsten Ziegeler, Stefan Seifert, Eric Norman +1 (non-binding): Andreas Schaefer I will copy this release to the Sling dist directory and promote the artifacts to the central Maven repository. Regards, Radu Cotescu
[VOTE] Release Apache Sling Engine 2.15.6
Hi, We solved 1 issue in this release: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310710=12353543=Text Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2778/ You can use this UNIX script to download the release and verify the signatures: https://raw.githubusercontent.com/apache/sling-tooling-release/master/check_staged_release.sh Usage: sh check_staged_release.sh 2778 /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, Radu Cotescu
[jira] [Resolved] (SLING-12003) The RequestDispatcher should flush the buffer on forward only if the buffer hasn't already been closed
[
https://issues.apache.org/jira/browse/SLING-12003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu resolved SLING-12003.
--
Resolution: Fixed
> The RequestDispatcher should flush the buffer on forward only if the buffer
> hasn't already been closed
> --
>
> Key: SLING-12003
> URL: https://issues.apache.org/jira/browse/SLING-12003
> Project: Sling
> Issue Type: Improvement
> Components: Engine
>Affects Versions: Engine 2.2.10
> Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Engine 2.15.6
>
>
> The {{SlingRequestDispatcher#forward}} call [0] attempts to close the
> response buffer even if this has already been closed by the servlet to which
> the request was originally forwarded. The Servlet Specification [1] mentions
> the following in section 9.4:
> {quote}Before the forward method of the RequestDispatcher interface returns
> without exception, the response content must be sent and committed, and
> closed by the servlet container, unless the request was put into the
> asynchronous mode.
> {quote}
> As such, the {{RequestDispatcher#forward}} implementation should indeed make
> sure the response is committed, but it's not necessarily the only one that
> must commit the response. Jetty seems to have the same understanding [2],
> where the close is performed only if the response hasn't already been
> committed and the request is not async.
> [0] -
> [https://github.com/apache/sling-org-apache-sling-engine/blob/368690a2a81fd8a121e62767fcd32b63936a65b8/src/main/java/org/apache/sling/engine/impl/request/SlingRequestDispatcher.java#L125-L128]
> [1] -
> [https://download.oracle.com/otn-pub/jcp/servlet-3_1-fr-spec/servlet-3_1-final.pdf]
> [2] -
> [https://github.com/eclipse/jetty.project/blob/jetty-11.0.x/jetty-server/src/main/java/org/eclipse/jetty/server/Dispatcher.java#L218]
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SLING-11458) Regress - "Writer has already been closed" exception in GraphQLServlet
[
https://issues.apache.org/jira/browse/SLING-11458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu closed SLING-11458.
> Regress - "Writer has already been closed" exception in GraphQLServlet
> --
>
> Key: SLING-11458
> URL: https://issues.apache.org/jira/browse/SLING-11458
> Project: Sling
> Issue Type: Bug
> Components: GraphQL
>Affects Versions: GraphQL Core 0.0.4
>Reporter: Evgeny Tugarev
>Assignee: Radu Cotescu
>Priority: Major
>
> The GraphQLServlet shouldn't call {{response.getWriter().flush()}} as the
> {{JsonWriter}} used by the {{JsonSerializer}} implements {{Closeable}} and as
> such [closes the
> Writer|https://github.com/jdereg/json-io/blob/cf849f15460decf10a8a320390de11965bb5996b/src/main/java/com/cedarsoftware/util/io/JsonWriter.java#L2413].
> This causes a "Writer has already been closed" Exception when {{flush()}} is
> called.
> This was fixed in commit d27f4bb7 but then this commit: 11c7e389 did undo the
> fix as now the JsonWriter is closed when existing the try-catch block.
> I will undo it and prevent the premature closure as this is causing issues
> like when the call to this servlet is made through a dispatcher.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SLING-11458) Regress - "Writer has already been closed" exception in GraphQLServlet
[
https://issues.apache.org/jira/browse/SLING-11458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu resolved SLING-11458.
--
Assignee: Radu Cotescu (was: Andreas Schaefer)
Resolution: Not A Problem
> Regress - "Writer has already been closed" exception in GraphQLServlet
> --
>
> Key: SLING-11458
> URL: https://issues.apache.org/jira/browse/SLING-11458
> Project: Sling
> Issue Type: Bug
> Components: GraphQL
>Affects Versions: GraphQL Core 0.0.4
>Reporter: Evgeny Tugarev
>Assignee: Radu Cotescu
>Priority: Major
>
> The GraphQLServlet shouldn't call {{response.getWriter().flush()}} as the
> {{JsonWriter}} used by the {{JsonSerializer}} implements {{Closeable}} and as
> such [closes the
> Writer|https://github.com/jdereg/json-io/blob/cf849f15460decf10a8a320390de11965bb5996b/src/main/java/com/cedarsoftware/util/io/JsonWriter.java#L2413].
> This causes a "Writer has already been closed" Exception when {{flush()}} is
> called.
> This was fixed in commit d27f4bb7 but then this commit: 11c7e389 did undo the
> fix as now the JsonWriter is closed when existing the try-catch block.
> I will undo it and prevent the premature closure as this is causing issues
> like when the call to this servlet is made through a dispatcher.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (SLING-12003) The RequestDispatcher should flush the buffer on forward only if the buffer hasn't already been closed
[
https://issues.apache.org/jira/browse/SLING-12003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu reassigned SLING-12003:
Assignee: Radu Cotescu
> The RequestDispatcher should flush the buffer on forward only if the buffer
> hasn't already been closed
> --
>
> Key: SLING-12003
> URL: https://issues.apache.org/jira/browse/SLING-12003
> Project: Sling
> Issue Type: Improvement
> Components: Engine
>Affects Versions: Engine 2.2.10
> Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Engine 2.15.6
>
>
> The {{SlingRequestDispatcher#forward}} call [0] attempts to close the
> response buffer even if this has already been closed by the servlet to which
> the request was originally forwarded. The Servlet Specification [1] mentions
> the following in section 9.4:
> {quote}Before the forward method of the RequestDispatcher interface returns
> without exception, the response content must be sent and committed, and
> closed by the servlet container, unless the request was put into the
> asynchronous mode.
> {quote}
> As such, the {{RequestDispatcher#forward}} implementation should indeed make
> sure the response is committed, but it's not necessarily the only one that
> must commit the response. Jetty seems to have the same understanding [2],
> where the close is performed only if the response hasn't already been
> committed and the request is not async.
> [0] -
> [https://github.com/apache/sling-org-apache-sling-engine/blob/368690a2a81fd8a121e62767fcd32b63936a65b8/src/main/java/org/apache/sling/engine/impl/request/SlingRequestDispatcher.java#L125-L128]
> [1] -
> [https://download.oracle.com/otn-pub/jcp/servlet-3_1-fr-spec/servlet-3_1-final.pdf]
> [2] -
> [https://github.com/eclipse/jetty.project/blob/jetty-11.0.x/jetty-server/src/main/java/org/eclipse/jetty/server/Dispatcher.java#L218]
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12003) The RequestDispatcher should flush the buffer on forward only if the buffer hasn't already been closed
[
https://issues.apache.org/jira/browse/SLING-12003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17754504#comment-17754504
]
Radu Cotescu commented on SLING-12003:
--
Exactly. I could submit a PR, unless you want to take this over.
> The RequestDispatcher should flush the buffer on forward only if the buffer
> hasn't already been closed
> --
>
> Key: SLING-12003
> URL: https://issues.apache.org/jira/browse/SLING-12003
> Project: Sling
> Issue Type: Improvement
> Components: Engine
>Affects Versions: Engine 2.2.10
> Reporter: Radu Cotescu
>Priority: Major
> Fix For: Engine 2.15.6
>
>
> The {{SlingRequestDispatcher#forward}} call [0] attempts to close the
> response buffer even if this has already been closed by the servlet to which
> the request was originally forwarded. The Servlet Specification [1] mentions
> the following in section 9.4:
> {quote}Before the forward method of the RequestDispatcher interface returns
> without exception, the response content must be sent and committed, and
> closed by the servlet container, unless the request was put into the
> asynchronous mode.
> {quote}
> As such, the {{RequestDispatcher#forward}} implementation should indeed make
> sure the response is committed, but it's not necessarily the only one that
> must commit the response. Jetty seems to have the same understanding [2],
> where the close is performed only if the response hasn't already been
> committed and the request is not async.
> [0] -
> [https://github.com/apache/sling-org-apache-sling-engine/blob/368690a2a81fd8a121e62767fcd32b63936a65b8/src/main/java/org/apache/sling/engine/impl/request/SlingRequestDispatcher.java#L125-L128]
> [1] -
> [https://download.oracle.com/otn-pub/jcp/servlet-3_1-fr-spec/servlet-3_1-final.pdf]
> [2] -
> [https://github.com/eclipse/jetty.project/blob/jetty-11.0.x/jetty-server/src/main/java/org/eclipse/jetty/server/Dispatcher.java#L218]
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-11458) Regress - "Writer has already been closed" exception in GraphQLServlet
[
https://issues.apache.org/jira/browse/SLING-11458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17754497#comment-17754497
]
Radu Cotescu commented on SLING-11458:
--
The GraphQL Servlet doesn't do anything wrong. The error mentioned in this
issue can happen when requests are forwarded to the GraphQL servlet and the
actual cause is described in SLING-12003.
> Regress - "Writer has already been closed" exception in GraphQLServlet
> --
>
> Key: SLING-11458
> URL: https://issues.apache.org/jira/browse/SLING-11458
> Project: Sling
> Issue Type: Bug
> Components: GraphQL
>Affects Versions: GraphQL Core 0.0.4
>Reporter: Evgeny Tugarev
>Assignee: Andreas Schaefer
>Priority: Major
>
> The GraphQLServlet shouldn't call {{response.getWriter().flush()}} as the
> {{JsonWriter}} used by the {{JsonSerializer}} implements {{Closeable}} and as
> such [closes the
> Writer|https://github.com/jdereg/json-io/blob/cf849f15460decf10a8a320390de11965bb5996b/src/main/java/com/cedarsoftware/util/io/JsonWriter.java#L2413].
> This causes a "Writer has already been closed" Exception when {{flush()}} is
> called.
> This was fixed in commit d27f4bb7 but then this commit: 11c7e389 did undo the
> fix as now the JsonWriter is closed when existing the try-catch block.
> I will undo it and prevent the premature closure as this is causing issues
> like when the call to this servlet is made through a dispatcher.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SLING-12003) The RequestDispatcher should flush the buffer on forward only if the buffer hasn't already been closed
Radu Cotescu created SLING-12003:
Summary: The RequestDispatcher should flush the buffer on forward
only if the buffer hasn't already been closed
Key: SLING-12003
URL: https://issues.apache.org/jira/browse/SLING-12003
Project: Sling
Issue Type: Improvement
Components: Engine
Affects Versions: Engine 2.2.10
Reporter: Radu Cotescu
Fix For: Engine 2.15.6
The {{SlingRequestDispatcher#forward}} call [0] attempts to close the response
buffer even if this has already been closed by the servlet to which the request
was originally forwarded. The Servlet Specification [1] mentions the following
in section 9.4:
{quote}Before the forward method of the RequestDispatcher interface returns
without exception, the response content must be sent and committed, and closed
by the servlet container, unless the request was put into the asynchronous mode.
{quote}
As such, the {{RequestDispatcher#forward}} implementation should indeed make
sure the response is committed, but it's not necessarily the only one that must
commit the response. Jetty seems to have the same understanding [2], where the
close is performed only if the response hasn't already been committed and the
request is not async.
[0] -
[https://github.com/apache/sling-org-apache-sling-engine/blob/368690a2a81fd8a121e62767fcd32b63936a65b8/src/main/java/org/apache/sling/engine/impl/request/SlingRequestDispatcher.java#L125-L128]
[1] -
[https://download.oracle.com/otn-pub/jcp/servlet-3_1-fr-spec/servlet-3_1-final.pdf]
[2] -
[https://github.com/eclipse/jetty.project/blob/jetty-11.0.x/jetty-server/src/main/java/org/eclipse/jetty/server/Dispatcher.java#L218]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-11458) Regress - "Writer has already been closed" exception in GraphQLServlet
[
https://issues.apache.org/jira/browse/SLING-11458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17754130#comment-17754130
]
Radu Cotescu commented on SLING-11458:
--
Circling back to this issue.
{quote}Is there a reason why the Servlet Writer needs to be closed?
{quote}
Yes, the GraphQL servlet is the one that controls the execution. What's the
point of having the writer open after the GraphQL execution result has been
sent?
> Regress - "Writer has already been closed" exception in GraphQLServlet
> --
>
> Key: SLING-11458
> URL: https://issues.apache.org/jira/browse/SLING-11458
> Project: Sling
> Issue Type: Bug
> Components: GraphQL
>Affects Versions: GraphQL Core 0.0.4
>Reporter: Evgeny Tugarev
>Assignee: Andreas Schaefer
>Priority: Major
>
> The GraphQLServlet shouldn't call {{response.getWriter().flush()}} as the
> {{JsonWriter}} used by the {{JsonSerializer}} implements {{Closeable}} and as
> such [closes the
> Writer|https://github.com/jdereg/json-io/blob/cf849f15460decf10a8a320390de11965bb5996b/src/main/java/com/cedarsoftware/util/io/JsonWriter.java#L2413].
> This causes a "Writer has already been closed" Exception when {{flush()}} is
> called.
> This was fixed in commit d27f4bb7 but then this commit: 11c7e389 did undo the
> fix as now the JsonWriter is closed when existing the try-catch block.
> I will undo it and prevent the premature closure as this is causing issues
> like when the call to this servlet is made through a dispatcher.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[VOTE] Release Apache Sling GraphQL Core 0.0.22
Hi, We solved 1 issue in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12353082 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2772/ You can use this UNIX script to download the release and verify the signatures: https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD Usage: sh check_staged_release.sh 2772 /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, Radu Cotescu
[jira] [Updated] (SLING-10901) Allow terminating a GraphQL query after a configured timeout
[ https://issues.apache.org/jira/browse/SLING-10901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-10901: - Fix Version/s: GraphQL Core 0.0.24 (was: GraphQL Core 0.0.22) > Allow terminating a GraphQL query after a configured timeout > > > Key: SLING-10901 > URL: https://issues.apache.org/jira/browse/SLING-10901 > Project: Sling > Issue Type: Improvement > Components: GraphQL > Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: GraphQL Core 0.0.24 > > > Since expensive GraphQL queries could lead to a DoS attack, it would be worth > allowing a system administrator to configure the maximum execution time of a > query. When a long running query is interrupted, the returned error should be > transparent for the GraphQL engine, so that the client knows exactly why the > query failed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-11920) Expose Object Type Names in Selected Field
[
https://issues.apache.org/jira/browse/SLING-11920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu resolved SLING-11920.
--
Resolution: Fixed
> Expose Object Type Names in Selected Field
> --
>
> Key: SLING-11920
> URL: https://issues.apache.org/jira/browse/SLING-11920
> Project: Sling
> Issue Type: Bug
>Affects Versions: GraphQL Core 0.0.20
>Reporter: Andreas Schaefer
>Assignee: Andreas Schaefer
>Priority: Critical
> Fix For: GraphQL Core 0.0.22
>
>
> Intermediary fields are not exposed as Selected Fields in Graphql-java and so
> it was added as list of Object Type Name.
> Now for handling '... on ' we need to expose these Object Type
> Names so that a client can deal with them.
> If we have a query where we have a inline fragments
> ([https://graphql.org/learn/queries/#inline-fragments]) like:
> {code:java}
> {
>image {
> ... on ImageRef {
> type{code}
> Then in the graphql-java 15.0 there is an inlined field called *ImageRef* but
> that is now gone in 20.1. Instead we have a list of Object Type Names in a
> field and in our example *type* would have Objet Type Names:
> {*}["ImageRef"]{*}. So for a client to obtain the type of the inlined
> fragments this data must be exposed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: Sling Model Exporter: Prevent serializing of a ResourceResolver
Hi Jörg,
I think you would have the same problem with that model given the other
property, namely that list of resources.
Unfortunately I don’t see an easy way out other than documenting this
aspect and advising developers to avoid exposing implementation details.
Whatever you’d change in the implementation to prevent this, it would be at
least a behaviour change, potentially causing regressions similar to
https://xkcd.com/1172/.
Regards,
Radu
On Tue, 27 Jun 2023 at 18:35, Jörg Hoh
wrote:
> HI Stefan,
>
> I agree, but:
>
> I don't have control over the code, which causes the ResourceResolver to be
> serialized. Also I cannot enforce, that such code is NOT written and
> deployed (there are too many ways to make it wrong). Also because it
> currently works, I would have to counter the "but it worked yesterday, and
> I did not change anything since then" argument, in case it fails with an
> exception like above.
>
> So I have to find another way to prevent the ResourceResolver from being
> serialized ...
>
> Jörg
>
>
>
> Am Di., 27. Juni 2023 um 13:38 Uhr schrieb Stefan Seifert
> :
>
> > well, using lombok with such a result is a bad idea. there should not be
> a
> > getResolver() method, this is an implementation detail and no getter
> should
> > be provided for it.
> >
> > so to put it another way: good that the serialization fails, so you can
> > fix the calls to not add a getResolver() method!
> >
> > stefan
> >
> > p.s. i'm not a fan of lombok in general and have no experience with it,
> > but I assume it can be configured to not expose the resolver.
> >
> > > -Original Message-
> > > From: Jörg Hoh
> > > Sent: Tuesday, June 27, 2023 1:28 PM
> > > To: Sling Developers List
> > > Subject: Sling Model Exporter: Prevent serializing of a
> ResourceResolver
> > >
> > > Hi,
> > >
> > > Assuming this Sling Model (using Lombok's @Getter annotation)
> > >
> > > @Getter
> > > @Model(
> > > adaptables = { SlingHttpServletRequest.class },
> > > adapters = { MyModel.class, ComponentExporter.class },
> > > resourceType = MyModel.RESOURCE_TYPE) @Exporter(
> > > name = ExporterConstants.SLING_MODEL_EXPORTER_NAME,
> > > extensions = ExporterConstants.SLING_MODEL_EXTENSION)
> > > public class MyModel implements ComponentExporter {
> > >
> > > static final String RESOURCE_TYPE = "myapp/components/mymodel";
> > >
> > > @Inject
> > > private ResourceResolver resolver;
> > >
> > > @ChildResource
> > > private List items;
> > >
> > > }
> > >
> > > When it this model is serialized via SlingModelExporter / Jackson, the
> > > resolver field is also exported via the created getResolver()) method.
> > >
> > > But serializing that does not always work:
> > >
> > > org.apache.sling.models.factory.ExportException:
> > > com.fasterxml.jackson.databind.exc.InvalidDefinitionException: No
> > > serializer found for class
> > > com.day.cq.wcm.core.impl.policies.ContentPolicyManagerImpl and no
> > > properties discovered to create BeanSerializer (to avoid exception,
> > > disable
> > > SerializationFeature.FAIL_ON_EMPTY_BEANS) (through reference chain:
> > > com.myapp.PageImpl[":items"]> [...] > com.myapp.MyModel["resolver"]
> > >
> >org.apache.sling.resourceresolver.impl.ResourceResolverImpl["propertyMa
> > > >p"]
> > >
> >java.util.HashMap["com.day.cq.wcm.core.impl.policies.ContentPolicyAdapt
> > > >erFactory.ContentPolicy"])
> > > at
> > >
> >
> org.apache.sling.models.jacksonexporter.impl.JacksonExporter.export(Jackso
> > > nExporter.java:138)
> > > [org.apache.sling.models.jacksonexporter:1.1.2]
> > > at
> > >
> >
> org.apache.sling.models.impl.ModelAdapterFactory.exportModel(ModelAdapterF
> > > actory.java:1333)
> > > [org.apache.sling.models.impl:1.5.4]
> > >
> > >
> > > I don't want to check each class I want to add to the propertyMap if it
> > > can be serialized or not; and a more serious problem is that
> serializing
> > > the resourceResolver and it's properyMap can leak a lot of information,
> > > which should be not get public.
> > >
> > > Do you see a way to prevent serialization of the ResourceResolver (and
> > > potentially other types as well) without touching the model classes?
> > >
> > > Jörg
> > >
> > > --
> > > Cheers,
> > > Jörg Hoh,
> > >
> > > https://cqdump.joerghoh.de
> > > Twitter: @joerghoh
> >
>
>
> --
> Cheers,
> Jörg Hoh,
>
> https://cqdump.joerghoh.de
> Twitter: @joerghoh
>
Re: JIRA Release notes link in vote email template
+1 > On 11 Jun 2023, at 11:30, Konrad Windszus wrote: > > If everyone is fine with that I will modify the email template at > https://sling.apache.org/documentation/development/release-management.html#starting-the-vote > accordingly and the placeholder logic in > https://github.com/apache/sling-org-apache-sling-committer-cli/blob/f7a647acecbbc32c2c76d19e0981b3bbd1d5bcf8/src/main/java/org/apache/sling/cli/impl/release/PrepareVoteEmailCommand.java#L132 > accordingly.
[jira] [Comment Edited] (SLING-11850) HTL: Add support for suffix manipulation in ResourceRuntimeExtension
[
https://issues.apache.org/jira/browse/SLING-11850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731675#comment-17731675
]
Radu Cotescu edited comment on SLING-11850 at 6/12/23 4:14 PM:
---
We never thought about adding support for the suffix, as that doesn't influence
which script will be picked up at rendering time, but I can see why the feature
could be useful. However, the URI Manipulation section of the specification
includes details about the suffix handling:
[https://github.com/adobe/htl-spec/blob/1.4/SPECIFICATION.md#125-uri-manipulation.]
Could you use that instead?
was (Author: radu.cotescu):
We never thought about adding support for the suffix, as that doesn't influence
which script will be picked up at rendering time, but I can see why the feature
could be useful.
> HTL: Add support for suffix manipulation in ResourceRuntimeExtension
>
>
> Key: SLING-11850
> URL: https://issues.apache.org/jira/browse/SLING-11850
> Project: Sling
> Issue Type: Improvement
> Components: Scripting
>Affects Versions: Scripting HTL Engine 1.4.22-1.4.0
>Reporter: Robin Brouns
>Priority: Minor
> Labels: Sightly
>
> In JSP there is the possibility to include a resource in a component and
> adjust the suffix of the sub-request, processing this resource:
> {code:java}
> path="my-component"
> resourceType="application/components/other-component"
> replaceSuffix="some-suffix"/>
> {code}
> See also:
> [https://github.com/apache/sling-org-apache-sling-scripting-jsp-taglib/blob/7835da79f1de7c9c14fd478e9fec23f54fd6d711/src/main/java/org/apache/sling/scripting/jsp/taglib/AbstractDispatcherTagHandler.java#L89]
> But HTL lacks this option to adjust the suffix for the sub-request (by using
> data-sly-resource): see
> [https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/3b50f91c4f600081f0585e50dfb775c4b2856b89/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/ResourceRuntimeExtension.java#L58]
>
> Is there a reason why this feature wasn't added and is not supported right
> now?
> Because we can manipulate the suffix in a URI context in HTL
> ([https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/3b50f91c4f600081f0585e50dfb775c4b2856b89/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/URIManipulationFilterExtension.java#L221),]
> but just not in the Resource context.
> The _RequestDispatcher_ is already available and used in the
> _ResourceRuntimeExtension_ so it could be added.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-11850) HTL: Add support for suffix manipulation in ResourceRuntimeExtension
[
https://issues.apache.org/jira/browse/SLING-11850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731675#comment-17731675
]
Radu Cotescu commented on SLING-11850:
--
We never thought about adding support for the suffix, as that doesn't influence
which script will be picked up at rendering time, but I can see why the feature
could be useful.
> HTL: Add support for suffix manipulation in ResourceRuntimeExtension
>
>
> Key: SLING-11850
> URL: https://issues.apache.org/jira/browse/SLING-11850
> Project: Sling
> Issue Type: Improvement
> Components: Scripting
>Affects Versions: Scripting HTL Engine 1.4.22-1.4.0
>Reporter: Robin Brouns
>Priority: Minor
> Labels: Sightly
>
> In JSP there is the possibility to include a resource in a component and
> adjust the suffix of the sub-request, processing this resource:
> {code:java}
> path="my-component"
> resourceType="application/components/other-component"
> replaceSuffix="some-suffix"/>
> {code}
> See also:
> [https://github.com/apache/sling-org-apache-sling-scripting-jsp-taglib/blob/7835da79f1de7c9c14fd478e9fec23f54fd6d711/src/main/java/org/apache/sling/scripting/jsp/taglib/AbstractDispatcherTagHandler.java#L89]
> But HTL lacks this option to adjust the suffix for the sub-request (by using
> data-sly-resource): see
> [https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/3b50f91c4f600081f0585e50dfb775c4b2856b89/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/ResourceRuntimeExtension.java#L58]
>
> Is there a reason why this feature wasn't added and is not supported right
> now?
> Because we can manipulate the suffix in a URI context in HTL
> ([https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/3b50f91c4f600081f0585e50dfb775c4b2856b89/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/URIManipulationFilterExtension.java#L221),]
> but just not in the Resource context.
> The _RequestDispatcher_ is already available and used in the
> _ResourceRuntimeExtension_ so it could be added.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SLING-11852) Make the ThreadsafeMockAdapterManagerWrapper use an InheritableThreadLocal
[
https://issues.apache.org/jira/browse/SLING-11852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu closed SLING-11852.
> Make the ThreadsafeMockAdapterManagerWrapper use an InheritableThreadLocal
> --
>
> Key: SLING-11852
> URL: https://issues.apache.org/jira/browse/SLING-11852
> Project: Sling
> Issue Type: Improvement
> Components: Testing
> Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Testing Sling Mock 3.4.8
>
>
> For scenarios where the mocked OSGi framework executes calls in other threads
> than the test thread (e.g. servlets under test in Jetty), the only way to
> pass the test's {{AdapterManager}} is to directly call
> {{{}SlingAdaptable#setAdapterManager{}}}. However, this will affect tests
> starting after this initial call.
> A better solution would be to make the
> {{org.apache.sling.testing.mock.sling.ThreadsafeMockAdapterManagerWrapper#THREAD_LOCAL}}
> an {{{}InheritableThreadLocal{}}}. This would allow the tests to still be
> executable in parallel, but threads started from a test thread (e.g. the
> servlets under test in Jetty) could inherit the thread local context.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[RESULT][VOTE] Release Apache Sling Testing Sling Mock 3.4.8
Hi, The vote has passed with the following result: +1 (binding): Eric Norman, Stefan Seifert, Radu Cotescu +1 (non-binding): none I will copy this release to the Sling dist directory and promote the artifacts to the central Maven repository. Regards, Radu Cotescu
Re: [VOTE] Release Apache Sling Testing Sling Mock 3.4.8
+1 > On 28 Apr 2023, at 16:12, Radu Cotescu wrote: > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ...
[VOTE] Release Apache Sling Testing Sling Mock 3.4.8
Hi, We solved 1 issue in this release: https://issues.apache.org/jira/projects/SLING/versions/12353178 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2739 You can use this UNIX script to download the release and verify the signatures: https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD Usage: sh check_staged_release.sh 2739 /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, Radu Cotescu smime.p7s Description: S/MIME cryptographic signature
[jira] [Resolved] (SLING-11852) Make the ThreadsafeMockAdapterManagerWrapper use an InheritableThreadLocal
[
https://issues.apache.org/jira/browse/SLING-11852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu resolved SLING-11852.
--
Resolution: Fixed
> Make the ThreadsafeMockAdapterManagerWrapper use an InheritableThreadLocal
> --
>
> Key: SLING-11852
> URL: https://issues.apache.org/jira/browse/SLING-11852
> Project: Sling
> Issue Type: Improvement
> Components: Testing
> Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Testing Sling Mock 3.4.8
>
>
> For scenarios where the mocked OSGi framework executes calls in other threads
> than the test thread (e.g. servlets under test in Jetty), the only way to
> pass the test's {{AdapterManager}} is to directly call
> {{{}SlingAdaptable#setAdapterManager{}}}. However, this will affect tests
> starting after this initial call.
> A better solution would be to make the
> {{org.apache.sling.testing.mock.sling.ThreadsafeMockAdapterManagerWrapper#THREAD_LOCAL}}
> an {{{}InheritableThreadLocal{}}}. This would allow the tests to still be
> executable in parallel, but threads started from a test thread (e.g. the
> servlets under test in Jetty) could inherit the thread local context.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [VOTE] Release Apache Sling Servlet Helpers 1.4.6, Testing JCR Mock 1.6.8, Testing Sling Mock 3.4.6
+1 > On 24 Apr 2023, at 02:28, Eric Norman wrote: > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ...
[jira] [Assigned] (SLING-11852) Make the ThreadsafeMockAdapterManagerWrapper use an InheritableThreadLocal
[
https://issues.apache.org/jira/browse/SLING-11852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu reassigned SLING-11852:
Assignee: Radu Cotescu
> Make the ThreadsafeMockAdapterManagerWrapper use an InheritableThreadLocal
> --
>
> Key: SLING-11852
> URL: https://issues.apache.org/jira/browse/SLING-11852
> Project: Sling
> Issue Type: Improvement
> Components: Testing
> Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Testing Sling Mock 3.4.8
>
>
> For scenarios where the mocked OSGi framework executes calls in other threads
> than the test thread (e.g. servlets under test in Jetty), the only way to
> pass the test's {{AdapterManager}} is to directly call
> {{{}SlingAdaptable#setAdapterManager{}}}. However, this will affect tests
> starting after this initial call.
> A better solution would be to make the
> {{org.apache.sling.testing.mock.sling.ThreadsafeMockAdapterManagerWrapper#THREAD_LOCAL}}
> an {{{}InheritableThreadLocal{}}}. This would allow the tests to still be
> executable in parallel, but threads started from a test thread (e.g. the
> servlets under test in Jetty) could inherit the thread local context.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SLING-11852) Make the ThreadsafeMockAdapterManagerWrapper use an InheritableThreadLocal
Radu Cotescu created SLING-11852:
Summary: Make the ThreadsafeMockAdapterManagerWrapper use an
InheritableThreadLocal
Key: SLING-11852
URL: https://issues.apache.org/jira/browse/SLING-11852
Project: Sling
Issue Type: Improvement
Components: Testing
Reporter: Radu Cotescu
Fix For: Testing Sling Mock 3.4.8
For scenarios where the mocked OSGi framework executes calls in other threads
than the test thread (e.g. servlets under test in Jetty), the only way to pass
the test's {{AdapterManager}} is to directly call
{{{}SlingAdaptable#setAdapterManager{}}}. However, this will affect tests
starting after this initial call.
A better solution would be to make the
{{org.apache.sling.testing.mock.sling.ThreadsafeMockAdapterManagerWrapper#THREAD_LOCAL}}
an {{{}InheritableThreadLocal{}}}. This would allow the tests to still be
executable in parallel, but threads started from a test thread (e.g. the
servlets under test in Jetty) could inherit the thread local context.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [VOTE] Release Apache Sling JCR Base 3.1.14
+1 > On 4 Apr 2023, at 16:04, Angela Schreiber wrote: > > 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.
[jira] [Updated] (SLING-8972) Self-explanatory message when the module name and Jira version name do not match
[
https://issues.apache.org/jira/browse/SLING-8972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-8972:
Fix Version/s: Committer CLI 1.0.2
(was: Committer CLI 1.0.0)
> Self-explanatory message when the module name and Jira version name do not
> match
>
>
> Key: SLING-8972
> URL: https://issues.apache.org/jira/browse/SLING-8972
> Project: Sling
> Issue Type: Improvement
> Components: Build and Source Control
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: Committer CLI 1.0.2
>
>
> When the committer CLI does not find a matching Jira release for the module
> name it fails with slightly cryptic error message (see below). We should
> explain to the user what is wrong, e.g. "Unable to match release with a Jira
> version - did not find a Jira version matching ${MODULE_NAME} ${VERSION}"
> {noformat}java.lang.IllegalArgumentException: No version found with name
> Default
> POST Servlets 2.3.34
> at
> org.apache.sling.cli.impl.jira.VersionClient.lambda$find$1(VersionClient.java:84)
> at java.base/java.util.Optional.orElseThrow(Unknown Source)
> at
> org.apache.sling.cli.impl.jira.VersionClient.find(VersionClient.java:84)
> at
> org.apache.sling.cli.impl.release.PrepareVoteEmailCommand.lambda$run$0(PrepareVoteEmailCommand.java:116)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(Unknown Source)
> at java.base/java.util.Iterator.forEachRemaining(Unknown Source)
> at
> java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Unknown
> Source)
> at java.base/java.util.stream.AbstractPipeline.copyInto(Unknown
> Source)
> at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(Unknown Source)
> at
> java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(Unknown
> Source)
> at java.base/java.util.stream.AbstractPipeline.evaluate(Unknown
> Source)
> at java.base/java.util.stream.ReferencePipeline.collect(Unknown
> Source)
> at
> org.apache.sling.cli.impl.release.PrepareVoteEmailCommand.run(PrepareVoteEmailCommand.java:117)
> at picocli.CommandLine.executeUserObject(CommandLine.java:1687)
> at picocli.CommandLine.access$900(CommandLine.java:146)
> at picocli.CommandLine$RunLast.handle(CommandLine.java:2059)
> at picocli.CommandLine$RunLast.handle(CommandLine.java:2026)
> at
> picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:1893)
> at picocli.CommandLine.execute(CommandLine.java:1822)
> at
> org.apache.sling.cli.impl.CommandProcessor.runCommand(CommandProcessor.java:110)
> at
> org.apache.sling.cli.impl.ExecutionTrigger.lambda$activate$0(ExecutionTrigger.java:33)
> at java.base/java.lang.Thread.run(Unknown Source)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-8338) Create sub-command to manage the Nexus stage repository release when promoting a release
[
https://issues.apache.org/jira/browse/SLING-8338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-8338:
Fix Version/s: (was: Committer CLI 1.0.0)
Committer CLI 1.0.2
> Create sub-command to manage the Nexus stage repository release when
> promoting a release
>
>
> Key: SLING-8338
> URL: https://issues.apache.org/jira/browse/SLING-8338
> Project: Sling
> Issue Type: Improvement
> Components: Tooling
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: Committer CLI 1.0.2
>
>
> We should add a new command {{release nexus-release}} which takes care of
> releasing the staged artifacts from Nexus for a new release.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-10355) Update the Commiter CLI to check SHA-512 signatures for the source release
[ https://issues.apache.org/jira/browse/SLING-10355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-10355: - Fix Version/s: Committer CLI 1.0.2 (was: Committer CLI 1.0.0) > Update the Commiter CLI to check SHA-512 signatures for the source release > -- > > Key: SLING-10355 > URL: https://issues.apache.org/jira/browse/SLING-10355 > Project: Sling > Issue Type: Improvement > Components: Tooling >Reporter: Robert Munteanu >Priority: Major > Fix For: Committer CLI 1.0.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-8699) Create sub-command to moving artifacts to dist.apache.org
[
https://issues.apache.org/jira/browse/SLING-8699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-8699:
Fix Version/s: Committer CLI 1.0.2
(was: Committer CLI 1.0.0)
> Create sub-command to moving artifacts to dist.apache.org
> -
>
> Key: SLING-8699
> URL: https://issues.apache.org/jira/browse/SLING-8699
> Project: Sling
> Issue Type: New Feature
> Components: Tooling
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: Committer CLI 1.0.2
>
>
> With SLING-8684 we now have the pieces in place to automate promoting
> artifacts to dist.apache.org.
> This sub-command will perform the following actions:
> - compute SHA-256 checksums and adds them to the files to be deployed
> - not include MD5 checksums
> - use the Java API equivalent of {{svn remove https://dist.apache.org/ ...}}
> to remove all old artifacts of a release
> - use the Java API equivalent of {{svn import . https://dist.apache.org/
> ...}} to import local set of artifacts to SVN
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-8395) Investigate automatically issuing GitHub PRs with the Committer CLI
[ https://issues.apache.org/jira/browse/SLING-8395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-8395: Fix Version/s: Committer CLI 1.0.2 (was: Committer CLI 1.0.0) > Investigate automatically issuing GitHub PRs with the Committer CLI > --- > > Key: SLING-8395 > URL: https://issues.apache.org/jira/browse/SLING-8395 > Project: Sling > Issue Type: Improvement > Components: Tooling >Reporter: Robert Munteanu >Priority: Major > Fix For: Committer CLI 1.0.2 > > > Some actions ( site update, starter update ) would require pushing code. > Ideally we would make these part a bot which issues pull requests which would > then be merged by a Sling Committer. > Major question is - how do we host this? Is Jenkins enough or do we need to > handle our own server (which would be a major disadvantage ). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-9301) CI validator does not take into account additional artifacts
[
https://issues.apache.org/jira/browse/SLING-9301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-9301:
Fix Version/s: Committer CLI 1.0.2
(was: Committer CLI 1.0.0)
> CI validator does not take into account additional artifacts
>
>
> Key: SLING-9301
> URL: https://issues.apache.org/jira/browse/SLING-9301
> Project: Sling
> Issue Type: Bug
> Components: Build and Source Control
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: Committer CLI 1.0.2
>
>
> When verifying a release that stages multiple artifacts, the CI status is
> printed for only one of them
> {noformat} $ ./run.sh release verify -r 2228
> org.apache.sling.repoinit.parser-1.6.2-source-release.zip
> GPG: signed by Bertrand Delacretaz (CODE SIGNING KEY)
> with key (id=0x77B6B69A9E4DCC6B;
> fingerprint=5EFF256585AC5FB607F6D46A77B6B69A9E4DCC6B)
> SHA-1: VALID (c2cf2ecfbdd9ae9de1c34b5c101a3cca5e89ee77)
> MD-5: VALID (cf819d39586ed9a7f2ab27b712354347)
> org.apache.sling.repoinit.parser-1.6.2.pom
> GPG: signed by Bertrand Delacretaz (CODE SIGNING KEY)
> with key (id=0x77B6B69A9E4DCC6B;
> fingerprint=5EFF256585AC5FB607F6D46A77B6B69A9E4DCC6B)
> SHA-1: VALID (a50ec0a3cd9d4cc351851e1fe2f0eb2fc4417263)
> MD-5: VALID (3fc5989f52b6d94a932c4e2ed1092b6e)
> org.apache.sling.jcr.repoinit-1.1.24-javadoc.jar
> GPG: signed by Bertrand Delacretaz (CODE SIGNING KEY)
> with key (id=0x77B6B69A9E4DCC6B;
> fingerprint=5EFF256585AC5FB607F6D46A77B6B69A9E4DCC6B)
> SHA-1: VALID (fe2eac7e58c88a2e1cb94df8890dd28aa9139fb8)
> MD-5: VALID (6557cc5774264eaf3b6b6a0cace03e29)
> org.apache.sling.jcr.repoinit-1.1.24-sources.jar
> GPG: signed by Bertrand Delacretaz (CODE SIGNING KEY)
> with key (id=0x77B6B69A9E4DCC6B;
> fingerprint=5EFF256585AC5FB607F6D46A77B6B69A9E4DCC6B)
> SHA-1: VALID (fc656cbb87cc4de9ed0a75b0832f5af98b86ec77)
> MD-5: VALID (2ddc5461e6a2dd9e7cc265055e857fbc)
> org.apache.sling.jcr.repoinit-1.1.24-source-release.zip
> GPG: signed by Bertrand Delacretaz (CODE SIGNING KEY)
> with key (id=0x77B6B69A9E4DCC6B;
> fingerprint=5EFF256585AC5FB607F6D46A77B6B69A9E4DCC6B)
> SHA-1: VALID (8bbcefb958396b0822e25c49cab0ab3cf8c36afa)
> MD-5: VALID (b8ff72fe65527861702117d70707)
> org.apache.sling.repoinit.parser-1.6.2.jar
> GPG: signed by Bertrand Delacretaz (CODE SIGNING KEY)
> with key (id=0x77B6B69A9E4DCC6B;
> fingerprint=5EFF256585AC5FB607F6D46A77B6B69A9E4DCC6B)
> SHA-1: VALID (54442784c12cb4fe5ae78a6c07d4833a4b814ebe)
> MD-5: VALID (1136e820a52c86e5e1621e9781a5302b)
> org.apache.sling.repoinit.parser-1.6.2-javadoc.jar
> GPG: signed by Bertrand Delacretaz (CODE SIGNING KEY)
> with key (id=0x77B6B69A9E4DCC6B;
> fingerprint=5EFF256585AC5FB607F6D46A77B6B69A9E4DCC6B)
> SHA-1: VALID (0aa8c275106c86d0717ff4a1b1255a6d39170603)
> MD-5: VALID (8c94789be7d15126f786942492d5cfd6)
> org.apache.sling.jcr.repoinit-1.1.24.jar
> GPG: signed by Bertrand Delacretaz (CODE SIGNING KEY)
> with key (id=0x77B6B69A9E4DCC6B;
> fingerprint=5EFF256585AC5FB607F6D46A77B6B69A9E4DCC6B)
> SHA-1: VALID (134f7c334d22f8187c6452762258a071ef454e77)
> MD-5: VALID (e4e73aff04aff5b49805229a03f9358b)
> org.apache.sling.jcr.repoinit-1.1.24.pom
> GPG: signed by Bertrand Delacretaz (CODE SIGNING KEY)
> with key (id=0x77B6B69A9E4DCC6B;
> fingerprint=5EFF256585AC5FB607F6D46A77B6B69A9E4DCC6B)
> SHA-1: VALID (255485068f952d548a24faa5766e918d4680f42c)
> MD-5: VALID (9765d12d2acd46073a0edbcf6bb769f4)
> org.apache.sling.repoinit.parser-1.6.2-sources.jar
> GPG: signed by Bertrand Delacretaz (CODE SIGNING KEY)
> with key (id=0x77B6B69A9E4DCC6B;
> fingerprint=5EFF256585AC5FB607F6D46A77B6B69A9E4DCC6B)
> SHA-1: VALID (bcde5285e0389198a170b0ececf022cad0cf9216)
> MD-5: VALID (15632480b50dd9f3421834d2bfafda39)
> CI Status: INVALID:
> continuous-integration/jenkins/branch
> State: error
> Description: This commit cannot be built
> See:
> https://builds.apache.org/job/Sling/job/sling-org-apache-sling-jcr-repoinit/job/master/311/display/redirect
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-8393) Create sub-command to update the Sling website when a release is made
[ https://issues.apache.org/jira/browse/SLING-8393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-8393: Fix Version/s: Committer CLI 1.0.2 (was: Committer CLI 1.0.0) > Create sub-command to update the Sling website when a release is made > - > > Key: SLING-8393 > URL: https://issues.apache.org/jira/browse/SLING-8393 > Project: Sling > Issue Type: Improvement > Components: Tooling >Reporter: Robert Munteanu >Priority: Major > Fix For: Committer CLI 1.0.2 > > > The current `release update-local-site` command generates a git diff when > ran. It would be useful to have the change committed and pushed to a remote > branch, ideally creating a PR for review. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-9083) Add support for authenticated requests when checking a release's build status
[
https://issues.apache.org/jira/browse/SLING-9083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-9083:
Fix Version/s: Committer CLI 1.0.2
(was: Committer CLI 1.0.0)
> Add support for authenticated requests when checking a release's build status
> -
>
> Key: SLING-9083
> URL: https://issues.apache.org/jira/browse/SLING-9083
> Project: Sling
> Issue Type: Improvement
> Components: Tooling
> Reporter: Radu Cotescu
>Priority: Major
> Fix For: Committer CLI 1.0.2
>
>
> The {{org.apache.sling.cli.impl.ci.CIStatusValidator}} checks if a release's
> build status is valid, when verifying a release. Depending on the network
> from which the requests originate, GitHub might enforce its API rate
> limiting, leading to a failure in the validator - the {{success}} JSON key is
> missing from the response. On one hand, the validator's JSON parsing could be
> improved to not fail if this key is missing. However, if a request is
> authenticated (usually with a GitHub access token), the rate limiting is not
> enforced (or better said the limit is so high that it should not be reached).
> This issue should implement both suggestions from above:
> # make the JSON parsing more resilient
> # optionally use a GitHub access token, if provided in the environment, to
> perform authenticated requests against the GitHub API
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-8394) Create sub-command to update the Sling starter when a release is made
[ https://issues.apache.org/jira/browse/SLING-8394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-8394: Fix Version/s: Committer CLI 1.0.2 (was: Committer CLI 1.0.0) > Create sub-command to update the Sling starter when a release is made > - > > Key: SLING-8394 > URL: https://issues.apache.org/jira/browse/SLING-8394 > Project: Sling > Issue Type: Improvement > Components: Tooling >Reporter: Robert Munteanu >Priority: Major > Fix For: Committer CLI 1.0.2 > > > The command should update the provisioning model files and then issue a pull > request against the starter repo. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-8808) Committer CLI does not record all votes from PMC members as binding
[
https://issues.apache.org/jira/browse/SLING-8808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-8808:
Fix Version/s: Committer CLI 1.0.2
(was: Committer CLI 1.0.0)
> Committer CLI does not record all votes from PMC members as binding
> ---
>
> Key: SLING-8808
> URL: https://issues.apache.org/jira/browse/SLING-8808
> Project: Sling
> Issue Type: Bug
> Components: Build and Source Control
>Reporter: Robert Munteanu
>Priority: Critical
> Fix For: Committer CLI 1.0.2
>
>
> {noformat}$ ./run.sh release tally-votes -r 2146
> The following email would be sent from your @apache.org address (see the
> "From:" header):
> From: Robert Munteanu
> To: "Sling Developers List"
> Reply-To: "Sling Developers List"
> Date: Mon, 28 Oct 2019 09:32:28 +
> Subject: [RESULT] [VOTE] Release Apache Sling Commons Threads 3.2.20
> Hi,
> The vote has passed with the following result:
> +1 (binding): Robert Munteanu, Carsten Ziegeler, Dan Klco, Radu Cotescu
> +1 (non-binding): David Bosschaert
> I will copy this release to the Sling dist directory and
> promote the artifacts to the central Maven repository.
> Regards,
> Robert Munteanu
> {noformat}
> David's vote is definitely binding.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SLING-11097) Committers CLI CI Fails on Tags
[ https://issues.apache.org/jira/browse/SLING-11097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu resolved SLING-11097. -- Resolution: Fixed > Committers CLI CI Fails on Tags > --- > > Key: SLING-11097 > URL: https://issues.apache.org/jira/browse/SLING-11097 > Project: Sling > Issue Type: Improvement >Reporter: Dan Klco >Assignee: Dan Klco >Priority: Major > Fix For: Committer CLI 1.0.0 > > > Currently for most (if not all) releases the Sling Committer CLI fails to > validate the release because the CI check fails. > This is because our Jenkins jobs do not execute on tags and therefore the CI > check doesn't see a success code for the tag commit's build status. > It seems not trivial to add builds on tags to Jenkins (though someone who > knows Jenkins DSL may know better than I) but either way it would seem like a > good idea to check the parent commit's build status if the tag commit does > not have a build status. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-11816) Transliterated project member names break the vote counting algorithm
[ https://issues.apache.org/jira/browse/SLING-11816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu resolved SLING-11816. -- Resolution: Fixed > Transliterated project member names break the vote counting algorithm > - > > Key: SLING-11816 > URL: https://issues.apache.org/jira/browse/SLING-11816 > Project: Sling > Issue Type: Bug > Components: Tooling > Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: Committer CLI 1.0.0 > > > If a project member provides their name using transliterated forms between > Whimsy and their email address, the CLI tool won't be able to correctly > record their names when it comes to counting the votes in a release tally > email. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [VOTE] Release Apache Sling GraphQL Core 0.0.20
+1 > On 31 Mar 2023, at 22:51, Andreas Schaefer wrote: > > 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.
[jira] [Created] (SLING-11816) Transliterated project member names break the vote counting algorithm
Radu Cotescu created SLING-11816: Summary: Transliterated project member names break the vote counting algorithm Key: SLING-11816 URL: https://issues.apache.org/jira/browse/SLING-11816 Project: Sling Issue Type: Bug Components: Tooling Reporter: Radu Cotescu Assignee: Radu Cotescu Fix For: Committer CLI 1.0.0 If a project member provides their name using transliterated forms between Whimsy and their email address, the CLI tool won't be able to correctly record their names when it comes to counting the votes in a release tally email. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [VOTE] Release Apache Sling Models API 1.5.0, Models Implementation 1.6.0
+1 > On 28 Mar 2023, at 13:51, Stefan Seifert > wrote: > > 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.
Re: [VOTE] Release Apache Sling Models API 1.5.0, Models Implementation 1.6.0
Ah, I missed the other thread. Sorry. :)
