[jira] [Resolved] (SLING-12243) Standalone execution of Repoinit statements is not clearly documented

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz resolved SLING-12243.
-
  Assignee: Bertrand Delacretaz
Resolution: Fixed

I have added a "Executing repoinit statements outside of the startup sequence" 
paragraph to 
https://sling.apache.org/documentation/bundles/repository-initialization.html 
that points to the above test.


> Standalone execution of Repoinit statements is not clearly documented
> -
>
> Key: SLING-12243
> URL: https://issues.apache.org/jira/browse/SLING-12243
> Project: Sling
>  Issue Type: Bug
>  Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.46
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Fix For: Repoinit JCR 1.1.48
>
>
> The repoinit documentation at 
> [https://sling.apache.org/documentation/bundles/repository-initialization.html]
>  does not clearly indicate how to execute repoinit statements outside of the 
> repository initialization cycle. The information is present but not obvious.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (SLING-12243) Standalone execution of Repoinit statements is not clearly documented

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz updated SLING-12243:

Fix Version/s: Repoinit JCR 1.1.48

> Standalone execution of Repoinit statements is not clearly documented
> -
>
> Key: SLING-12243
> URL: https://issues.apache.org/jira/browse/SLING-12243
> Project: Sling
>  Issue Type: Bug
>  Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.46
>Reporter: Bertrand Delacretaz
>Priority: Minor
> Fix For: Repoinit JCR 1.1.48
>
>
> The repoinit documentation at 
> [https://sling.apache.org/documentation/bundles/repository-initialization.html]
>  does not clearly indicate how to execute repoinit statements outside of the 
> repository initialization cycle. The information is present but not obvious.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (SLING-12243) Standalone execution of Repoinit statements is not clearly documented

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-12243:
-

Commit 
[https://github.com/apache/sling-org-apache-sling-jcr-repoinit/commit/ae1167a3b789e953234650e6344dbce93103061b]
 adds a test that demonstrates standalone execution of repoinit statements

> Standalone execution of Repoinit statements is not clearly documented
> -
>
> Key: SLING-12243
> URL: https://issues.apache.org/jira/browse/SLING-12243
> Project: Sling
>  Issue Type: Bug
>  Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.46
>Reporter: Bertrand Delacretaz
>Priority: Minor
>
> The repoinit documentation at 
> [https://sling.apache.org/documentation/bundles/repository-initialization.html]
>  does not clearly indicate how to execute repoinit statements outside of the 
> repository initialization cycle. The information is present but not obvious.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (SLING-12243) Standalone execution of Repoinit statements is not clearly documented

[Bertrand Delacretaz (Jira)]

Bertrand Delacretaz created SLING-12243:
---

 Summary: Standalone execution of Repoinit statements is not 
clearly documented
 Key: SLING-12243
 URL: https://issues.apache.org/jira/browse/SLING-12243
 Project: Sling
  Issue Type: Bug
  Components: Repoinit
Affects Versions: Repoinit JCR 1.1.46
Reporter: Bertrand Delacretaz


The repoinit documentation at 
[https://sling.apache.org/documentation/bundles/repository-initialization.html] 
does not clearly indicate how to execute repoinit statements outside of the 
repository initialization cycle. The information is present but not obvious.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (SLING-12198) Extending sling.graphql.engine to allow passing custom graphql ParserOptions while executing GraphQL queries

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz resolved SLING-12198.
-
Resolution: Fixed

Merged, thanks for your contribution!

> 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] [Assigned] (SLING-12198) Extending sling.graphql.engine to allow passing custom graphql ParserOptions while executing GraphQL queries

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz reassigned SLING-12198:
---

Assignee: Bertrand Delacretaz

> 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] [Updated] (SLING-10901) Allow terminating a GraphQL query after a configured timeout

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz updated SLING-10901:

Fix Version/s: GraphQL Core 0.0.30
   (was: GraphQL Core 0.0.28)

> 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.30
>
>
> 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] [Updated] (SLING-12200) sling-org-apache-sling-graphql-core unnecessarily uses the shaded guava from graphql-java

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz updated SLING-12200:

Fix Version/s: GraphQL Core 0.0.28

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

[jira] [Resolved] (SLING-12200) sling-org-apache-sling-graphql-core unnecessarily uses the shaded guava from graphql-java

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz resolved SLING-12200.
-
Resolution: Fixed

PR applied, thanks for your contribution!

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

[jira] [Updated] (SLING-12198) Extending sling.graphql.engine to allow passing custom graphql ParserOptions while executing GraphQL queries

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz updated SLING-12198:

Fix Version/s: GraphQL Core 0.0.28

> 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
>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] [Assigned] (SLING-12200) sling-org-apache-sling-graphql-core unnecessarily uses the shaded guava from graphql-java

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz reassigned SLING-12200:
---

Assignee: Bertrand Delacretaz  (was: Julian Reschke)

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

[jira] [Commented] (SLING-12198) Extending sling.graphql.engine to allow passing custom graphql ParserOptions while executing GraphQL queries

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-12198:
-

I think the use case makes sense, would you be able to provide a patch?

> 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
>Priority: Major
>
> 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] [Resolved] (SLING-12052) Add search function to the Sling website

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz resolved SLING-12052.
-
Resolution: Fixed

Downgrading Node.js to {{v16.6.0}} fixed the GLIBC issue, the searchbox is now 
live.

> Add search function to the Sling website
> 
>
> Key: SLING-12052
> URL: https://issues.apache.org/jira/browse/SLING-12052
> Project: Sling
>  Issue Type: Task
>  Components: Site
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
>
> A site search function would be useful on https://sling.apache.org/
> The https://community.apache.org/ and https://www.apache.org/ websites are 
> successfully using https://pagefind.app/ which is fairly simple to integrate, 
> we might do the same.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (SLING-12052) Add search function to the Sling website

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-12052:
-

I have merged PR #133 but the 
[build|https://ci-builds.apache.org/job/Sling/job/modules/job/sling-site/job/master/]
 fails when trying to run {{npx pagefind}} :
{quote}/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found 
(required by 
/home/jenkins/712657a4/workspace/ling_modules_sling-site_master_2/jdk_11_latest/target/node/node)
{quote}

> Add search function to the Sling website
> 
>
> Key: SLING-12052
> URL: https://issues.apache.org/jira/browse/SLING-12052
> Project: Sling
>  Issue Type: Task
>  Components: Site
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
>
> A site search function would be useful on https://sling.apache.org/
> The https://community.apache.org/ and https://www.apache.org/ websites are 
> successfully using https://pagefind.app/ which is fairly simple to integrate, 
> we might do the same.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (SLING-12052) Add search function to the Sling website

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz reassigned SLING-12052:
---

Assignee: Bertrand Delacretaz

> Add search function to the Sling website
> 
>
> Key: SLING-12052
> URL: https://issues.apache.org/jira/browse/SLING-12052
> Project: Sling
>  Issue Type: Task
>  Components: Site
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
>
> A site search function would be useful on https://sling.apache.org/
> The https://community.apache.org/ and https://www.apache.org/ websites are 
> successfully using https://pagefind.app/ which is fairly simple to integrate, 
> we might do the same.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (SLING-12052) Add search function to the Sling website

[Bertrand Delacretaz (Jira)]

Bertrand Delacretaz created SLING-12052:
---

 Summary: Add search function to the Sling website
 Key: SLING-12052
 URL: https://issues.apache.org/jira/browse/SLING-12052
 Project: Sling
  Issue Type: Task
  Components: Site
Reporter: Bertrand Delacretaz


A site search function would be useful on https://sling.apache.org/

The https://community.apache.org/ and https://www.apache.org/ websites are 
successfully using https://pagefind.app/ which is fairly simple to integrate, 
we might do the same.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (SLING-11736) Create path should potentially adjust the primary type/mixin types of existing paths

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-11736:
-

I won't be able to work on this right now but what you suggest sounds 
reasonable to me. If someone else creates a patch I recommend writing tests 
which clearly demonstrate the changed behavior, as there's a minor risk of 
backwards incompatibility.

> Create path should potentially adjust the primary type/mixin types of 
> existing paths
> 
>
> Key: SLING-11736
> URL: https://issues.apache.org/jira/browse/SLING-11736
> Project: Sling
>  Issue Type: Bug
>  Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.42
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently "create path " is a no-op when the path does already exist 
> (https://github.com/apache/sling-org-apache-sling-jcr-repoinit/blob/9913b787574186a7a31d184480cec3862816438f/src/main/java/org/apache/sling/jcr/repoinit/impl/AclVisitor.java#L191).
>  This is dangerous as then the path might have other primary and mixin types 
> and subsequent calls of "set properties ..." might fail.
> Instead the primary type and mixins should potentially be adjusted on 
> existing nodes as well.
> This happened in 
> https://github.com/adobe/aem-project-archetype/issues/997#issuecomment-1351895791
>  which lead to not starting the repository at all.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (SLING-47) microsling - simple webapp to demonstrate the core principles of Sling

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-47:
--

I'll be mentioning that today in a discussion on the history of Sling - for the 
curious among you, the code is now archived at 
https://svn.apache.org/repos/asf/sling/whiteboard/microsling/

> microsling - simple webapp to demonstrate the core principles of Sling
> --
>
> Key: SLING-47
> URL: https://issues.apache.org/jira/browse/SLING-47
> Project: Sling
>  Issue Type: New Feature
>  Components: Engine
>Reporter: Bertrand Delacretaz
>Priority: Minor
> Attachments: microsling-homepage.html, microsling-homepage.html
>
>
> Following our recent API redesign discussions (see 
> http://cwiki.apache.org/confluence/display/SLING/Sling+API+Redesign in 
> particular), I have started working on "microsling", a webapp that 
> demonstrates my understanding of the "most important parts" of Sling.
> The goal is to create very simple codebase that helps in understanding how 
> Sling processes HTTP requests: the current Sling codebase contains many 
> (useful) things which are not central to Sling's vision, and make it hard to 
> understand what Sling is really about.
> The first version that I'm going to commit to 
> http://svn.apache.org/repos/asf/incubator/sling/whiteboard/microsling is 
> probably not worth looking at in detail, I hope to have a "good enough for 
> review" version in a few days.
> Note that I have not studied Sling's internals in detail - I'm starting from 
> scratch based on my current understanding of how things work. The goal is not 
> to replace any of the Sling's current code, but having a very simple thing to 
> play with will hopefully help us in our simplification efforts.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (SLING-9068) Add more context to ParseException

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-9068:


As per 
https://stackoverflow.com/questions/1564448/format-parseexception-with-javacc 
it looks like we'll need to store a (partial) copy of the input, probably by 
wrapping the input Reader, to be able to recreate the context based on the 
positional information provided by the {{currentToken}} when an Exception is 
thrown.

> Add more context to ParseException
> --
>
> Key: SLING-9068
> URL: https://issues.apache.org/jira/browse/SLING-9068
> Project: Sling
>  Issue Type: Improvement
>  Components: Repoinit
>Affects Versions: Repoinit Parser 1.6.2
>Reporter: Angela Schreiber
>Priority: Minor
>
> today the repo init grammar doesn't come with dedicated exception handing and 
> thus the parser will fail with messages that can make it hard to spot actual 
> problem... specially in a lengthy repo-init as it is present with Adobe AEM. 
> Example:
> {code}
> org.apache.sling.repoinit.parser.impl.ParseException: Encountered " "," ", "" 
> at line 115, column 46.
> Was expecting:
> ")" ...
> 
>   at 
> org.apache.sling.repoinit.parser.impl.RepoInitParserImpl.generateParseException(RepoInitParserImpl.java:3095)
>  [org.apache.sling.repoinit.parser:1.3.2]
> {code}
> if i am not mistaken this should be doable be adding explicit exceptions to 
> the grammar.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Comment Edited] (SLING-9068) Add more context to ParseException

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz edited comment on SLING-9068 at 6/7/22 7:05 AM:


I guess what's needed is to include a relevant excerpt of the failing script in 
the error output, maybe something like

{code}
org.apache.sling.repoinit.parser.impl.ParseException: Encountered " "," ", "" 
at line 115, column 46.
Was expecting:
")" ...

Here's the last few lines, where ===> marks the one that causes the error:
create path /content(sling:OrderedFolder)
112 set ACL for anonymous
113 allow jcr:read on /etc/something
114 allow jcr:read on /etc/somethingelse
115 ===> created pathes /allwrong
 {code}

As mentioned, I haven't looked yet at how to implement this, just meant to 
clarify the requirements.


was (Author: bdelacretaz):
I guess what's needed is to include a relevant excerpt of the failing script in 
the error output, maybe something like

{code}
org.apache.sling.repoinit.parser.impl.ParseException: Encountered " "," ", "" 
at line 115, column 46.
Was expecting:
")" ...

Here's the last few lines, where ===> marks the one that causes the error:
create path /content(sling:OrderedFolder)
set ACL for anonymous
allow jcr:read on /etc/something
allow jcr:read on /etc/somethingelse
===> created pathes /allwrong
 {code}

As mentioned, I haven't looked yet at how to implement this, just meant to 
clarify the requirements.

> Add more context to ParseException
> --
>
> Key: SLING-9068
> URL: https://issues.apache.org/jira/browse/SLING-9068
> Project: Sling
>  Issue Type: Improvement
>  Components: Repoinit
>Affects Versions: Repoinit Parser 1.6.2
>Reporter: Angela Schreiber
>Priority: Minor
>
> today the repo init grammar doesn't come with dedicated exception handing and 
> thus the parser will fail with messages that can make it hard to spot actual 
> problem... specially in a lengthy repo-init as it is present with Adobe AEM. 
> Example:
> {code}
> org.apache.sling.repoinit.parser.impl.ParseException: Encountered " "," ", "" 
> at line 115, column 46.
> Was expecting:
> ")" ...
> 
>   at 
> org.apache.sling.repoinit.parser.impl.RepoInitParserImpl.generateParseException(RepoInitParserImpl.java:3095)
>  [org.apache.sling.repoinit.parser:1.3.2]
> {code}
> if i am not mistaken this should be doable be adding explicit exceptions to 
> the grammar.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (SLING-9068) Add more context to ParseException

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-9068:


I guess what's needed is to include a relevant excerpt of the failing script in 
the error output, maybe something like

{code}
org.apache.sling.repoinit.parser.impl.ParseException: Encountered " "," ", "" 
at line 115, column 46.
Was expecting:
")" ...

Here's the last few lines, where ===> marks the one that causes the error:
create path /content(sling:OrderedFolder)
set ACL for anonymous
allow jcr:read on /etc/something
allow jcr:read on /etc/somethingelse
===> created pathes /allwrong
 {code}

As mentioned, I haven't looked yet at how to implement this, just meant to 
clarify the requirements.

> Add more context to ParseException
> --
>
> Key: SLING-9068
> URL: https://issues.apache.org/jira/browse/SLING-9068
> Project: Sling
>  Issue Type: Improvement
>  Components: Repoinit
>Affects Versions: Repoinit Parser 1.6.2
>Reporter: Angela Schreiber
>Priority: Minor
>
> today the repo init grammar doesn't come with dedicated exception handing and 
> thus the parser will fail with messages that can make it hard to spot actual 
> problem... specially in a lengthy repo-init as it is present with Adobe AEM. 
> Example:
> {code}
> org.apache.sling.repoinit.parser.impl.ParseException: Encountered " "," ", "" 
> at line 115, column 46.
> Was expecting:
> ")" ...
> 
>   at 
> org.apache.sling.repoinit.parser.impl.RepoInitParserImpl.generateParseException(RepoInitParserImpl.java:3095)
>  [org.apache.sling.repoinit.parser:1.3.2]
> {code}
> if i am not mistaken this should be doable be adding explicit exceptions to 
> the grammar.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (SLING-11315) Reject duplicate servlet mount configurations

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-11315:
-

The docs that you mention are about multiple servlets matching the current 
request, which is fine and by design, when multiple servlets with _different 
mount parameters_ match at different levels.

What we're talking about here is multiple servlets registered with the _exact 
same_ mount parameters, like in [my new 
test|https://github.com/apache/sling-org-apache-sling-servlets-resolver/commit/1603a0ecb2ab8b4395560c0d53d9e5569b68a568],
 which I don't think ever makes sense.

> Reject duplicate servlet mount configurations
> -
>
> Key: SLING-11315
> URL: https://issues.apache.org/jira/browse/SLING-11315
> Project: Sling
>  Issue Type: New Feature
>  Components: Servlets
>Reporter: Adrian Kozma
>Priority: Major
>
> Multiple servlets having the same mount parameters should trigger an error.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Comment Edited] (SLING-11315) Reject duplicate servlet mount configurations

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz edited comment on SLING-11315 at 5/11/22 3:14 PM:
--

I have tentatively added [a new 
test|https://github.com/apache/sling-org-apache-sling-servlets-resolver/commit/1603a0ecb2ab8b4395560c0d53d9e5569b68a568]
 to the servlets resolver module to check the current behavior.

Running the test multiple times it looks like it's the first registered servlet 
that wins if two are registered with the same mount parameters.

I'm not sure if that's by design or just by chance, but refusing to register 
the second servlet seems to make more sense to me in such cases. I'll discuss 
[on our dev 
list|https://lists.apache.org/thread/4dgf75dd4sdwyh851ovl7bxfo7wft008].


was (Author: bdelacretaz):
I have tentatively added [a new 
test|https://github.com/apache/sling-org-apache-sling-servlets-resolver/commit/1603a0ecb2ab8b4395560c0d53d9e5569b68a568]
 to the servlets resolver module to check the current behavior.

Running the test multiple times it looks like it's the first registered servlet 
that wins if two are registered with the same mount parameters.

I'm not sure if that's by design or just by chance, but refusing to register 
the second servlet seems to make more sense to me in such cases. I'll discuss 
on our dev list.

> Reject duplicate servlet mount configurations
> -
>
> Key: SLING-11315
> URL: https://issues.apache.org/jira/browse/SLING-11315
> Project: Sling
>  Issue Type: New Feature
>  Components: Servlets
>Reporter: Adrian Kozma
>Priority: Major
>
> Multiple servlets having the same mount parameters should trigger an error.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (SLING-11315) Reject duplicate servlet mount configurations

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-11315:
-

I have tentatively added [a new 
test|https://github.com/apache/sling-org-apache-sling-servlets-resolver/commit/1603a0ecb2ab8b4395560c0d53d9e5569b68a568]
 to the servlets resolver module to check the current behavior.

Running the test multiple times it looks like it's the first registered servlet 
that wins if two are registered with the same mount parameters.

I'm not sure if that's by design or just by chance, but refusing to register 
the second servlet seems to make more sense to me in such cases. I'll discuss 
on our dev list.

> Reject duplicate servlet mount configurations
> -
>
> Key: SLING-11315
> URL: https://issues.apache.org/jira/browse/SLING-11315
> Project: Sling
>  Issue Type: New Feature
>  Components: Servlets
>Reporter: Adrian Kozma
>Priority: Major
>
> Multiple servlets having the same mount parameters should trigger an error.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (SLING-11230) Support Limit and Offset via JcrResourceProvider / findResources

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-11230:
-

Instead of changing the {{{}ResourceResolver{}}}, creating a new query service 
interface the takes a {{ResourceResolver}} as an argument would IMHO be more 
decoupled and modular. IIUC that's the intention of SLING-4752 but I haven't 
looked in detail.

In terms of paginated result sets we have 
[https://github.com/apache/sling-org-apache-sling-graphql-core/tree/master/src/main/java/org/apache/sling/graphql/api/pagination]
 which is based on the [Relay Cursor Connections 
spec|https://relay.dev/graphql/connections.htm]. That spec is meant for GraphQL 
but I think we would use the same principles (and envelope output format maybe) 
for any API, for consistency, if that works for your use cases.

Note that that spec is about cursor-based pagination, as opposed to 
offset-based, and in the GraphQL Core we have only implemented the 
"forward-only, infinite scroll" style. I think that's a good way of preventing 
clients from doing crazy things, and putting the burden on the client if they 
_really_ need back and forth navigation in the results. That can IMHO help 
avoid creating undue load on servers in such cases, and prompt developers to no 
go too far with pagination.

> Support Limit and Offset via JcrResourceProvider / findResources
> 
>
> Key: SLING-11230
> URL: https://issues.apache.org/jira/browse/SLING-11230
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Reporter: Dan Klco
>Assignee: Dan Klco
>Priority: Minor
>
> *Problem Statement*
> In addition to not supporting global limits, there are good reasons that a 
> developer may want to return only a sub-set of the query results when 
> executing a query. For example returning the 10 latest uploaded files. 
> Currently this can be accomplished by executing a query and then only 
> iterating to the 10th item, however a much larger query set may be fetched 
> from the node store than required to service the intended use case. 
> In addition, to support paging, the current implementation would require 
> retrieving and iterating over the Resources until the desired start point is 
> found then reading the subsequent Resources.
> _However_ changing the API contract for the ResourceResolver to either add a 
> new method with the start and limit values would have a non-insignificant 
> ripple effect into the implementations, mocks and providers which would be 
> required to support this new method.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (SLING-11233) Change ACL json structure to be less ambiguous for restrictions

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-11233:
-

>From what you're writing I'm starting to understand that this is an _output_ 
>format. I initially thought it was an _input_ format.

I agree with you that the repoinit syntax is not useful as an output format.

I should have checked earlier, sorry for the noise!

> Change ACL json structure to be less ambiguous for restrictions
> ---
>
> Key: SLING-11233
> URL: https://issues.apache.org/jira/browse/SLING-11233
> Project: Sling
>  Issue Type: Improvement
>Reporter: Eric Norman
>Assignee: Eric Norman
>Priority: Major
> Fix For: JCR Jackrabbit Access Manager 3.0.12
>
>
> The restriction details in the ACL json can be ambiguous in some situations.
> For example, in the example below it is not clear if the "rep:glob" 
> restriction applies to the "jcr:read" privilege or the "rep:write" privilege.
>  
> {code:java}
> {
>   "user1":{
>     "principal":"user1",
>     "granted":[
>       "jcr:read"
>     ],
>     "denied":[
>       "rep:write"
>     ],
>     "order":0,
>     "restrictions":{
>       "rep:glob":"glob1"
>     }
>   }
> } {code}
>  
>  
> Expected:
> The JSON structure of the ACE should be enhanced to make it more clear. 
> For example, replace the "granted/denied/restrictions" items with a 
> "privileges" structure whose items are the granted or denied privileges.  
> Each privilege has a "deny" and/or "grant" child whose value is either true 
> (no restrictions) or an array of restrictions + values.
> For example:
>  
> {code:java}
> {
>   "user1":{
>     "principal":"user1",
>     "order":0,
>     "privileges":{
>       "jcr:read":{
>         "allow":{
>           "rep:glob":"glob1"
>         }
>       },
>       "jcr:readAccessControl":{
>         "allow":{
>           "rep:itemNames":[
>             "name1",
>             "name2"
>           ]
>         }
>       },
>       "rep:write":{
>         "deny":true
>       }
>     }
>   }
> } {code}
> The new format should also be flexible enough to describe a privilege that is 
> granted and denied with different restrictions for each of those states.  
> That scenario is impossible to describe in the old format.
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (SLING-11233) Change ACL json structure to be less ambiguous for restrictions

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-11233:
-

Instead of inventing a new format, would it make sense to allow using the 
[repoinit 
syntax|https://sling.apache.org/documentation/bundles/repository-initialization.html]
 in this module? Assuming that syntax is rich enough for what you want to do, 
and the additional dependencies (repoinit parser + JCR module) are acceptable.

> Change ACL json structure to be less ambiguous for restrictions
> ---
>
> Key: SLING-11233
> URL: https://issues.apache.org/jira/browse/SLING-11233
> Project: Sling
>  Issue Type: Improvement
>Reporter: Eric Norman
>Assignee: Eric Norman
>Priority: Major
> Fix For: JCR Jackrabbit Access Manager 3.0.12
>
>
> The restriction details in the ACL json can be ambiguous in some situations.
> For example, in the example below it is not clear if the "rep:glob" 
> restriction applies to the "jcr:read" privilege or the "rep:write" privilege.
>  
> {code:java}
> {
>   "user1":{
>     "principal":"user1",
>     "granted":[
>       "jcr:read"
>     ],
>     "denied":[
>       "rep:write"
>     ],
>     "order":0,
>     "restrictions":{
>       "rep:glob":"glob1"
>     }
>   }
> } {code}
>  
>  
> Expected:
> The JSON structure of the ACE should be enhanced to make it more clear. 
> For example, replace the "granted/denied/restrictions" items with a 
> "privileges" structure whose items are the granted or denied privileges.  
> Each privilege has a "deny" and/or "grant" child whose value is either true 
> (no restrictions) or an array of restrictions + values.
> For example:
>  
> {code:java}
> {
>   "user1":{
>     "principal":"user1",
>     "order":0,
>     "privileges":{
>       "jcr:read":{
>         "allow":{
>           "rep:glob":"glob1"
>         }
>       },
>       "jcr:readAccessControl":{
>         "allow":{
>           "rep:itemNames":[
>             "name1",
>             "name2"
>           ]
>         }
>       },
>       "rep:write":{
>         "deny":true
>       }
>     }
>   }
> } {code}
> The new format should also be flexible enough to describe a privilege that is 
> granted and denied with different restrictions for each of those states.  
> That scenario is impossible to describe in the old format.
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (SLING-7333) Build fails due to Animal Sniffer

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-7333:


FWIW, 
[https://github.com/apache/sling-org-apache-sling-crankstart-launcher|https://github.com/apache/sling-org-apache-sling-crankstart-launcher]
 has been deprecated in the meantime

> Build fails due to Animal Sniffer
> -
>
> Key: SLING-7333
> URL: https://issues.apache.org/jira/browse/SLING-7333
> Project: Sling
>  Issue Type: Bug
>  Components: Crankstart
>Reporter: Oliver Lietz
>Priority: Major
> Fix For: Crankstart Launcher 2.0.0
>
>
> The build fails due to Animal Sniffer after switching from Apache Parent 10 
> to Sling Parent 32. Skipping Animal Sniffer for now.
> [~bdelacretaz], can you have a look?



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (SLING-11160) Repoinit does not allow to remove individual ACEs

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-11160:
-

I agree with the need to avoid confusion between ACL and ACE - and we probably 
need to add a short section on what those are, or point to existing 
documentation, from 
[https://sling.apache.org/documentation/bundles/repository-initialization.html].
 Basically just explain that an Access Control List is a set of Access Control 
Entries, and repoinit statements act on one or the other.

In terms of implementation, reformulating what [~angela] is suggesting to make 
sure I understand:
 * {{set ACL}} remains unchanged, to add a set of ACEs to a given ACL.
 * {{delete ACL}} remains unchanged, to delete a complete ACL
 * {{remove ACE}} is added, similar to the current pull request but using 
{{ACE}} instead of {{ACL}} in the statement

If my understanding is correct, the above works for me.

> Repoinit does not allow to remove individual ACEs
> -
>
> Key: SLING-11160
> URL: https://issues.apache.org/jira/browse/SLING-11160
> Project: Sling
>  Issue Type: Bug
>  Components: Repoinit
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Major
> Attachments: SLING-11160-initial-draft.patch
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> With SLING-9090 support for using _REMOVE *_ for all entries at a given path 
> or for a given principal has been implemented.
> However as indicated in the same issue the intended usage of _REMOVE 
> some-thing-specific_ is not clear.
> What is therefore missing with repo-init is the ability to remove a single 
> access control entry that matches 
> - prinicipal
> - privileges
> - allow-status
> - single value restriction
> - mv restrictions.
> As far as I can see the biggest issue is the fact that REMOVE vs ALLOW/DENY 
> are mutually exclusive as the other params listed above can be extracted from 
> a given AclLine in combination with the set-ACL statement.
> This could be fixed by adjusting the following parser method
> {code}
> AclLine privilegesLineOperation() :
> {}
> {
> ( 
> { return new AclLine(AclLine.Action.REMOVE); }
> | (  { return new AclLine(AclLine.Action.ALLOW); } )
> | (   { return new AclLine(AclLine.Action.DENY); } )
> ) 
> }
> {code}
> such that
> - REMOVE is optional, followed by 
> - ALLOW or DENY
> The  {{AclLine}} would then need to be slightly adjusted such that REMOVE can 
> be combined with either ALLOW or DENY.
> Otherwise, I don't see how 
> {{AccessControlList.removeAccessControlEntry(AccessControlEntry)}} could be 
> implemented in org.apache.sling.jcr.repoinit for a single ACE.
> Or maybe the intention was something different in the first place?
> [~bdelacretaz], I would appreciate if you had time to comment on this.
> cc: [~kpauls], [~cziegeler]



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (SLING-11160) Repoinit does not allow to remove individual ACEs

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-11160:
-

I agree with your comment on {{remove repository ACL}}, and I think this means 
that the grammar will not simply reproduce all {{set ACL}} constructs as 
{{remove ACL}} ones.

That will make the grammar a bit more complicated but I think that's fine, as 
long as we add all the required test cases to make things clear. And also to 
produce good documentation [on the Sling 
website|https://sling.apache.org/documentation/bundles/repository-initialization.html#appendix-a-repoinit-syntax-parser-test-scenarios-1],
 where the _Repoinit parser test scenarios_ section is generated from the test 
cases.

I also agree with your view on {{remove *}}.

> Repoinit does not allow to remove individual ACEs
> -
>
> Key: SLING-11160
> URL: https://issues.apache.org/jira/browse/SLING-11160
> Project: Sling
>  Issue Type: Bug
>  Components: Repoinit
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Major
> Attachments: SLING-11160-initial-draft.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> With SLING-9090 support for using _REMOVE *_ for all entries at a given path 
> or for a given principal has been implemented.
> However as indicated in the same issue the intended usage of _REMOVE 
> some-thing-specific_ is not clear.
> What is therefore missing with repo-init is the ability to remove a single 
> access control entry that matches 
> - prinicipal
> - privileges
> - allow-status
> - single value restriction
> - mv restrictions.
> As far as I can see the biggest issue is the fact that REMOVE vs ALLOW/DENY 
> are mutually exclusive as the other params listed above can be extracted from 
> a given AclLine in combination with the set-ACL statement.
> This could be fixed by adjusting the following parser method
> {code}
> AclLine privilegesLineOperation() :
> {}
> {
> ( 
> { return new AclLine(AclLine.Action.REMOVE); }
> | (  { return new AclLine(AclLine.Action.ALLOW); } )
> | (   { return new AclLine(AclLine.Action.DENY); } )
> ) 
> }
> {code}
> such that
> - REMOVE is optional, followed by 
> - ALLOW or DENY
> The  {{AclLine}} would then need to be slightly adjusted such that REMOVE can 
> be combined with either ALLOW or DENY.
> Otherwise, I don't see how 
> {{AccessControlList.removeAccessControlEntry(AccessControlEntry)}} could be 
> implemented in org.apache.sling.jcr.repoinit for a single ACE.
> Or maybe the intention was something different in the first place?
> [~bdelacretaz], I would appreciate if you had time to comment on this.
> cc: [~kpauls], [~cziegeler]



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Comment Edited] (SLING-11160) Repoinit does not allow to remove individual ACEs

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz edited comment on SLING-11160 at 2/28/22, 2:36 PM:
---

The more I look at this the more I think having a "remove" statement in "set 
ACL" is a design mistake (which I'm probably responsible for).

It naturally leads to the "remove allow" and "remove deny" statements that you 
are suggesting, which do not look natural nor obvious.

I think we should rather introduce a new top-level REMOVE ACL statement as in 
the examples below.

Basically, reproducing the "set ACL" statements with "remove ACL" for removal.

And maybe deprecate the existing {{{}remove *{}}}, or allow it only in {{remove 
ACL}} statements.

Not sure if we need all the below variants for now, we can also introduce just 
the ones that are needed now.

WDYT?
{code:java}
remove ACL on /someting
   allow jcr:read for userA,userB
end

remove repository ACL for user1,user2
allow jcr:read,jcr:lockManagement
deny jcr:write
end

remove ACL for user1,u2
allow jcr:read on /content
deny jcr:write on /apps
end

remove principal ACL for principal1,principal2
# this was "remove *" so far in "set ACL"
* on /libs,/apps
allow jcr:read on /content
{code}


was (Author: bdelacretaz):
The more I look at this the more I think having a "remove" statement in "set 
ACL" is a design mistake (which I'm probably responsible for).

It naturally leads to the "remove allow" and "remove deny" statements that you 
are suggesting, which do not look natural nor obvious.

I think we should rather introduce a new top-level REMOVE ACL statement as in 
the examples below. 

Basically, reproducing the "set ACL" statements with "remove ACL" for removal.

And maybe deprecate the existing "remove *", or allow it only in "remove ACL" 
statements.

Not sure if we need all the below variants for now, we can also introduce just 
the ones that are needed now.

WDYT?

{code}
remove ACL on /someting
   allow jcr:read for userA,userB
end

remove repository ACL for user1,user2
allow jcr:read,jcr:lockManagement
deny jcr:write
end

remove ACL for user1,u2
allow jcr:read on /content
deny jcr:write on /apps
end

remove principal ACL for principal1,principal2
# this was "remove *" so far in "set ACL"
* on /libs,/apps
allow jcr:read on /content
{code}

> Repoinit does not allow to remove individual ACEs
> -
>
> Key: SLING-11160
> URL: https://issues.apache.org/jira/browse/SLING-11160
> Project: Sling
>  Issue Type: Bug
>  Components: Repoinit
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Major
> Attachments: SLING-11160-initial-draft.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> With SLING-9090 support for using _REMOVE *_ for all entries at a given path 
> or for a given principal has been implemented.
> However as indicated in the same issue the intended usage of _REMOVE 
> some-thing-specific_ is not clear.
> What is therefore missing with repo-init is the ability to remove a single 
> access control entry that matches 
> - prinicipal
> - privileges
> - allow-status
> - single value restriction
> - mv restrictions.
> As far as I can see the biggest issue is the fact that REMOVE vs ALLOW/DENY 
> are mutually exclusive as the other params listed above can be extracted from 
> a given AclLine in combination with the set-ACL statement.
> This could be fixed by adjusting the following parser method
> {code}
> AclLine privilegesLineOperation() :
> {}
> {
> ( 
> { return new AclLine(AclLine.Action.REMOVE); }
> | (  { return new AclLine(AclLine.Action.ALLOW); } )
> | (   { return new AclLine(AclLine.Action.DENY); } )
> ) 
> }
> {code}
> such that
> - REMOVE is optional, followed by 
> - ALLOW or DENY
> The  {{AclLine}} would then need to be slightly adjusted such that REMOVE can 
> be combined with either ALLOW or DENY.
> Otherwise, I don't see how 
> {{AccessControlList.removeAccessControlEntry(AccessControlEntry)}} could be 
> implemented in org.apache.sling.jcr.repoinit for a single ACE.
> Or maybe the intention was something different in the first place?
> [~bdelacretaz], I would appreciate if you had time to comment on this.
> cc: [~kpauls], [~cziegeler]



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Comment Edited] (SLING-11160) Repoinit does not allow to remove individual ACEs

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz edited comment on SLING-11160 at 2/28/22, 11:53 AM:


The more I look at this the more I think having a "remove" statement in "set 
ACL" is a design mistake (which I'm probably responsible for).

It naturally leads to the "remove allow" and "remove deny" statements that you 
are suggesting, which do not look natural nor obvious.

I think we should rather introduce a new top-level REMOVE ACL statement as in 
the examples below. 

Basically, reproducing the "set ACL" statements with "remove ACL" for removal.

And maybe deprecate the existing "remove *", or allow it only in "remove ACL" 
statements.

Not sure if we need all the below variants for now, we can also introduce just 
the ones that are needed now.

WDYT?

{code}
remove ACL on /someting
   allow jcr:read for userA,userB
end

remove repository ACL for user1,user2
allow jcr:read,jcr:lockManagement
deny jcr:write
end

remove ACL for user1,u2
allow jcr:read on /content
deny jcr:write on /apps
end

remove principal ACL for principal1,principal2
# this was "remove *" so far in "set ACL"
* on /libs,/apps
allow jcr:read on /content
{code}


was (Author: bdelacretaz):
The more I look at this the more I think having a "remove" statement in "set 
ACL" is a design mistake (which I'm probably responsible for).

It naturally leads to the "remove allow" and "remove deny" statements that you 
are suggesting, which do not look natural nor obvious.

I think we should rather introduce a new top-level REMOVE ACL statement as in 
the examples below. 

Basically, reproducing the "set ACL" statements with "remove ACL" for removal.

And maybe deprecate the existing "remove *", or allow it only in "remove ACL" 
statements.

Not sure if we need all the below variants for now, we can also introduce just 
the ones that are needed now.

WDYT?

{code}
remove ACL on /someting
   allow jcr:read for userA,userB
end

remove repository ACL for user1,user2
allow jcr:read,jcr:lockManagement
deny jcr:write
end

remove ACL for user1,u2
allow jcr:read on /content
deny jcr:write on /apps
end

remove principal ACL for principal1,principal2
remove * on /libs,/apps
allow jcr:read on /content
{code}

> Repoinit does not allow to remove individual ACEs
> -
>
> Key: SLING-11160
> URL: https://issues.apache.org/jira/browse/SLING-11160
> Project: Sling
>  Issue Type: Bug
>  Components: Repoinit
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Major
> Attachments: SLING-11160-initial-draft.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> With SLING-9090 support for using _REMOVE *_ for all entries at a given path 
> or for a given principal has been implemented.
> However as indicated in the same issue the intended usage of _REMOVE 
> some-thing-specific_ is not clear.
> What is therefore missing with repo-init is the ability to remove a single 
> access control entry that matches 
> - prinicipal
> - privileges
> - allow-status
> - single value restriction
> - mv restrictions.
> As far as I can see the biggest issue is the fact that REMOVE vs ALLOW/DENY 
> are mutually exclusive as the other params listed above can be extracted from 
> a given AclLine in combination with the set-ACL statement.
> This could be fixed by adjusting the following parser method
> {code}
> AclLine privilegesLineOperation() :
> {}
> {
> ( 
> { return new AclLine(AclLine.Action.REMOVE); }
> | (  { return new AclLine(AclLine.Action.ALLOW); } )
> | (   { return new AclLine(AclLine.Action.DENY); } )
> ) 
> }
> {code}
> such that
> - REMOVE is optional, followed by 
> - ALLOW or DENY
> The  {{AclLine}} would then need to be slightly adjusted such that REMOVE can 
> be combined with either ALLOW or DENY.
> Otherwise, I don't see how 
> {{AccessControlList.removeAccessControlEntry(AccessControlEntry)}} could be 
> implemented in org.apache.sling.jcr.repoinit for a single ACE.
> Or maybe the intention was something different in the first place?
> [~bdelacretaz], I would appreciate if you had time to comment on this.
> cc: [~kpauls], [~cziegeler]



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (SLING-11160) Repoinit does not allow to remove individual ACEs

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-11160:
-

The more I look at this the more I think having a "remove" statement in "set 
ACL" is a design mistake (which I'm probably responsible for).

It naturally leads to the "remove allow" and "remove deny" statements that you 
are suggesting, which do not look natural nor obvious.

I think we should rather introduce a new top-level REMOVE ACL statement as in 
the examples below. 

Basically, reproducing the "set ACL" statements with "remove ACL" for removal.

And maybe deprecate the existing "remove *", or allow it only in "remove ACL" 
statements.

Not sure if we need all the below variants for now, we can also introduce just 
the ones that are needed now.

WDYT?

{code}
remove ACL on /someting
   allow jcr:read for userA,userB
end

remove repository ACL for user1,user2
allow jcr:read,jcr:lockManagement
deny jcr:write
end

remove ACL for user1,u2
allow jcr:read on /content
deny jcr:write on /apps
end

remove principal ACL for principal1,principal2
remove * on /libs,/apps
allow jcr:read on /content
{code}

> Repoinit does not allow to remove individual ACEs
> -
>
> Key: SLING-11160
> URL: https://issues.apache.org/jira/browse/SLING-11160
> Project: Sling
>  Issue Type: Bug
>  Components: Repoinit
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Major
> Attachments: SLING-11160-initial-draft.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> With SLING-9090 support for using _REMOVE *_ for all entries at a given path 
> or for a given principal has been implemented.
> However as indicated in the same issue the intended usage of _REMOVE 
> some-thing-specific_ is not clear.
> What is therefore missing with repo-init is the ability to remove a single 
> access control entry that matches 
> - prinicipal
> - privileges
> - allow-status
> - single value restriction
> - mv restrictions.
> As far as I can see the biggest issue is the fact that REMOVE vs ALLOW/DENY 
> are mutually exclusive as the other params listed above can be extracted from 
> a given AclLine in combination with the set-ACL statement.
> This could be fixed by adjusting the following parser method
> {code}
> AclLine privilegesLineOperation() :
> {}
> {
> ( 
> { return new AclLine(AclLine.Action.REMOVE); }
> | (  { return new AclLine(AclLine.Action.ALLOW); } )
> | (   { return new AclLine(AclLine.Action.DENY); } )
> ) 
> }
> {code}
> such that
> - REMOVE is optional, followed by 
> - ALLOW or DENY
> The  {{AclLine}} would then need to be slightly adjusted such that REMOVE can 
> be combined with either ALLOW or DENY.
> Otherwise, I don't see how 
> {{AccessControlList.removeAccessControlEntry(AccessControlEntry)}} could be 
> implemented in org.apache.sling.jcr.repoinit for a single ACE.
> Or maybe the intention was something different in the first place?
> [~bdelacretaz], I would appreciate if you had time to comment on this.
> cc: [~kpauls], [~cziegeler]



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (SLING-10955) RepoInit documentation contains confusing example for single-valued rep:glob restriction

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-10955:
-

Thanks for mentioning that, I wasn't aware of this {{rep:glob}} constraint.

IIUC, replacing {{rep:glob}} by {{example:restriction}} in these tests would 
fix this?

The examples on the docs page are now generated from [the test 
scenarios|https://github.com/apache/sling-org-apache-sling-repoinit-parser/tree/master/src/test/resources/testcases]
 - but changing those is not a problem.

> RepoInit documentation contains confusing example for single-valued rep:glob 
> restriction
> 
>
> Key: SLING-10955
> URL: https://issues.apache.org/jira/browse/SLING-10955
> Project: Sling
>  Issue Type: Bug
>  Components: Repoinit
>Reporter: Angela Schreiber
>Priority: Major
>
> [~bdelacretaz], just came across the following examples on the documentation 
> page for the Sling RepoInit feature at 
> https://sling.apache.org/documentation/bundles/repository-initialization.html
> {code}
> # restrictions with glob patterns
> allow jcr:addChildNodes on /apps,/content 
> restriction(rep:glob,/cat,/cat/,cat)
> allow jcr:addChildNodes on /apps,/content 
> restriction(rep:glob,cat/,*,*cat)
> allow jcr:addChildNodes on /apps,/content 
> restriction(rep:glob,/cat/*,*/cat,*cat/*)
> {code}
> the {{rep:glob}} restriction defined with Jackrabbit Oak is single-valued :)
> while i admit that this could just be viewed as a random, the fact that there 
> is an restriction with the given name, might create a false impression and 
> consumers of the documentation might actually believe this is valid. 
> i would suggest to either use an arbitrary restriction name or if using 
> rep:glob change the examples such that they would actually work in a setup 
> based on Jackrabbit



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (SLING-7231) Move to owasp sanitizer library

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-7231:


Looking at the test coverage (build with {{-P jacoco-report}} and look at 
{{target/site/jacoco-merged/index.html}} it seems like some of the 
{{org.apache.sling.xss.impl}} code is not tested, especially the 
{{XSSFilterImpl}} where the {{check}} method and a number of error cases are 
not tested.

I think at least the {{check}} method, being part of the public API, deserves 
to have tests added before making extensive changes to this module. The error 
cases might not be relevant anymore depending on how much the implementation 
changes.

> Move to owasp sanitizer library
> ---
>
> Key: SLING-7231
> URL: https://issues.apache.org/jira/browse/SLING-7231
> Project: Sling
>  Issue Type: Improvement
>  Components: XSS Protection API
>Reporter: Carsten Ziegeler
>Assignee: Tatyana
>Priority: Critical
>  Labels: gsoc2018, java, mentor
>
> While looking at the extensive dependency list of the XSS module (which are 
> all caused by the embedded owasp.org artifacts), I found out that the 
> versions we use are outdated.
> So I think we should update those to the latest.
> Furthermore, the embedded antisamy library does not look to be maintained 
> anymore
> (https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project)
> instead the html sanitizer looks much fresher and claims to be faster
> https://www.owasp.org/index.php/OWASP_Java_HTML_Sanitizer_Project
> I think we should switch. Quick analysis:
> Pros:
> Actively maintained
> Much faster
> Lightweight (also from a dependency POV)
> Cons:
> Incompatible (and runtime-object based) configuration
> Not completely feature equivalent (but close enough and better in some 
> aspects)
> Some investigation is needed on how
> a) filter rules can be configured (e.g. sling configurations, file based, 
> code bundle, ... ?)
> b) existing configurations can be migrated 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (SLING-10740) Repoinit create path statement fails for node types with a mandatory property

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-10740:
-

bq. ...the proposal outlined by Bertrand Delacretaz, which would allow to set 
props for random paths looks a bit odd to me.

It's not meant for setting props on random paths...the example above is a 
single path {{/var/discovery(nt:unstructured)/somefolder}} which is created and 
on which properties are set. I included nodetype parentheses in the example to 
make it clear that that syntax shouldn't change.

> Repoinit create path statement fails for node types with a mandatory property
> -
>
> Key: SLING-10740
> URL: https://issues.apache.org/jira/browse/SLING-10740
> Project: Sling
>  Issue Type: Bug
>  Components: Repoinit
>Reporter: Eric Norman
>Assignee: Eric Norman
>Priority: Major
> Fix For: Repoinit JCR 1.1.38
>
>
> The processing of the "create path" statement calls save() at the end which 
> will cause a constraint violation if the nodetype of the created path 
> contains any properties that are declared as mandatory (and not autocreated). 
>  No processing of "set properties" statements happens before the save() call 
> in AclVisitor#visitCreatePath so it does not seem to be possible to define 
> any mandatory properties using the current repoinit grammar.
> I could see this solved in a couple ways:
>  # The AclVisitor#visitCreatePath could possibly pre-process any "set 
> properties" statements that are applicable to the created path before calling 
> save and then skip those same items when NodePropertiesVisitor visits the 
> same.
>  # Or, the "create path" grammar could be extended to allow defining 
> properties to be set at the same time as the create (with a syntax that is 
> similar to the "set properties" statement?)
>  # Or, perhaps calling save in AclVisitor#visitCreatePath is not necessary?  
> I'm not sure of the historical reasons why save() is done there.
>  # Or, maybe something else I haven't thought of
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SLING-10740) Repoinit create path statement fails for node types with a mandatory property

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-10740:
-

{quote}...we might need to review that and optimize to call save() only where 
really needed.
{quote}
In the meantime I ran [some experiments with large numbers of repoinit 
statements|https://gist.github.com/bdelacretaz/5ece181782206c0c9f820a78e6baaeef],
 and not calling save() at all might be problematic in such cases, in terms of 
performance. I _think_ if the Oak transient space gets too big that can be 
problematic - but I'm not sure.

This speaks for the second option that you suggested, extending the {{create 
path}} syntax to allow for setting properties.

As create path accepts a single path I think the following syntax will work for 
that:
{code:java}
create path (sling:Folder) /var/discovery(nt:unstructured)/somefolder with 
properties
  # same syntax as "set properties", and use the same code to set them
  # (maybe simply generate two Operations and make sure there's no save() in 
between?)
  set sling:ResourceType{String} to /x/y/z
  set cq:allowedTemplates to /d/e/f/*, m/n/*
  default someInteger{Long} to 42
end
{code}
That doesn't preclude removing any extraneous save() calls, but I think this 
solution is cleaner and also better in terms of keeping things together.

> Repoinit create path statement fails for node types with a mandatory property
> -
>
> Key: SLING-10740
> URL: https://issues.apache.org/jira/browse/SLING-10740
> Project: Sling
>  Issue Type: Bug
>  Components: Repoinit
>Reporter: Eric Norman
>Assignee: Eric Norman
>Priority: Major
> Fix For: Repoinit JCR 1.1.38
>
>
> The processing of the "create path" statement calls save() at the end which 
> will cause a constraint violation if the nodetype of the created path 
> contains any properties that are declared as mandatory (and not autocreated). 
>  No processing of "set properties" statements happens before the save() call 
> in AclVisitor#visitCreatePath so it does not seem to be possible to define 
> any mandatory properties using the current repoinit grammar.
> I could see this solved in a couple ways:
>  # The AclVisitor#visitCreatePath could possibly pre-process any "set 
> properties" statements that are applicable to the created path before calling 
> save and then skip those same items when NodePropertiesVisitor visits the 
> same.
>  # Or, the "create path" grammar could be extended to allow defining 
> properties to be set at the same time as the create (with a syntax that is 
> similar to the "set properties" statement?)
>  # Or, perhaps calling save in AclVisitor#visitCreatePath is not necessary?  
> I'm not sure of the historical reasons why save() is done there.
>  # Or, maybe something else I haven't thought of
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SLING-10840) Sling Servlet Helpers implements @ProviderType interfaces

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-10840:
-

FWIW you can see an example of the GraphQL core making an internal request to 
get a schema for the current request using an internal request [in the 
DefaultSchemaProvider 
class|https://github.com/apache/sling-org-apache-sling-graphql-core/blob/1ea954e36e626d0c89ddc93655d71b9300f26e88/src/main/java/org/apache/sling/graphql/core/schema/DefaultSchemaProvider.java#L55].

> Sling Servlet Helpers implements @ProviderType interfaces
> -
>
> Key: SLING-10840
> URL: https://issues.apache.org/jira/browse/SLING-10840
> Project: Sling
>  Issue Type: Bug
>  Components: General
>Affects Versions: Servlet Helpers 1.4.2
>Reporter: David Gonzalez
>Priority: Major
>
> When using the Sling Servlet Helpers bundle/API, code quality scans detect 
> that implentations in the Sling Servlet Helpers bundle implement 
> @ProviderType interfaces from OTHER Sling bundles, which is not correct. Here 
> are some fo the examples (though probably not exhaustive) I found when 
> attempting to use ths Servlet Helpers library.
>  
> |The product interface org.apache.sling.api.request.RequestParameter 
> annotated with @ProviderType should not be implemented by custom code. 
> Detected in org.apache.sling.servlethelpers.MockRequestParameter contained in 
> /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.|
> |The product interface org.apache.sling.api.request.RequestParameterMap 
> annotated with @ProviderType should not be implemented by custom code. 
> Detected in org.apache.sling.servlethelpers.MockRequestParameterMap contained 
> in 
> /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.|
> |The product interface org.apache.sling.api.request.RequestPathInfo annotated 
> with @ProviderType should not be implemented by custom code. Detected in 
> org.apache.sling.servlethelpers.MockRequestPathInfo contained in 
> /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.|
> |The product interface org.apache.sling.api.request.RequestProgressTracker 
> annotated with @ProviderType should not be implemented by custom code. 
> Detected in org.apache.sling.servlethelpers.MockRequestProgressTracker 
> contained in 
> /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.|
> |The product interface org.apache.sling.api.SlingHttpServletRequest annotated 
> with @ProviderType should not be implemented by custom code. Detected in 
> org.apache.sling.servlethelpers.MockSlingHttpServletRequest contained in 
> /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.|
> |The product interface org.apache.sling.api.SlingHttpServletResponse 
> annotated with @ProviderType should not be implemented by custom code. 
> Detected in org.apache.sling.servlethelpers.MockSlingHttpServletResponse 
> contained in 
> /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.|
> |The product interface org.apache.sling.api.resource.Resource annotated with 
> @ProviderType should not be implemented by custom code. Detected in 
> org.apache.sling.servlethelpers.internalrequests.ServletResolutionResource 
> contained in 
> /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.|
> Perhaps there needs to be Wrappers for all these classes that are 
> @ConsumerTypes?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (SLING-10840) Sling Servlet Helpers implements @ProviderType interfaces

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz edited comment on SLING-10840 at 9/29/21, 7:32 AM:
---

As stated in the docs at 
[https://sling.apache.org/documentation/bundles/servlet-helpers.html] I think 
one good reason to use the servlet helpers bundle in production is the 
{{SlingInternalRequest}} and {{ServletInternalRequest}} helpers, which make 
internal requests simple and clean. The {{org.apache.sling.graphql.core}} 
bundle for example uses them.

I think these services correctly hide their implementation details, returning a 
{{SlingHttpServletResponse}} for example, so changing the underlying 
request/response objects should be possible if needed.

Maybe these services should have been implemented in a different bundle which 
only exports the package that allows using them. The servlets helpers bundle 
also exports the {{org.apache.sling.servlethelpers}} package, which IIUC 
contains the problematic classes discussed here.


was (Author: bdelacretaz):
As stated in the docs at 
[https://sling.apache.org/documentation/bundles/servlet-helpers.html] I think 
one good reason to use the servlet helpers bundle in production is the 
{{SlingInternalRequest}} and {{ServletInternalRequest}} helpers, which make 
internal requests simple and clean.

I think these services correctly hide their implementation details, returning a 
{{SlingHttpServletResponse}} for example, so changing the underlying 
request/response objects should be possible if needed.

Maybe these services should have been implemented in a different bundle which 
only exports the package that allows using them. The servlets helpers bundle 
also exports the {{org.apache.sling.servlethelpers}} package, which IIUC 
contains the problematic classes discussed here.

> Sling Servlet Helpers implements @ProviderType interfaces
> -
>
> Key: SLING-10840
> URL: https://issues.apache.org/jira/browse/SLING-10840
> Project: Sling
>  Issue Type: Bug
>  Components: General
>Affects Versions: Servlet Helpers 1.4.2
>Reporter: David Gonzalez
>Priority: Major
>
> When using the Sling Servlet Helpers bundle/API, code quality scans detect 
> that implentations in the Sling Servlet Helpers bundle implement 
> @ProviderType interfaces from OTHER Sling bundles, which is not correct. Here 
> are some fo the examples (though probably not exhaustive) I found when 
> attempting to use ths Servlet Helpers library.
>  
> |The product interface org.apache.sling.api.request.RequestParameter 
> annotated with @ProviderType should not be implemented by custom code. 
> Detected in org.apache.sling.servlethelpers.MockRequestParameter contained in 
> /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.|
> |The product interface org.apache.sling.api.request.RequestParameterMap 
> annotated with @ProviderType should not be implemented by custom code. 
> Detected in org.apache.sling.servlethelpers.MockRequestParameterMap contained 
> in 
> /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.|
> |The product interface org.apache.sling.api.request.RequestPathInfo annotated 
> with @ProviderType should not be implemented by custom code. Detected in 
> org.apache.sling.servlethelpers.MockRequestPathInfo contained in 
> /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.|
> |The product interface org.apache.sling.api.request.RequestProgressTracker 
> annotated with @ProviderType should not be implemented by custom code. 
> Detected in org.apache.sling.servlethelpers.MockRequestProgressTracker 
> contained in 
> /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.|
> |The product interface org.apache.sling.api.SlingHttpServletRequest annotated 
> with @ProviderType should not be implemented by custom code. Detected in 
> org.apache.sling.servlethelpers.MockSlingHttpServletRequest contained in 
> /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.|
> |The product interface org.apache.sling.api.SlingHttpServletResponse 
> annotated with @ProviderType should not be implemented by custom code. 
> Detected in org.apache.sling.servlethelpers.MockSlingHttpServletResponse 
> contained in 
> /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.|
> |The product interface org.apache.sling.api.resource.Resource annotated with 
> @ProviderType should not be implemented by custom code. Detected in 
> 

[jira] [Commented] (SLING-10840) Sling Servlet Helpers implements @ProviderType interfaces

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-10840:
-

As stated in the docs at 
[https://sling.apache.org/documentation/bundles/servlet-helpers.html] I think 
one good reason to use the servlet helpers bundle in production is the 
{{SlingInternalRequest}} and {{ServletInternalRequest}} helpers, which make 
internal requests simple and clean.

I think these services correctly hide their implementation details, returning a 
{{SlingHttpServletResponse}} for example, so changing the underlying 
request/response objects should be possible if needed.

Maybe these services should have been implemented in a different bundle which 
only exports the package that allows using them. The servlets helpers bundle 
also exports the {{org.apache.sling.servlethelpers}} package, which IIUC 
contains the problematic classes discussed here.

> Sling Servlet Helpers implements @ProviderType interfaces
> -
>
> Key: SLING-10840
> URL: https://issues.apache.org/jira/browse/SLING-10840
> Project: Sling
>  Issue Type: Bug
>  Components: General
>Affects Versions: Servlet Helpers 1.4.2
>Reporter: David Gonzalez
>Priority: Major
>
> When using the Sling Servlet Helpers bundle/API, code quality scans detect 
> that implentations in the Sling Servlet Helpers bundle implement 
> @ProviderType interfaces from OTHER Sling bundles, which is not correct. Here 
> are some fo the examples (though probably not exhaustive) I found when 
> attempting to use ths Servlet Helpers library.
>  
> |The product interface org.apache.sling.api.request.RequestParameter 
> annotated with @ProviderType should not be implemented by custom code. 
> Detected in org.apache.sling.servlethelpers.MockRequestParameter contained in 
> /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.|
> |The product interface org.apache.sling.api.request.RequestParameterMap 
> annotated with @ProviderType should not be implemented by custom code. 
> Detected in org.apache.sling.servlethelpers.MockRequestParameterMap contained 
> in 
> /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.|
> |The product interface org.apache.sling.api.request.RequestPathInfo annotated 
> with @ProviderType should not be implemented by custom code. Detected in 
> org.apache.sling.servlethelpers.MockRequestPathInfo contained in 
> /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.|
> |The product interface org.apache.sling.api.request.RequestProgressTracker 
> annotated with @ProviderType should not be implemented by custom code. 
> Detected in org.apache.sling.servlethelpers.MockRequestProgressTracker 
> contained in 
> /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.|
> |The product interface org.apache.sling.api.SlingHttpServletRequest annotated 
> with @ProviderType should not be implemented by custom code. Detected in 
> org.apache.sling.servlethelpers.MockSlingHttpServletRequest contained in 
> /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.|
> |The product interface org.apache.sling.api.SlingHttpServletResponse 
> annotated with @ProviderType should not be implemented by custom code. 
> Detected in org.apache.sling.servlethelpers.MockSlingHttpServletResponse 
> contained in 
> /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.|
> |The product interface org.apache.sling.api.resource.Resource annotated with 
> @ProviderType should not be implemented by custom code. Detected in 
> org.apache.sling.servlethelpers.internalrequests.ServletResolutionResource 
> contained in 
> /apps/asset-share-commons-vendor-packages/application/install/org.apache.sling.servlet-helpers-1.4.2.jar.|
> Perhaps there needs to be Wrappers for all these classes that are 
> @ConsumerTypes?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (SLING-10810) new status code should not be set if response is already committed

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz updated SLING-10810:

Summary: new status code should not be set if response is already committed 
 (was: new status code should not be set if response is already comitted)

> new status code should not be set if response is already committed
> --
>
> Key: SLING-10810
> URL: https://issues.apache.org/jira/browse/SLING-10810
> Project: Sling
>  Issue Type: Improvement
>  Components: Engine
>Affects Versions: Engine 2.7.8
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: Engine 2.7.10
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> If the response is already committed, a new response should not be set, but 
> it should only be warned.
> Otherwise the status code logged in the Sling instance will taken from the 
> ResponseImpl object, which is different from the statuscode which is sent to 
> the client.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SLING-8909) Create docker image in hub.docker.com

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-8909:


FWIW there's a recent [related discussion on 
builds@a.o|https://lists.apache.org/thread.html/r531e870de4d457659c92042c9930b0423fa864dc0990396f4990e58e%40%3Cbuilds.apache.org%3E]

> Create docker image in hub.docker.com
> -
>
> Key: SLING-8909
> URL: https://issues.apache.org/jira/browse/SLING-8909
> Project: Sling
>  Issue Type: Improvement
>  Components: App CMS
>Reporter: Max Barrass
>Priority: Minor
>  Labels: newbie
>
> To allow rapid testing and evaluation of the App CMS and its components 
> having a accessible docker image hosted in hub.docker.com would provide a 
> method for public access and testing of the app.
>  
> This would require to create a Dockerfile that can create a docker image.
> Update pipeline to publish Docker image to hub.docker.com



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (SLING-9173) Add KEYS file to https://dist.apache.org/repos/dist/release/sling

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz edited comment on SLING-9173 at 9/15/21, 9:28 AM:
--

Not sure if that's what you are asking, but the following works for me: first 
failing, then importing a key from that KEYS file and then succeeding.

The {{--no-default-keyring --keyring /tmp/kr}} options are meant to ignore my 
default keyring, for this example, you usually do not need them.

The "not certified with a trusted signature" bit means we don't know whether 
that key actually belongs to Justin, which is the case for all keys which do 
not have a web of trust connection to the key of the current user. But GPG did 
verify that the signature matches the jar file.
{code:java}
$ wget 
https://dist.apache.org/repos/dist/release/sling/adapter-annotations-1.0.0-javadoc.jar
$ wget 
https://dist.apache.org/repos/dist/release/sling/adapter-annotations-1.0.0-javadoc.jar.asc

$ gpg --no-default-keyring --keyring /tmp/kr --verify 
adapter-annotations-1.0.0-javadoc.jar.asc 
gpg: assuming signed data in 'adapter-annotations-1.0.0-javadoc.jar'
gpg: Signature made Thu Jan 12 17:53:23 2012 CET
gpg:using DSA key 87DBF05A134B145C
gpg: Can't check signature: No public key

$ curl -s https://downloads.apache.org/sling/KEYS | gpg --no-default-keyring 
--keyring /tmp/kr --import
...
gpg: Total number processed: 38
gpg:   imported: 38

$ gpg --no-default-keyring --keyring /tmp/kr --verify 
adapter-annotations-1.0.0-javadoc.jar.asc 
gpg: assuming signed data in 'adapter-annotations-1.0.0-javadoc.jar'
gpg: Signature made Thu Jan 12 17:53:23 2012 CET
gpg:using DSA key 87DBF05A134B145C
gpg: Good signature from "Justin Edelson (CODE SIGNING KEY) 
" [unknown]
gpg: aka "Justin Edelson " [unknown]
gpg: aka "Justin Edelson " [unknown]
gpg: aka "Justin Edelson " 
[unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: A04B C4AD 3639 6AD5 A52C  8FE1 87DB F05A 134B 145C

 {code}
 


was (Author: bdelacretaz):
Not sure if that's what you are asking, but the following works for me: first 
failing, then importing a key from that KEYS file and then succeeding.

The {{--no-default-keyring --keyring /tmp/kr}} options are meant to ignore my 
default keyring, for this example, you usually do not need them.

The "not certified with a trusted signature" bit means we don't know whether 
that key actually belongs to Justin, which is the case for all keys which do 
not have a web of trust connection to the key of the current user.
{code:java}
$ wget 
https://dist.apache.org/repos/dist/release/sling/adapter-annotations-1.0.0-javadoc.jar
$ wget 
https://dist.apache.org/repos/dist/release/sling/adapter-annotations-1.0.0-javadoc.jar.asc

$ gpg --no-default-keyring --keyring /tmp/kr --verify 
adapter-annotations-1.0.0-javadoc.jar.asc 
gpg: assuming signed data in 'adapter-annotations-1.0.0-javadoc.jar'
gpg: Signature made Thu Jan 12 17:53:23 2012 CET
gpg:using DSA key 87DBF05A134B145C
gpg: Can't check signature: No public key

$ curl -s https://downloads.apache.org/sling/KEYS | gpg --no-default-keyring 
--keyring /tmp/kr --import
...
gpg: Total number processed: 38
gpg:   imported: 38

$ gpg --no-default-keyring --keyring /tmp/kr --verify 
adapter-annotations-1.0.0-javadoc.jar.asc 
gpg: assuming signed data in 'adapter-annotations-1.0.0-javadoc.jar'
gpg: Signature made Thu Jan 12 17:53:23 2012 CET
gpg:using DSA key 87DBF05A134B145C
gpg: Good signature from "Justin Edelson (CODE SIGNING KEY) 
" [unknown]
gpg: aka "Justin Edelson " [unknown]
gpg: aka "Justin Edelson " [unknown]
gpg: aka "Justin Edelson " 
[unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: A04B C4AD 3639 6AD5 A52C  8FE1 87DB F05A 134B 145C

 {code}
 

> Add KEYS file to https://dist.apache.org/repos/dist/release/sling
> -
>
> Key: SLING-9173
> URL: https://issues.apache.org/jira/browse/SLING-9173
> Project: Sling
>  Issue Type: Bug
>  Components: General
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> The link at https://sling.apache.org/downloads.cgi to 
> https://www.apache.org/dist/sling/KEYS is broken, because the KEYS file has 
> been removed in 2013 from the dist directory.
> The file needs to be reestablished and 
> 

[jira] [Commented] (SLING-9173) Add KEYS file to https://dist.apache.org/repos/dist/release/sling

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-9173:


Not sure if that's what you are asking, but the following works for me: first 
failing, then importing a key from that KEYS file and then succeeding.

The {{--no-default-keyring --keyring /tmp/kr}} options are meant to ignore my 
default keyring, for this example, you usually do not need them.

The "not certified with a trusted signature" bit means we don't know whether 
that key actually belongs to Justin, which is the case for all keys which do 
not have a web of trust connection to the key of the current user.
{code:java}
$ wget 
https://dist.apache.org/repos/dist/release/sling/adapter-annotations-1.0.0-javadoc.jar
$ wget 
https://dist.apache.org/repos/dist/release/sling/adapter-annotations-1.0.0-javadoc.jar.asc

$ gpg --no-default-keyring --keyring /tmp/kr --verify 
adapter-annotations-1.0.0-javadoc.jar.asc 
gpg: assuming signed data in 'adapter-annotations-1.0.0-javadoc.jar'
gpg: Signature made Thu Jan 12 17:53:23 2012 CET
gpg:using DSA key 87DBF05A134B145C
gpg: Can't check signature: No public key

$ curl -s https://downloads.apache.org/sling/KEYS | gpg --no-default-keyring 
--keyring /tmp/kr --import
...
gpg: Total number processed: 38
gpg:   imported: 38

$ gpg --no-default-keyring --keyring /tmp/kr --verify 
adapter-annotations-1.0.0-javadoc.jar.asc 
gpg: assuming signed data in 'adapter-annotations-1.0.0-javadoc.jar'
gpg: Signature made Thu Jan 12 17:53:23 2012 CET
gpg:using DSA key 87DBF05A134B145C
gpg: Good signature from "Justin Edelson (CODE SIGNING KEY) 
" [unknown]
gpg: aka "Justin Edelson " [unknown]
gpg: aka "Justin Edelson " [unknown]
gpg: aka "Justin Edelson " 
[unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: A04B C4AD 3639 6AD5 A52C  8FE1 87DB F05A 134B 145C

 {code}
 

> Add KEYS file to https://dist.apache.org/repos/dist/release/sling
> -
>
> Key: SLING-9173
> URL: https://issues.apache.org/jira/browse/SLING-9173
> Project: Sling
>  Issue Type: Bug
>  Components: General
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> The link at https://sling.apache.org/downloads.cgi to 
> https://www.apache.org/dist/sling/KEYS is broken, because the KEYS file has 
> been removed in 2013 from the dist directory.
> The file needs to be reestablished and 
> https://sling.apache.org/documentation/development/release-management.html#appendix-a-create-and-add-your-key-to-peopleapacheorg
>  need to be updated.
> Compare with the discussion at  
> https://lists.apache.org/thread.html/ra6807cd9c8d7921f4441f621b43c92aa90cb0380b0190e0da1461939%40%3Cdev.sling.apache.org%3E
> It is not allowed to instead just reference the file from 
> https://people.apache.org/keys/group/sling.asc, for a reasoning look at 
> https://people.apache.org/keys/



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (SLING-7813) SlingHttpServletResponseImpl should log when setStatus is called after it is committed

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz edited comment on SLING-7813 at 9/14/21, 11:49 AM:
---

_Update: the below comment is not valid as it refers to sendError, which does 
declare exceptions in the Servlet API, but setStatus does not_

I stumbled on this while looking at SLING-10810 and I think [commit 
bc9696bd|https://github.com/apache/sling-org-apache-sling-engine/commit/bc9696bd4f52a3a2b50a19f2572b80a4ac2ea3a2]
 introduces a non-standard behavior, where setStatus just logs a message if the 
request is already committed, instead of throwing an exception like 
[HttpServletResponse.sendError|https://javaee.github.io/javaee-spec/javadocs/javax/servlet/http/HttpServletResponse.html#sendError-int-java.lang.String-]
 does.

Actually, IIUC that non-standard behavior only happens if setStatus(status, 
message) is called with a non-empty message, otherwise super.setStatus is 
called.

That's suboptimal IMO, but considering that these changes are more than 3 years 
old now there's probably no urgent need to change that back - I'll just leave 
that note here in case we want to revisit this in the future.


was (Author: bdelacretaz):
I stumbled on this while looking at SLING-10810 and I think [commit 
bc9696bd|https://github.com/apache/sling-org-apache-sling-engine/commit/bc9696bd4f52a3a2b50a19f2572b80a4ac2ea3a2]
 introduces a non-standard behavior, where setStatus just logs a message if the 
request is already committed, instead of throwing an exception like 
[HttpServletResponse.sendError|https://javaee.github.io/javaee-spec/javadocs/javax/servlet/http/HttpServletResponse.html#sendError-int-java.lang.String-]
 does.

Actually, IIUC that non-standard behavior only happens if setStatus(status, 
message) is called with a non-empty message, otherwise super.setStatus is 
called.

That's suboptimal IMO, but considering that these changes are more than 3 years 
old now there's probably no urgent need to change that back - I'll just leave 
that note here in case we want to revisit this in the future.

> SlingHttpServletResponseImpl should log when setStatus is called after it is 
> committed
> --
>
> Key: SLING-7813
> URL: https://issues.apache.org/jira/browse/SLING-7813
> Project: Sling
>  Issue Type: Improvement
>  Components: Engine
>Affects Versions: Engine 2.6.12
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
> Fix For: Engine 2.6.14
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> I have been debugging a scenario, where a response did not have the (in this 
> case) expected status code {{500}} set by an error handling script, but 
> instead the status code was {{200}}.
> It turns out that a rendering script calls {{#flushBuffer()}} on the response 
> early on in order to optimize user experience. Later in the rendering chain a 
> JSP causes a {{NullPointerException}}, triggering an error handler which 
> calls {{#setStatus(500)}}. The {{#setStatus}} call is silently ignored.
> "Fixing" this problem would require buffering the entire response and 
> ignoring any flush calls (be it {{#flushBuffer()}}, {{#getWriter().flush()}} 
> or {{#getOutputStream().flush()}}). This would be a change in behaviour, a 
> violation of the Servlet spec and performance issues waiting to happen. Thus 
> I am ruling out this option.
> However, it would be helpful to improve "debuggability" of the problem. I 
> propose to log a warning when {{#setStatus()}} is called. Additionally, if 
> debug logging is enabled, I propose to log a stack trace to identify where 
> the flush call originated (unless the flush was due to too many bytes 
> written, which is not very helpful information).
> cc [~rombert]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SLING-7813) SlingHttpServletResponseImpl should log when setStatus is called after it is committed

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-7813:


I stumbled on this while looking at SLING-10810 and I think [commit 
bc9696bd|https://github.com/apache/sling-org-apache-sling-engine/commit/bc9696bd4f52a3a2b50a19f2572b80a4ac2ea3a2]
 introduces a non-standard behavior, where setStatus just logs a message if the 
request is already committed, instead of throwing an exception like 
[HttpServletResponse.sendError|https://javaee.github.io/javaee-spec/javadocs/javax/servlet/http/HttpServletResponse.html#sendError-int-java.lang.String-]
 does.

Actually, IIUC that non-standard behavior only happens if setStatus(status, 
message) is called with a non-empty message, otherwise super.setStatus is 
called.

That's suboptimal IMO, but considering that these changes are more than 3 years 
old now there's probably no urgent need to change that back - I'll just leave 
that note here in case we want to revisit this in the future.

> SlingHttpServletResponseImpl should log when setStatus is called after it is 
> committed
> --
>
> Key: SLING-7813
> URL: https://issues.apache.org/jira/browse/SLING-7813
> Project: Sling
>  Issue Type: Improvement
>  Components: Engine
>Affects Versions: Engine 2.6.12
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
> Fix For: Engine 2.6.14
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> I have been debugging a scenario, where a response did not have the (in this 
> case) expected status code {{500}} set by an error handling script, but 
> instead the status code was {{200}}.
> It turns out that a rendering script calls {{#flushBuffer()}} on the response 
> early on in order to optimize user experience. Later in the rendering chain a 
> JSP causes a {{NullPointerException}}, triggering an error handler which 
> calls {{#setStatus(500)}}. The {{#setStatus}} call is silently ignored.
> "Fixing" this problem would require buffering the entire response and 
> ignoring any flush calls (be it {{#flushBuffer()}}, {{#getWriter().flush()}} 
> or {{#getOutputStream().flush()}}). This would be a change in behaviour, a 
> violation of the Servlet spec and performance issues waiting to happen. Thus 
> I am ruling out this option.
> However, it would be helpful to improve "debuggability" of the problem. I 
> propose to log a warning when {{#setStatus()}} is called. Additionally, if 
> debug logging is enabled, I propose to log a stack trace to identify where 
> the flush call originated (unless the flush was due to too many bytes 
> written, which is not very helpful information).
> cc [~rombert]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SLING-10810) new status code should not be set if response is already comitted

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-10810:
-

Digging a bit deeper, it looks like the behavior that I consider non-standard 
(ignoring setStatus instead of throwing an exception if the response is already 
committed) was introduced in 
[bc9696bd|https://github.com/apache/sling-org-apache-sling-engine/commit/bc9696bd4f52a3a2b50a19f2572b80a4ac2ea3a2]
 for SLING-7813.

I agree that your changes improve the situation but I regret not catching 
SLING-7813 at that time, I would have at least challenged the suggested new 
behavior.

However, It's been 3 years now so it looks like that's working.

> new status code should not be set if response is already comitted
> -
>
> Key: SLING-10810
> URL: https://issues.apache.org/jira/browse/SLING-10810
> Project: Sling
>  Issue Type: Improvement
>  Components: Engine
>Affects Versions: Engine 2.7.8
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: Engine 2.7.10
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> If the response is already committed, a new response should not be set, but 
> it should only be warned.
> Otherwise the status code logged in the Sling instance will taken from the 
> ResponseImpl object, which is different from the statuscode which is sent to 
> the client.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (SLING-10810) new status code should not be set if response is already comitted

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz edited comment on SLING-10810 at 9/14/21, 7:55 AM:
---

I'm not sure exactly where this problem happens, but in general shouldn't we 
throw an exception if code tries to set the status code of a committed response?

The 
[HttpServletResponse.sendError|https://javaee.github.io/javaee-spec/javadocs/javax/servlet/http/HttpServletResponse.html#sendError-int-java.lang.String-]
 method, for example, throws an IllegalStateException if it's called when the 
response is already committed. We might want do to the same.


was (Author: bdelacretaz):
I'm not sure exactly where this problem happens, but in general shouldn't we 
throw an exception if code tries to set multiple response status codes?

The 
[HttpServletResponse.sendError|https://javaee.github.io/javaee-spec/javadocs/javax/servlet/http/HttpServletResponse.html#sendError-int-java.lang.String-]
 method, for example, throws an IllegalStateException if it's called when the 
response is already committed. We might want do to the same.

> new status code should not be set if response is already comitted
> -
>
> Key: SLING-10810
> URL: https://issues.apache.org/jira/browse/SLING-10810
> Project: Sling
>  Issue Type: Improvement
>  Components: Engine
>Affects Versions: Engine 2.7.8
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: Engine 2.7.10
>
>
> If the response is already committed, a new response should not be set, but 
> it should only be warned.
> Otherwise the status code logged in the Sling instance will taken from the 
> ResponseImpl object, which is different from the statuscode which is sent to 
> the client.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SLING-10810) new status code should not be set if response is already comitted

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-10810:
-

I'm not sure exactly where this problem happens, but in general shouldn't we 
throw an exception if code tries to set multiple response status codes?

The 
[HttpServletResponse.sendError|https://javaee.github.io/javaee-spec/javadocs/javax/servlet/http/HttpServletResponse.html#sendError-int-java.lang.String-]
 method, for example, throws an IllegalStateException if it's called when the 
response is already committed. We might want do to the same.

> new status code should not be set if response is already comitted
> -
>
> Key: SLING-10810
> URL: https://issues.apache.org/jira/browse/SLING-10810
> Project: Sling
>  Issue Type: Improvement
>  Components: Engine
>Affects Versions: Engine 2.7.8
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: Engine 2.7.10
>
>
> If the response is already committed, a new response should not be set, but 
> it should only be warned.
> Otherwise the status code logged in the Sling instance will taken from the 
> ResponseImpl object, which is different from the statuscode which is sent to 
> the client.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SLING-10793) Enable or create admin user after deactivaition/deletion

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-10793:
-

I don't have an answer and also recommend asking the Jackrabbit project

>  Enable or create  admin user after deactivaition/deletion
> --
>
> Key: SLING-10793
> URL: https://issues.apache.org/jira/browse/SLING-10793
> Project: Sling
>  Issue Type: Wish
>Reporter: Nitish Sharma
>Priority: Major
>
> Do we have a way to enable or create admin user, which was removed earlier 
> due to security problems ?
> I have tried creating a new service user, but it again requires me to be 
> admin. Do we currently have any solution to solve this problem?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SLING-10645) Update Sling Resource Merger with handling for multi-valued properties

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-10645:
-

What bugs me with use cases 4 and 5 and for the "somewhere in between" option 
of 1 is that they imply that you know the original values. If that's the case, 
you could argue that replacing the whole set has the same effect. Or "almost" 
the same effect but that "almost" is where things possibly become hard to 
understand and troubleshoot.

Anyway, if you want to implement all cases I am not opposed, as long as the 
whole thing is backed by strong tests and clearly documented.

However I would much prefer having just what's actually required, which IIUC is 
a merge mode, maybe with "add before" or "add after" options which are simple 
to understand.

> Update Sling Resource Merger with handling for multi-valued properties
> --
>
> Key: SLING-10645
> URL: https://issues.apache.org/jira/browse/SLING-10645
> Project: Sling
>  Issue Type: Improvement
>  Components: ResourceResolver
>Affects Versions: Resource Merger 1.4.0
>Reporter: Henry Kuijpers
>Priority: Major
>
> Sling Resource Merger is able to handle properties, not individual property 
> values.
> When setting up this node structure (with AEM's extraClientlibs property in 
> TouchUI dialogs):
> + /libs/wcm/basicpage/cq:dialog@extraClientlibs=["a", "b", "c"]
> + /apps/website/components/page@sling:resourceSuperType="wcm/basicpage"
> + /apps/website/components/page/cq:dialog@extraClientlibs=["d", "e"]
> We want to make sure that the extraClientlibs property that is being read in 
> website/components/page/cq:dialog will return ["a", "b", "c", "d", "e"]. 
> Currently, it will just return ["d", "e"], since the extraClientlibs-property 
> is *overwritten*. 
> It would be nice to add additional logic to allow more control over the 
> inheritance of the values that are tied to a parent's 
> extraClientlibs-property.
> Maybe we can come up with some additional properties that can function as 
> instructions to the Resource Merger (next to the ones we already have), so 
> that there can be more fine-grained control over the inheritance/removal of 
> property values in multi-valued scenarios.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SLING-10645) Update Sling Resource Merger with handling for multi-valued properties

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-10645:
-

I don't know much about the resource merger, but looking at the docs at 
[https://sling.apache.org/documentation/bundles/resource-merger.html] the key 
modes seem to be "override" and "merge".

In this case for multi-valued properties the default mode is apparently 
"override", do you need more than a new "merge" option?

IIUC you're going for overriding or hiding individual values, which looks quite 
brittle to me. If just adding a "merge" mode would work for your use cases that 
might be easier to manage.

 

> Update Sling Resource Merger with handling for multi-valued properties
> --
>
> Key: SLING-10645
> URL: https://issues.apache.org/jira/browse/SLING-10645
> Project: Sling
>  Issue Type: Improvement
>  Components: ResourceResolver
>Affects Versions: Resource Merger 1.4.0
>Reporter: Henry Kuijpers
>Priority: Major
>
> Sling Resource Merger is able to handle properties, not individual property 
> values.
> When setting up this node structure (with AEM's extraClientlibs property in 
> TouchUI dialogs):
> + /libs/wcm/basicpage/cq:dialog@extraClientlibs=["a", "b", "c"]
> + /apps/website/components/page@sling:resourceSuperType="wcm/basicpage"
> + /apps/website/components/page/cq:dialog@extraClientlibs=["d", "e"]
> We want to make sure that the extraClientlibs property that is being read in 
> website/components/page/cq:dialog will return ["a", "b", "c", "d", "e"]. 
> Currently, it will just return ["d", "e"], since the extraClientlibs-property 
> is *overwritten*. 
> It would be nice to add additional logic to allow more control over the 
> inheritance of the values that are tied to a parent's 
> extraClientlibs-property.
> Maybe we can come up with some additional properties that can function as 
> instructions to the Resource Merger (next to the ones we already have), so 
> that there can be more fine-grained control over the inheritance/removal of 
> property values in multi-valued scenarios.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SLING-10742) Create integration tests for ResourceResolver

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-10742:
-

If someone's willing and able to create integration tests directly in the 
{{org.apache.sling.resourceresolver}} module I think that would be nice. The 
ones that Robert mentions look like they could run there as well, with pax exam 
or Sling Mocks, and having the ITs in the same module is a good thing IMO.

> Create integration tests for ResourceResolver
> -
>
> Key: SLING-10742
> URL: https://issues.apache.org/jira/browse/SLING-10742
> Project: Sling
>  Issue Type: Improvement
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.7.10
>Reporter: Henry Kuijpers
>Priority: Minor
>
> Now that the logic in Resource Resolver becomes more and more complex, for 
> example with regards to executing querys, it would be a good idea to create 
> some integration tests for this module.
> Mocking frameworks only go so far, many assumptions are made. In particular, 
> query execution is not done in our mocking frameworks. Instead of executing 
> them, we're basically saying "If we receive query 'x', we return results [y, 
> z]", without validating the query, without parsing it, without executing it. 
> This came up in SLING-10447, where we decided that verifying the correct 
> execution of the querys would be valuable to have. Right now, only the string 
> (that contains the query) is checked, but we're not checking if there are any 
> syntax issues and we're also not checking if the query executes correctly, 
> i.e. returns the expected results.
> We will probably come up with some more complex logic in SLING-10466, which 
> could also benefit from these integration tests.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (SLING-10749) Update repoinit parser in Feature Analyser

[Bertrand Delacretaz (Jira)]

Bertrand Delacretaz created SLING-10749:
---

 Summary: Update repoinit parser in Feature Analyser
 Key: SLING-10749
 URL: https://issues.apache.org/jira/browse/SLING-10749
 Project: Sling
  Issue Type: Improvement
  Components: Feature Model Analyser
Affects Versions: Feature Model Analyser 1.3.34
Reporter: Bertrand Delacretaz
Assignee: Bertrand Delacretaz


The feature analyser should be updated to the latest 
{{org.apache.sling.repoinit.parser}} version, which is currently 1.6.10



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (SLING-10747) Remove test-99 and better sync docs page with repoinit parser tests

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz resolved SLING-10747.
-
Resolution: Fixed

Implemented in commit 
https://github.com/apache/sling-org-apache-sling-repoinit-parser/commit/0128ee6bdc284a060f442258da59883b2dcab828

> Remove test-99 and better sync docs page with repoinit parser tests
> ---
>
> Key: SLING-10747
> URL: https://issues.apache.org/jira/browse/SLING-10747
> Project: Sling
>  Issue Type: Bug
>  Components: Repoinit
>Affects Versions: Repoinit Parser 1.6.10
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Fix For: Repoinit Parser 1.6.12
>
>
> The docs page at 
> [https://sling.apache.org/documentation/bundles/repository-initialization.html]
>  is supposed to show examples of all repoinit statements, but it's hard to 
> keep in sync manually and is often slightly out of sync.
> The {{src/test/resources/testcases/test-99.txt}} is supposed to also expose 
> all the repoinit syntax, is also maintained manually and is not 100% in sync 
> with that docs page.
> To make sure the docs stay in sync with minimal effort, we should:
>  * Remove the {{test-99.txt}} and adapt the other tests scenarios to make 
> sure the test coverage remains the same or better. Currently there's a slight 
> difference in "missed branches" in the {{-P jacoco-report}} output for the 
> parser.impl package if I remove it.
>  * Create a script that aggregates all the 
> {{src/test/resources/testcases/test-*.txt}} scenarios, ordered by name, and 
> use that output in the docs page.
>  * Verify that the result is at least as good as the current docs page in 
> terms of examples, comments and notes on required versions, and adapt the 
> test scenarios if not.
>  * Add information to the docs page on how to keep it up to date.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (SLING-10747) Remove test-99 and better sync docs page with repoinit parser tests

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz edited comment on SLING-10747 at 8/24/21, 3:26 PM:
---

Implemented in commit 
https://github.com/apache/sling-org-apache-sling-repoinit-parser/commit/0128ee6bdc284a060f442258da59883b2dcab828
 and docs page updated using the script provided in that commit, 
https://sling.apache.org/documentation/bundles/repository-initialization.html


was (Author: bdelacretaz):
Implemented in commit 
https://github.com/apache/sling-org-apache-sling-repoinit-parser/commit/0128ee6bdc284a060f442258da59883b2dcab828

> Remove test-99 and better sync docs page with repoinit parser tests
> ---
>
> Key: SLING-10747
> URL: https://issues.apache.org/jira/browse/SLING-10747
> Project: Sling
>  Issue Type: Bug
>  Components: Repoinit
>Affects Versions: Repoinit Parser 1.6.10
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Fix For: Repoinit Parser 1.6.12
>
>
> The docs page at 
> [https://sling.apache.org/documentation/bundles/repository-initialization.html]
>  is supposed to show examples of all repoinit statements, but it's hard to 
> keep in sync manually and is often slightly out of sync.
> The {{src/test/resources/testcases/test-99.txt}} is supposed to also expose 
> all the repoinit syntax, is also maintained manually and is not 100% in sync 
> with that docs page.
> To make sure the docs stay in sync with minimal effort, we should:
>  * Remove the {{test-99.txt}} and adapt the other tests scenarios to make 
> sure the test coverage remains the same or better. Currently there's a slight 
> difference in "missed branches" in the {{-P jacoco-report}} output for the 
> parser.impl package if I remove it.
>  * Create a script that aggregates all the 
> {{src/test/resources/testcases/test-*.txt}} scenarios, ordered by name, and 
> use that output in the docs page.
>  * Verify that the result is at least as good as the current docs page in 
> terms of examples, comments and notes on required versions, and adapt the 
> test scenarios if not.
>  * Add information to the docs page on how to keep it up to date.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (SLING-10747) Remove test-99 and better sync docs page with repoinit parser tests

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz updated SLING-10747:

Fix Version/s: Repoinit Parser 1.6.12

> Remove test-99 and better sync docs page with repoinit parser tests
> ---
>
> Key: SLING-10747
> URL: https://issues.apache.org/jira/browse/SLING-10747
> Project: Sling
>  Issue Type: Bug
>  Components: Repoinit
>Affects Versions: Repoinit Parser 1.6.10
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Fix For: Repoinit Parser 1.6.12
>
>
> The docs page at 
> [https://sling.apache.org/documentation/bundles/repository-initialization.html]
>  is supposed to show examples of all repoinit statements, but it's hard to 
> keep in sync manually and is often slightly out of sync.
> The {{src/test/resources/testcases/test-99.txt}} is supposed to also expose 
> all the repoinit syntax, is also maintained manually and is not 100% in sync 
> with that docs page.
> To make sure the docs stay in sync with minimal effort, we should:
>  * Remove the {{test-99.txt}} and adapt the other tests scenarios to make 
> sure the test coverage remains the same or better. Currently there's a slight 
> difference in "missed branches" in the {{-P jacoco-report}} output for the 
> parser.impl package if I remove it.
>  * Create a script that aggregates all the 
> {{src/test/resources/testcases/test-*.txt}} scenarios, ordered by name, and 
> use that output in the docs page.
>  * Verify that the result is at least as good as the current docs page in 
> terms of examples, comments and notes on required versions, and adapt the 
> test scenarios if not.
>  * Add information to the docs page on how to keep it up to date.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (SLING-10747) Remove test-99 and better sync docs page with repoinit parser tests

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz reassigned SLING-10747:
---

Assignee: Bertrand Delacretaz

> Remove test-99 and better sync docs page with repoinit parser tests
> ---
>
> Key: SLING-10747
> URL: https://issues.apache.org/jira/browse/SLING-10747
> Project: Sling
>  Issue Type: Bug
>  Components: Repoinit
>Affects Versions: Repoinit Parser 1.6.10
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
>
> The docs page at 
> [https://sling.apache.org/documentation/bundles/repository-initialization.html]
>  is supposed to show examples of all repoinit statements, but it's hard to 
> keep in sync manually and is often slightly out of sync.
> The {{src/test/resources/testcases/test-99.txt}} is supposed to also expose 
> all the repoinit syntax, is also maintained manually and is not 100% in sync 
> with that docs page.
> To make sure the docs stay in sync with minimal effort, we should:
>  * Remove the {{test-99.txt}} and adapt the other tests scenarios to make 
> sure the test coverage remains the same or better. Currently there's a slight 
> difference in "missed branches" in the {{-P jacoco-report}} output for the 
> parser.impl package if I remove it.
>  * Create a script that aggregates all the 
> {{src/test/resources/testcases/test-*.txt}} scenarios, ordered by name, and 
> use that output in the docs page.
>  * Verify that the result is at least as good as the current docs page in 
> terms of examples, comments and notes on required versions, and adapt the 
> test scenarios if not.
>  * Add information to the docs page on how to keep it up to date.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (SLING-10747) Remove test-99 and better sync docs page with repoinit parser tests

[Bertrand Delacretaz (Jira)]

Bertrand Delacretaz created SLING-10747:
---

 Summary: Remove test-99 and better sync docs page with repoinit 
parser tests
 Key: SLING-10747
 URL: https://issues.apache.org/jira/browse/SLING-10747
 Project: Sling
  Issue Type: Bug
  Components: Repoinit
Affects Versions: Repoinit Parser 1.6.10
Reporter: Bertrand Delacretaz


The docs page at 
[https://sling.apache.org/documentation/bundles/repository-initialization.html] 
is supposed to show examples of all repoinit statements, but it's hard to keep 
in sync manually and is often slightly out of sync.

The {{src/test/resources/testcases/test-99.txt}} is supposed to also expose all 
the repoinit syntax, is also maintained manually and is not 100% in sync with 
that docs page.

To make sure the docs stay in sync with minimal effort, we should:
 * Remove the {{test-99.txt}} and adapt the other tests scenarios to make sure 
the test coverage remains the same or better. Currently there's a slight 
difference in "missed branches" in the {{-P jacoco-report}} output for the 
parser.impl package if I remove it.
 * Create a script that aggregates all the 
{{src/test/resources/testcases/test-*.txt}} scenarios, ordered by name, and use 
that output in the docs page.
 * Verify that the result is at least as good as the current docs page in terms 
of examples, comments and notes on required versions, and adapt the test 
scenarios if not.
 * Add information to the docs page on how to keep it up to date.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SLING-10740) Repoinit create path statement fails for node types with a mandatory property

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-10740:
-

bq. perhaps calling save in AclVisitor#visitCreatePath is not necessary? 

I agree that removing that save might be the right path here. Before doing 
that, however, I would look at where save() calls happen generally in that 
module, we might need to review that and optimize to call save() only where 
really needed.

> Repoinit create path statement fails for node types with a mandatory property
> -
>
> Key: SLING-10740
> URL: https://issues.apache.org/jira/browse/SLING-10740
> Project: Sling
>  Issue Type: Bug
>  Components: Repoinit
>Reporter: Eric Norman
>Priority: Major
> Fix For: Repoinit JCR 1.1.38
>
>
> The processing of the "create path" statement calls save() at the end which 
> will cause a constraint violation if the nodetype of the created path 
> contains any properties that are declared as mandatory (and not autocreated). 
>  No processing of "set properties" statements happens before the save() call 
> in AclVisitor#visitCreatePath so it does not seem to be possible to define 
> any mandatory properties using the current repoinit grammar.
> I could see this solved in a couple ways:
>  # The AclVisitor#visitCreatePath could possibly pre-process any "set 
> properties" statements that are applicable to the created path before calling 
> save and then skip those same items when NodePropertiesVisitor visits the 
> same.
>  # Or, the "create path" grammar could be extended to allow defining 
> properties to be set at the same time as the create (with a syntax that is 
> similar to the "set properties" statement?)
>  # Or, perhaps calling save in AclVisitor#visitCreatePath is not necessary?  
> I'm not sure of the historical reasons why save() is done there.
>  # Or, maybe something else I haven't thought of
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SLING-10136) Sling Repo Init: Add option to delete paths

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-10136:
-

I'm not sure if one needs Sling Pipes just to delete paths - you could also 
just implement a 
{{[SlingRepositoryInitializer|https://sling.apache.org/documentation/bundles/repository-initialization.html#slingrepositoryinitializer-1]}}
  that deletes the appropriate paths.

> Sling Repo Init: Add option to delete paths
> ---
>
> Key: SLING-10136
> URL: https://issues.apache.org/jira/browse/SLING-10136
> Project: Sling
>  Issue Type: New Feature
>  Components: Repoinit
>Affects Versions: Repoinit Parser 1.6.4, Repoinit JCR 1.1.30
>Reporter: Henry Kuijpers
>Priority: Major
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> Given that we are able to create paths, it would also be beneficial to be 
> able to delete paths as well. 
> In our case, we're migrating a legacy setup to Sling Repo Init, where there 
> are some "leftover" nodes in the instances. Given that Sling Repo Init is an 
> "admin" way to initialize a repo, it would be very nice if delete statements 
> could be supported.
> In our case, we would want to delete /apps/foundation, for example, because 
> historically there seem to have been modifications made there.
> This mandates for a simple syntax like "delete path /apps/foundation" being 
> supported.
> Another case is that we would like to cleanup /apps/cq, however, there are 
> some nodes that are maintained by the product (in our case AEM), such as 
> /apps/cq/xssprotection and also /apps/cq/core/content/nav/tools. 
> This mandates for a slightly more complicated syntax such as "delete path 
> /apps/cq (!/xssprotection,!/core/content/nav/tools,*)", however, I would be 
> fine with multiple delete path statements as well, for that usecase.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SLING-10136) Sling Repo Init: Add option to delete paths

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-10136:
-

Considering that there is a "create path" operation, I think there should also 
be a "delete path".

However that's quite a dangerous operation, and might take a long time if 
there's lots of content and/or listeners triggered during deletion.

Do people have an idea on how to avoid the risk, or make sure whoever writes 
that statement is aware of the risk?

One approach might be to count the child nodes of the deletion candidate 
recursively and failing the command once that count reaches a set limit. And 
maybe allow raising the limit value with {{DELETE PATH /somepath LIMIT }} 
where N sets a new limit.

That's a crude mechanism but would at least make people aware that in general 
this is meant to delete small quantities of content only.

Alternatively, we might create a version of the path before deleting it, to 
provide a way to restore it if needed, but I'm not sure if that's practical or 
if that might cause other problems.

> Sling Repo Init: Add option to delete paths
> ---
>
> Key: SLING-10136
> URL: https://issues.apache.org/jira/browse/SLING-10136
> Project: Sling
>  Issue Type: New Feature
>  Components: Repoinit
>Affects Versions: Repoinit Parser 1.6.4, Repoinit JCR 1.1.30
>Reporter: Henry Kuijpers
>Priority: Major
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> Given that we are able to create paths, it would also be beneficial to be 
> able to delete paths as well. 
> In our case, we're migrating a legacy setup to Sling Repo Init, where there 
> are some "leftover" nodes in the instances. Given that Sling Repo Init is an 
> "admin" way to initialize a repo, it would be very nice if delete statements 
> could be supported.
> In our case, we would want to delete /apps/foundation, for example, because 
> historically there seem to have been modifications made there.
> This mandates for a simple syntax like "delete path /apps/foundation" being 
> supported.
> Another case is that we would like to cleanup /apps/cq, however, there are 
> some nodes that are maintained by the product (in our case AEM), such as 
> /apps/cq/xssprotection and also /apps/cq/core/content/nav/tools. 
> This mandates for a slightly more complicated syntax such as "delete path 
> /apps/cq (!/xssprotection,!/core/content/nav/tools,*)", however, I would be 
> fine with multiple delete path statements as well, for that usecase.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (SLING-10644) Return servlet resolver information in JSON format

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz closed SLING-10644.
---

> Return servlet resolver information in JSON format
> --
>
> Key: SLING-10644
> URL: https://issues.apache.org/jira/browse/SLING-10644
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Affects Versions: Servlets Resolver 2.8.0
>Reporter: Natalia Angulo Herrera
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: Servlets Resolver 2.8.2
>
>
> Currently we are only returning the servlet resolver information in HTML 
> format 
> [https://github.com/apache/sling-org-apache-sling-servlets-resolver/blob/master/src/main/java/org/apache/sling/servlets/resolver/internal/console/WebConsolePlugin.java.]
>  Return the output also in JSON format to be reusable and managable.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (SLING-10691) mvn sonar:sonar (Java 11) fails for many modules, "Unable to create javax script engine for javascript"

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz edited comment on SLING-10691 at 7/30/21, 2:24 PM:
---

To experiment with minimal changes for one of these old modules I tried just 
setting the parent pom version to 43 and adding the missing dependencies 
versions to the {{sling-org-apache-sling-junit-healthcheck}} module, using the 
same versions as reported by {{mvn dependency:tree}} before the changes 
([commit 
571173|https://github.com/apache/sling-org-apache-sling-junit-healthcheck/commit/5711734d9284a2c8ed101ecf2b645e5f4ca5fc6b])
 and that build passes now.

That won't work for all modules however, for {{org-apache-sling-junit-remote}} 
for example which uses {{maven-scr-plugin}}, unless I missed something the 
highest possible parent pom version is 29, which doesn't help with the Java 11 
issue. To go higher we'd need to switch away from {{maven-scr-plugin}}. For 
now, I'll disable sonar builds for that module to have a successful CI build.


was (Author: bdelacretaz):
To experiment with minimal changes for one of these old modules I tried just 
setting the parent pom version to 43 and adding the missing dependencies 
versions to the {{sling-org-apache-sling-junit-healthcheck}} module, using the 
same versions as reported by {{mvn dependency:tree}} before the changes 
([commit 
571173|https://github.com/apache/sling-org-apache-sling-junit-healthcheck/commit/5711734d9284a2c8ed101ecf2b645e5f4ca5fc6b])
 and that build passes now.

That won't work for all modules however, for {{org-apache-sling-junit-remote}} 
for example which uses {{maven-scr-plugin}}, unless I missed something the 
highest possible parent pom version is 29, which doesn't help with the Java 11 
issue. To go higher we'd need to switch away from {{maven-scr-plugin}}. I'll 
disable sonar builds for that module to have a successful CI build.

> mvn sonar:sonar (Java 11) fails for many modules, "Unable to create javax 
> script engine for javascript"
> ---
>
> Key: SLING-10691
> URL: https://issues.apache.org/jira/browse/SLING-10691
> Project: Sling
>  Issue Type: Bug
>Reporter: Bertrand Delacretaz
>Priority: Major
>
> This error at 
> https://ci-builds.apache.org/job/Sling/view/Monitor/job/modules/job/sling-maven-launchpad-plugin/job/master/56/console
>  seems to be common to many of our modules, for which {{mvn sonar:sonar}} 
> fails on Jenkins:
> {code}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-antrun-plugin:1.8:run
> (set-bundle-required-execution-environment) on project maven-launchpad-plugin:
> An Ant BuildException has occured:
> Unable to create javax script engine for javascript
> [ERROR] around Ant part ...
> 

[jira] [Comment Edited] (SLING-10691) mvn sonar:sonar (Java 11) fails for many modules, "Unable to create javax script engine for javascript"

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz edited comment on SLING-10691 at 7/30/21, 2:18 PM:
---

To experiment with minimal changes for one of these old modules I tried just 
setting the parent pom version to 43 and adding the missing dependencies 
versions to the {{sling-org-apache-sling-junit-healthcheck}} module, using the 
same versions as reported by {{mvn dependency:tree}} before the changes 
([commit 
571173|https://github.com/apache/sling-org-apache-sling-junit-healthcheck/commit/5711734d9284a2c8ed101ecf2b645e5f4ca5fc6b])
 and that build passes now.

That won't work for all modules however, for {{org-apache-sling-junit-remote}} 
for example which uses {{maven-scr-plugin}}, unless I missed something the 
highest possible parent pom version is 29, which doesn't help with the Java 11 
issue. To go higher we'd need to switch away from {{maven-scr-plugin}}. I'll 
disable sonar builds for that module to have a successful CI build.


was (Author: bdelacretaz):
To experiment with minimal changes for one of these old modules I tried just 
setting the parent pom version to 43 and adding the missing dependencies 
versions to the {{sling-org-apache-sling-junit-healthcheck}} module, using the 
same versions as reported by {{mvn dependency:tree}} before the changes 
([commit 
571173|https://github.com/apache/sling-org-apache-sling-junit-healthcheck/commit/5711734d9284a2c8ed101ecf2b645e5f4ca5fc6b])
 and that build passes now.

> mvn sonar:sonar (Java 11) fails for many modules, "Unable to create javax 
> script engine for javascript"
> ---
>
> Key: SLING-10691
> URL: https://issues.apache.org/jira/browse/SLING-10691
> Project: Sling
>  Issue Type: Bug
>Reporter: Bertrand Delacretaz
>Priority: Major
>
> This error at 
> https://ci-builds.apache.org/job/Sling/view/Monitor/job/modules/job/sling-maven-launchpad-plugin/job/master/56/console
>  seems to be common to many of our modules, for which {{mvn sonar:sonar}} 
> fails on Jenkins:
> {code}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-antrun-plugin:1.8:run
> (set-bundle-required-execution-environment) on project maven-launchpad-plugin:
> An Ant BuildException has occured:
> Unable to create javax script engine for javascript
> [ERROR] around Ant part ...
> 

[jira] [Comment Edited] (SLING-10691) mvn sonar:sonar (Java 11) fails for many modules, "Unable to create javax script engine for javascript"

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz edited comment on SLING-10691 at 7/30/21, 2:07 PM:
---

Note also [https://ci-builds.apache.org/job/Sling/view/Monitor/] - that's where 
all the orange prompted me to have a look, and an overview of the build states 
is now also available at https://sling.apache.org/repolist.html


was (Author: bdelacretaz):
Note also [https://ci-builds.apache.org/job/Sling/view/Monitor/] - that's where 
all the orange prompted me to have a look.

> mvn sonar:sonar (Java 11) fails for many modules, "Unable to create javax 
> script engine for javascript"
> ---
>
> Key: SLING-10691
> URL: https://issues.apache.org/jira/browse/SLING-10691
> Project: Sling
>  Issue Type: Bug
>Reporter: Bertrand Delacretaz
>Priority: Major
>
> This error at 
> https://ci-builds.apache.org/job/Sling/view/Monitor/job/modules/job/sling-maven-launchpad-plugin/job/master/56/console
>  seems to be common to many of our modules, for which {{mvn sonar:sonar}} 
> fails on Jenkins:
> {code}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-antrun-plugin:1.8:run
> (set-bundle-required-execution-environment) on project maven-launchpad-plugin:
> An Ant BuildException has occured:
> Unable to create javax script engine for javascript
> [ERROR] around Ant part ...
> 

[jira] [Commented] (SLING-10691) mvn sonar:sonar (Java 11) fails for many modules, "Unable to create javax script engine for javascript"

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-10691:
-

To experiment with minimal changes for one of these old modules I tried just 
setting the parent pom version to 43 and adding the missing dependencies 
versions to the {{sling-org-apache-sling-junit-healthcheck}} module, using the 
same versions as reported by {{mvn dependency:tree}} before the changes 
([commit 
571173|https://github.com/apache/sling-org-apache-sling-junit-healthcheck/commit/5711734d9284a2c8ed101ecf2b645e5f4ca5fc6b])
 and that build passes now.

> mvn sonar:sonar (Java 11) fails for many modules, "Unable to create javax 
> script engine for javascript"
> ---
>
> Key: SLING-10691
> URL: https://issues.apache.org/jira/browse/SLING-10691
> Project: Sling
>  Issue Type: Bug
>Reporter: Bertrand Delacretaz
>Priority: Major
>
> This error at 
> https://ci-builds.apache.org/job/Sling/view/Monitor/job/modules/job/sling-maven-launchpad-plugin/job/master/56/console
>  seems to be common to many of our modules, for which {{mvn sonar:sonar}} 
> fails on Jenkins:
> {code}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-antrun-plugin:1.8:run
> (set-bundle-required-execution-environment) on project maven-launchpad-plugin:
> An Ant BuildException has occured:
> Unable to create javax script engine for javascript
> [ERROR] around Ant part ...
> 

[jira] [Commented] (SLING-10691) mvn sonar:sonar (Java 11) fails for many modules, "Unable to create javax script engine for javascript"

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-10691:
-

Note also [https://ci-builds.apache.org/job/Sling/view/Monitor/] - that's where 
all the orange prompted me to have a look.

> mvn sonar:sonar (Java 11) fails for many modules, "Unable to create javax 
> script engine for javascript"
> ---
>
> Key: SLING-10691
> URL: https://issues.apache.org/jira/browse/SLING-10691
> Project: Sling
>  Issue Type: Bug
>Reporter: Bertrand Delacretaz
>Priority: Major
>
> This error at 
> https://ci-builds.apache.org/job/Sling/view/Monitor/job/modules/job/sling-maven-launchpad-plugin/job/master/56/console
>  seems to be common to many of our modules, for which {{mvn sonar:sonar}} 
> fails on Jenkins:
> {code}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-antrun-plugin:1.8:run
> (set-bundle-required-execution-environment) on project maven-launchpad-plugin:
> An Ant BuildException has occured:
> Unable to create javax script engine for javascript
> [ERROR] around Ant part ...
> 

[jira] [Updated] (SLING-10691) mvn sonar:sonar (Java 11) fails for many modules, "Unable to create javax script engine for javascript"

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz updated SLING-10691:

Summary: mvn sonar:sonar (Java 11) fails for many modules, "Unable to 
create javax script engine for javascript"  (was: mvn sonar:sonar fails for 
many modules, "Unable to create javax script engine for javascript")

> mvn sonar:sonar (Java 11) fails for many modules, "Unable to create javax 
> script engine for javascript"
> ---
>
> Key: SLING-10691
> URL: https://issues.apache.org/jira/browse/SLING-10691
> Project: Sling
>  Issue Type: Bug
>Reporter: Bertrand Delacretaz
>Priority: Major
>
> This error at 
> https://ci-builds.apache.org/job/Sling/view/Monitor/job/modules/job/sling-maven-launchpad-plugin/job/master/56/console
>  seems to be common to many of our modules, for which {{mvn sonar:sonar}} 
> fails on Jenkins:
> {code}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-antrun-plugin:1.8:run
> (set-bundle-required-execution-environment) on project maven-launchpad-plugin:
> An Ant BuildException has occured:
> Unable to create javax script engine for javascript
> [ERROR] around Ant part ...
> 

[jira] [Commented] (SLING-10691) mvn sonar:sonar fails for many modules, "Unable to create javax script engine for javascript"

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-10691:
-

The problem is modules which do not build with Java 11.

This was discussed in SLING-9839: the SonarQube setup that we are using doesn't 
support Java 8 builds anymore, and some of our older modules do not build with 
Java 11, {{mvn -U clean verify sonar:sonar}} will fail for such modules when 
run with Java 11.

I think we need a way to mark such modules to avoid revisiting this discussion 
again and again, maybe just se
 {{"sonarQubeEnabled": false}} in {{.sling-module.json}} for these older 
modules that don't build with Java 11?

I've done that for https://github.com/apache/sling-maven-launchpad-plugin and 
that build is green now. The risk is forgetting to remove that setting later 
and missing problems.

> mvn sonar:sonar fails for many modules, "Unable to create javax script engine 
> for javascript"
> -
>
> Key: SLING-10691
> URL: https://issues.apache.org/jira/browse/SLING-10691
> Project: Sling
>  Issue Type: Bug
>Reporter: Bertrand Delacretaz
>Priority: Major
>
> This error at 
> https://ci-builds.apache.org/job/Sling/view/Monitor/job/modules/job/sling-maven-launchpad-plugin/job/master/56/console
>  seems to be common to many of our modules, for which {{mvn sonar:sonar}} 
> fails on Jenkins:
> {code}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-antrun-plugin:1.8:run
> (set-bundle-required-execution-environment) on project maven-launchpad-plugin:
> An Ant BuildException has occured:
> Unable to create javax script engine for javascript
> [ERROR] around Ant part ...
> 

[jira] [Commented] (SLING-10676) Add a SECURITY.MD file to all our Git repositories

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-10676:
-

Thank you for your comments, my "doesn't hurt" statement is gone now ;-)

I have removed SECURITY.md everywhere as it's not needed, 
https://github.com/apache/sling-org-apache-sling-discovery-oak and 
https://github.com/apache/sling-org-apache-sling-launchpad-testing for example 
are back to green.

A number of modules are still orange at  
https://ci-builds.apache.org/job/Sling/view/Monitor/ but that's more likely 
SLING-10691

Sorry about all the noise with this ticket, it looks like I'm ready to write a 
"Success at Apache - making mistakes in public" blog post.

> Add a SECURITY.MD file to all our Git repositories
> --
>
> Key: SLING-10676
> URL: https://issues.apache.org/jira/browse/SLING-10676
> Project: Sling
>  Issue Type: Improvement
>  Components: Documentation
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
>
> We should add 
> [https://github.com/apache/.github/blob/main/.github/SECURITY.md] to all our 
> repositories (but linking to [1]), as per 
> [https://twitter.com/iamamoose/status/1417104695626240001:]
> {quote}All Apache projects follow the default ASF security policy; but not 
> all have a github SECURITY․md file, and they get penalised, i.e. with lower 
> #openssf scorecard scores 
> ([http://metrics.openssf.org|http://metrics.openssf.org/]) 
> {quote}
> Tentatively assigning to myself but if someone beats me to it I'd be happy!
> [1] https://sling.apache.org/project-information/security.html



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (SLING-10691) mvn sonar:sonar fails for many modules, "Unable to create javax script engine for javascript"

[Bertrand Delacretaz (Jira)]

Bertrand Delacretaz created SLING-10691:
---

 Summary: mvn sonar:sonar fails for many modules, "Unable to create 
javax script engine for javascript"
 Key: SLING-10691
 URL: https://issues.apache.org/jira/browse/SLING-10691
 Project: Sling
  Issue Type: Bug
Reporter: Bertrand Delacretaz


This error at 
https://ci-builds.apache.org/job/Sling/view/Monitor/job/modules/job/sling-maven-launchpad-plugin/job/master/56/console
 seems to be common to many of our modules, for which {{mvn sonar:sonar}} fails 
on Jenkins:

{code}
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-antrun-plugin:1.8:run
(set-bundle-required-execution-environment) on project maven-launchpad-plugin:
An Ant BuildException has occured:
Unable to create javax script engine for javascript
[ERROR] around Ant part ...

[jira] [Commented] (SLING-10676) Add a SECURITY.MD file to all our Git repositories

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-10676:
-

Turns out adding these files was not needed, the default security policy 
applies to all GitHub repos from the apache organization that don't have one.

For example https://github.com/apache/incubator-ponymail-foal/security/policy 
displays https://github.com/apache/.github/blob/main/.github/SECURITY.md even 
though there's no SECURITY.md at 
https://github.com/apache/incubator-ponymail-foal

Anyway, with the one I added we have sling-specific security information, that 
doesn't hurt.

> Add a SECURITY.MD file to all our Git repositories
> --
>
> Key: SLING-10676
> URL: https://issues.apache.org/jira/browse/SLING-10676
> Project: Sling
>  Issue Type: Improvement
>  Components: Documentation
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
>
> We should add 
> [https://github.com/apache/.github/blob/main/.github/SECURITY.md] to all our 
> repositories (but linking to [1]), as per 
> [https://twitter.com/iamamoose/status/1417104695626240001:]
> {quote}All Apache projects follow the default ASF security policy; but not 
> all have a github SECURITY․md file, and they get penalised, i.e. with lower 
> #openssf scorecard scores 
> ([http://metrics.openssf.org|http://metrics.openssf.org/]) 
> {quote}
> Tentatively assigning to myself but if someone beats me to it I'd be happy!
> [1] https://sling.apache.org/project-information/security.html



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (SLING-10676) Add a SECURITY.MD file to all our Git repositories

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz resolved SLING-10676.
-
Resolution: Fixed

I have now added SECURITY.md to all Sling repositories using the script at 
https://github.com/apache/sling-aggregator/blob/master/add-security-md.sh

There were a few stray commits with a zero bytes SECURITY.md due to a bug in my 
script, which should all be fixed now.

> Add a SECURITY.MD file to all our Git repositories
> --
>
> Key: SLING-10676
> URL: https://issues.apache.org/jira/browse/SLING-10676
> Project: Sling
>  Issue Type: Improvement
>  Components: Documentation
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
>
> We should add 
> [https://github.com/apache/.github/blob/main/.github/SECURITY.md] to all our 
> repositories (but linking to [1]), as per 
> [https://twitter.com/iamamoose/status/1417104695626240001:]
> {quote}All Apache projects follow the default ASF security policy; but not 
> all have a github SECURITY․md file, and they get penalised, i.e. with lower 
> #openssf scorecard scores 
> ([http://metrics.openssf.org|http://metrics.openssf.org/]) 
> {quote}
> Tentatively assigning to myself but if someone beats me to it I'd be happy!
> [1] https://sling.apache.org/project-information/security.html



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SLING-10676) Add a SECURITY.MD file to all our Git repositories

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-10676:
-

I have created 
https://github.com/apache/sling-aggregator/blob/master/SECURITY.md that we can 
replicate to other modules.

> Add a SECURITY.MD file to all our Git repositories
> --
>
> Key: SLING-10676
> URL: https://issues.apache.org/jira/browse/SLING-10676
> Project: Sling
>  Issue Type: Improvement
>  Components: Documentation
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
>
> We should add 
> [https://github.com/apache/.github/blob/main/.github/SECURITY.md] to all our 
> repositories (but linking to [1]), as per 
> [https://twitter.com/iamamoose/status/1417104695626240001:]
> {quote}All Apache projects follow the default ASF security policy; but not 
> all have a github SECURITY․md file, and they get penalised, i.e. with lower 
> #openssf scorecard scores 
> ([http://metrics.openssf.org|http://metrics.openssf.org/]) 
> {quote}
> Tentatively assigning to myself but if someone beats me to it I'd be happy!
> [1] https://sling.apache.org/project-information/security.html



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (SLING-10676) Add a SECURITY.MD file to all our Git repositories

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz updated SLING-10676:

Description: 
We should add [https://github.com/apache/.github/blob/main/.github/SECURITY.md] 
to all our repositories (but linking to [1]), as per 
[https://twitter.com/iamamoose/status/1417104695626240001:]

{quote}All Apache projects follow the default ASF security policy; but not all 
have a github SECURITY․md file, and they get penalised, i.e. with lower 
#openssf scorecard scores 
([http://metrics.openssf.org|http://metrics.openssf.org/]) 
{quote}

Tentatively assigning to myself but if someone beats me to it I'd be happy!

[1] https://sling.apache.org/project-information/security.html

  was:
We should add [https://github.com/apache/.github/blob/main/.github/SECURITY.md] 
to all our repositories, as per 
[https://twitter.com/iamamoose/status/1417104695626240001:]

{quote}All Apache projects follow the default ASF security policy; but not all 
have a github SECURITY․md file, and they get penalised, i.e. with lower 
#openssf scorecard scores 
([http://metrics.openssf.org|http://metrics.openssf.org/]) 
{quote}

Tentatively assigning to myself but if someone beats me to it I'd be happy!




> Add a SECURITY.MD file to all our Git repositories
> --
>
> Key: SLING-10676
> URL: https://issues.apache.org/jira/browse/SLING-10676
> Project: Sling
>  Issue Type: Improvement
>  Components: Documentation
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
>
> We should add 
> [https://github.com/apache/.github/blob/main/.github/SECURITY.md] to all our 
> repositories (but linking to [1]), as per 
> [https://twitter.com/iamamoose/status/1417104695626240001:]
> {quote}All Apache projects follow the default ASF security policy; but not 
> all have a github SECURITY․md file, and they get penalised, i.e. with lower 
> #openssf scorecard scores 
> ([http://metrics.openssf.org|http://metrics.openssf.org/]) 
> {quote}
> Tentatively assigning to myself but if someone beats me to it I'd be happy!
> [1] https://sling.apache.org/project-information/security.html



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (SLING-10676) Add a SECURITY.MD file to all our Git repositories

[Bertrand Delacretaz (Jira)]

Bertrand Delacretaz created SLING-10676:
---

 Summary: Add a SECURITY.MD file to all our Git repositories
 Key: SLING-10676
 URL: https://issues.apache.org/jira/browse/SLING-10676
 Project: Sling
  Issue Type: Improvement
  Components: Documentation
Reporter: Bertrand Delacretaz
Assignee: Bertrand Delacretaz


We should add [https://github.com/apache/.github/blob/main/.github/SECURITY.md] 
to all our repositories, as per 
[https://twitter.com/iamamoose/status/1417104695626240001:]

{quote}All Apache projects follow the default ASF security policy; but not all 
have a github SECURITY․md file, and they get penalised, i.e. with lower 
#openssf scorecard scores 
([http://metrics.openssf.org|http://metrics.openssf.org/]) 
{quote}

Tentatively assigning to myself but if someone beats me to it I'd be happy!





--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SLING-10672) Document required settings for reproducible builds

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-10672:
-

The 
[https://maven.apache.org/guides/minia/guide-reproducible-builds.html|https://maven.apache.org/guides/mini/guide-reproducible-builds.html]
 guide says that maven-javadoc-plugin also requires a 
{{true}} configuration in {{pluginManagement}} (for 
automatic use both from plugins and reports), would that help?

> Document required settings for reproducible builds
> --
>
> Key: SLING-10672
> URL: https://issues.apache.org/jira/browse/SLING-10672
> Project: Sling
>  Issue Type: Task
>  Components: Documentation
>Affects Versions: Parent 44
>Reporter: Oliver Lietz
>Priority: Major
>
> Building Commons Messaging Mail with Bundle Parent 44 fails (after [adding 
> required 
> property|https://maven.apache.org/guides/mini/guide-reproducible-builds.html] 
> {{1}}):
> {noformat}
> [INFO] --- maven-javadoc-plugin:3.3.0:javadoc (default-cli) @ 
> org.apache.sling.commons.messaging.mail ---
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time:  21.566 s
> [INFO] Finished at: 2021-07-26T20:15:20+02:00
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-javadoc-plugin:3.3.0:javadoc (default-cli) on 
> project org.apache.sling.commons.messaging.mail: Execution default-cli of 
> goal org.apache.maven.plugins:maven-javadoc-plugin:3.3.0:javadoc failed: Text 
> '1' could not be parsed at index 0 -> [Help 1]
> [ERROR] 
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR] 
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SLING-10669) Unable to move CMS directory

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-10669:
-

I was curious and did some investigation. Not planning to work on fixing this 
myself, but hopefully this helps.

As a **workaround**, the CMS starts for me if I remove the {{launcher/cache/}} 
and {{launcher/framework/}} folders before starting, after having moved the 
whole CMS folder to a different location. This means losing any OSGi 
configuration changes that were made, but the content is preserved.

Without this workaround I get the following errors:

Case A: after **renaming the folder** that contains the CMS, I get lots of 
"Referenced file does not exist" errors at startup, with absolute bundle 
filenames which include the old folder name. Moving the {{launcher/cache}} 
folder back to the previous location avoids this issue.

Case B: On the other hand if I copy the folder contents to a different 
location, but the **old location still exists**, I get this error:
{code:java}
[ERROR] Error while running launcher: null
java.lang.reflect.InvocationTargetException
at 
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
 Method)
...
at 
org.apache.sling.feature.launcher.impl.launchers.FrameworkLauncher.run(FrameworkLauncher.java:98)
...
at org.apache.sling.cms.feature.Main.main(Main.java:35)
Caused by: org.osgi.framework.BundleException: Bundle symbolic name and version 
are not unique: org.jvnet.staxex.stax-ex:1.8.3
at 
org.apache.felix.framework.BundleImpl.createRevision(BundleImpl.java:1337)
...
at 
org.apache.sling.feature.launcher.impl.launchers.FrameworkRunner.(FrameworkRunner.java:82)
{code}
But if I rename or remove the previous location the error is back to case A.

So it looks like the **root cause** might be absolute filenames being stored to 
refer to the {{launcher/cache}} location.

> Unable to move CMS directory
> 
>
> Key: SLING-10669
> URL: https://issues.apache.org/jira/browse/SLING-10669
> Project: Sling
>  Issue Type: Bug
>  Components: App CMS
>Affects Versions: App CMS 1.0.2, App CMS 1.0.4
>Reporter: James Raynor
>Priority: Major
>
> Operating system: Win10
> Steps to reproduce:
> Create the folder C:\SlingCMS
>  Start SlingCMS with the following command
>  java -jar org.apache.sling.cms-1.0.4.jar
> Close SlingCMS, move “SlingCMS” folder to the “C:\test” folder, and then the 
> CMS will not start.
>  C:\test\SlingCMS
>  
> It is now impossible to easily move the entire folder of the website from the 
> local computer to the server again, allowing the bundle or configuration 
> information to remain as well.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SLING-10625) Repoinit Visitors should not throw RuntimeExceptions

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-10625:
-

bq. do you recall why the code wraps all exceptions into RuntimeExceptions..

I don't, but it's probably a way to avoid the hassle of checked exceptions?

If you have a backwards compatible suggestion I'm open to that.

> Repoinit Visitors should not throw RuntimeExceptions
> 
>
> Key: SLING-10625
> URL: https://issues.apache.org/jira/browse/SLING-10625
> Project: Sling
>  Issue Type: Improvement
>  Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.36
>Reporter: Joerg Hoh
>Priority: Major
> Fix For: Repoinit JCR 1.1.38
>
>
> When a repoinit visitor catches an exception it wraps this exception into a 
> RuntimeException. In case the original exception is an 
> InvalidItemStateException, the retry mechanism introduced in SLING-10418 is 
> not able to retry.
> This should be changed, instead of wrapping the Exception the exception 
> should just be thrown, the special handling of report should not be required 
> at all.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SLING-10229) [LauncherContainer]Set up automated builds for this Docker image

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-10229:
-

{quote}there is just one build for each release...
{quote}
For Sling yes but if Docker Hub counts all builds from the 
[https://github.com/apache/] that might be a lot.

I have no idea how many similar builds there are under 
[https://github.com/apache/] and what the limits are but if we rely on this 
build someone needs to find out.

Alternatively, if a "manual" way of publishing the image to Docker Hub is 
available and documented that might be fine, as a last resource in case we (the 
ASF, collectively) hit build resource limitations.

> [LauncherContainer]Set up automated builds for this Docker image 
> -
>
> Key: SLING-10229
> URL: https://issues.apache.org/jira/browse/SLING-10229
> Project: Sling
>  Issue Type: Improvement
>  Components: Feature Model
>Reporter: Stefan Bischof
>Priority: Minor
>
> This is an leftover from an other PR:
> [~rombert]: in  
> [PR|https://github.com/apache/sling-org-apache-sling-feature-launcher/pull/18]
> "I think it would be good to set up automated builds for this Docker image 
> eventually ( not in scope of this PR ). Looking at 
> https://stackoverflow.com/questions/36853002/writing-dockerfile-for-dockerhub-automated-builds,
>  it looks like the Docker build is basically invoking a top-level Dockerfile. 
> Maybe we should move the 'launch' Dockerfile where the plug-in expects it and 
> leave the top-level Dockerfile as an entry point for Dockerhub automated 
> builds?"
> ---
> I am not sure what you mean with `launch`Dockerfile. And that would mean that 
> we have 2 files?
> The Docker Hub automated build uses a file, that could be specified in 
> Docker-hub. They use the Tag/Branch as the version tag of the image. But we 
> are holding the version just inside maven. So I am not sure that this 
> automated build from the Dockerhub-side is the best way. And we are back at 
> the point where we have to find a way to copy the launcher-${version].jar 
> without changing the Dockerfile in every version just because of the 
> different names. 
> I would really like to have this official container automated in the docker 
> hub.
> But I do not know how to solve this with your CI-Tooling / Access rights on 
> DockerHub.
> Having an jenkins that builds every commit with the -P container option and 
> pushes the images would be the easiest way.
> regards
> Stefan



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (SLING-10656) SmokeIT readable URL checks need retries

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz updated SLING-10656:

Fix Version/s: Starter 12

> SmokeIT readable URL checks need retries
> 
>
> Key: SLING-10656
> URL: https://issues.apache.org/jira/browse/SLING-10656
> Project: Sling
>  Issue Type: Improvement
>  Components: Starter
>Affects Versions: Starter 11
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Fix For: Starter 12
>
>
> The {{SmokeIT. verifyReadableUrl}} tests introduced for SLING-10402 do not 
> retry their HTTP requests and it looks like in some cases the content is not 
> ready when the test runs.
> As we do have a {{Check}} class in the {{StarterReadyRule}} which does 
> retries, we should also use it for the {{verifyReadableUrl}} tests.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (SLING-10656) SmokeIT readable URL checks need retries

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz resolved SLING-10656.
-
Resolution: Fixed

Implemented in [commit 
9db5b09|https://github.com/apache/sling-org-apache-sling-starter/commit/9db5b09bce14fea95c4500ea8f845cda7a274756]

> SmokeIT readable URL checks need retries
> 
>
> Key: SLING-10656
> URL: https://issues.apache.org/jira/browse/SLING-10656
> Project: Sling
>  Issue Type: Improvement
>  Components: Starter
>Affects Versions: Starter 11
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
>
> The {{SmokeIT. verifyReadableUrl}} tests introduced for SLING-10402 do not 
> retry their HTTP requests and it looks like in some cases the content is not 
> ready when the test runs.
> As we do have a {{Check}} class in the {{StarterReadyRule}} which does 
> retries, we should also use it for the {{verifyReadableUrl}} tests.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (SLING-10656) SmokeIT readable URL checks need retries

[Bertrand Delacretaz (Jira)]

Bertrand Delacretaz created SLING-10656:
---

 Summary: SmokeIT readable URL checks need retries
 Key: SLING-10656
 URL: https://issues.apache.org/jira/browse/SLING-10656
 Project: Sling
  Issue Type: Improvement
  Components: Starter
Affects Versions: Starter 11
Reporter: Bertrand Delacretaz
Assignee: Bertrand Delacretaz


The {{SmokeIT. verifyReadableUrl}} tests introduced for SLING-10402 do not 
retry their HTTP requests and it looks like in some cases the content is not 
ready when the test runs.

As we do have a {{Check}} class in the {{StarterReadyRule}} which does retries, 
we should also use it for the {{verifyReadableUrl}} tests.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SLING-10655) Provide a good developer experience for GraphQL Schemas assembled by the Schema Aggregator

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-10655:
-

As discussed in SLING-10619, from the developer's point of view the only 
requirement for exporting a partial schema should be to place it at a know 
location in the source code tree ({{src/main/graphql/partials}} maybe) and 
activate the bnd plugin that generates the capabilities.

The plugin should also ideally validate the partials syntax to detect errors at 
build time.

> Provide a good developer experience for GraphQL Schemas assembled by the 
> Schema Aggregator
> --
>
> Key: SLING-10655
> URL: https://issues.apache.org/jira/browse/SLING-10655
> Project: Sling
>  Issue Type: Task
>  Components: GraphQL
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: GraphQL Schema Aggregator 0.0.2
>
>
> The [GraphQL Schema 
> Aggregator|https://github.com/apache/sling-org-apache-sling-graphql-schema-aggregator]
>  allows assembling and serving GraphQL Schemas to which multiple provider 
> bundles can contribute.
> Currently, this still relies on the presence of the {{Sling-GraphQL-Schema}} 
> bundle header in the provider bundles, but this should be replaced by OSGi 
> capabilities and requirements.
> The GraphQL Schema Aggregator already provides the following capability:
> {code}
> osgi.extender;osgi.extender="sling.graphql-schema-aggregator";version:Version="0.1"
> {code}
> where the version indicates which syntax version of the partial files is 
> supported.
> Provider bundles should in turn require this capability:
> {code}
> Require-Capability: 
> osgi.extender;filter:="(&(osgi.extender=sling.graphql-schema-aggregator)(version>=0.1)((version>=1.0)))"
> {code}
> and provide in turn a capability indicating the partials they contribute. If 
> they also require other partials provided by other bundles, these should be 
> translated as well into other {{Require-Capability}} entries.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SLING-10619) Remove sling.graphql-schema-aggregator capability if not useful

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-10619:
-

Ok cool, that works for me. 

I think this makes the developer scenario even simpler:

* Add partials under src/main/graphql/partials
* Let the bnd plugin generate the corresponding OSGi requirements and 
capabilities
* Let the bnd plugin check the partials syntax

> Remove sling.graphql-schema-aggregator capability if not useful
> ---
>
> Key: SLING-10619
> URL: https://issues.apache.org/jira/browse/SLING-10619
> Project: Sling
>  Issue Type: Improvement
>  Components: GraphQL
>Reporter: Bertrand Delacretaz
>Priority: Minor
> Fix For: GraphQL Schema Aggregator 0.0.2
>
>
> The {{ProviderBundleTracker}} currently requires provider bundles to define 
> an [OSGi 
> capability|https://github.com/apache/sling-org-apache-sling-graphql-schema-aggregator/blob/04474a2fe16389c0df60471922f38e7dcfc637ef/src/main/java/org/apache/sling/graphql/schema/aggregator/impl/ProviderBundleTracker.java#L48],
>  I think the idea is for that class to efficiently ignore bundles which are 
> not provider bundles.
> However I don't think this is more efficient than just having 
> {{addingBundle(...)}} test for the {{Sling-GraphQL-Schema}} header.
> I would argue that doing the following in that method would be at least as 
> efficient than the current code in terms of ignoring non-provider bundles:
> {code:java}
> @Override
> public Object addingBundle(Bundle bundle, BundleEvent event) {
>   final String providersPath = 
> bundle.getHeaders().get("Sling-GraphQL-Schema");
>   if (providersPath == null) {
> // not interested in that bundle
> return;
>   ...
> {code}
> Currently, requiring this capability means provider bundles must declare both 
> the {{Sling-GraphQL-Schema}} header and the 
> {{sling.graphql-schema-aggregator}} capability. 
> Unless there are definite advantages in having both, I'd be in favor of 
> requiring just the {{Sling-GraphQL-Schema}} header to keep things as simple 
> as possible.
> [~radu] I know you were in favor of using the capability, if we agree that 
> the above code has no performance impact, do you see another benefit of using 
> the capability?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SLING-7534) Release policy - stop providing MD5 and start providing SHA-512 checksums

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-7534:


Ok, I'll change the download page to include the sha512 only for the "source 
zip" artifacts.

I'm curious, why do we omit sha512 for binaries? Build performance, or because 
they're not Apache Releases?

> Release policy - stop providing MD5 and start providing SHA-512 checksums
> -
>
> Key: SLING-7534
> URL: https://issues.apache.org/jira/browse/SLING-7534
> Project: Sling
>  Issue Type: Task
>  Components: Tooling
>Reporter: Robert Munteanu
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: Parent 43
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> See http://www.apache.org/dev/release-distribution#sigs-and-sums , we SHOULD 
> no longer provide MD5 checksums for new releases.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SLING-10619) Remove sling.graphql-schema-aggregator capability if not useful

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-10619:
-

bq. ...they also in turn advertise a capability for each schema / partial they 
provide...

Do you envision generating those capabilities automatically at build time? 
Maybe with a bnd plugin like 
https://github.com/apache/sling-org-apache-sling-bnd-models ?

I think from the developer's point of view the ideal scenario should be:

* Add the Sling-GraphQL-Schema header pointing to the path where partials are 
found
* Add any partial schema files in there
* That's it

And at build time the tooling should:
* a) Validate the syntax of the partial files
* b) Generate the corresponding OSGi provide-capability and require-capability 
headers

And maybe later a Sling feature analyser can 

* c) verify that the required partials are provided as well as ideally verify 
the syntax of the aggregated schema.

That's the ideal case but I think we need at least b) to avoid having to 
duplicate information, and that requires a) to extract the relevant values.

> Remove sling.graphql-schema-aggregator capability if not useful
> ---
>
> Key: SLING-10619
> URL: https://issues.apache.org/jira/browse/SLING-10619
> Project: Sling
>  Issue Type: Improvement
>  Components: GraphQL
>Reporter: Bertrand Delacretaz
>Priority: Minor
> Fix For: GraphQL Schema Aggregator 0.0.2
>
>
> The {{ProviderBundleTracker}} currently requires provider bundles to define 
> an [OSGi 
> capability|https://github.com/apache/sling-org-apache-sling-graphql-schema-aggregator/blob/04474a2fe16389c0df60471922f38e7dcfc637ef/src/main/java/org/apache/sling/graphql/schema/aggregator/impl/ProviderBundleTracker.java#L48],
>  I think the idea is for that class to efficiently ignore bundles which are 
> not provider bundles.
> However I don't think this is more efficient than just having 
> {{addingBundle(...)}} test for the {{Sling-GraphQL-Schema}} header.
> I would argue that doing the following in that method would be at least as 
> efficient than the current code in terms of ignoring non-provider bundles:
> {code:java}
> @Override
> public Object addingBundle(Bundle bundle, BundleEvent event) {
>   final String providersPath = 
> bundle.getHeaders().get("Sling-GraphQL-Schema");
>   if (providersPath == null) {
> // not interested in that bundle
> return;
>   ...
> {code}
> Currently, requiring this capability means provider bundles must declare both 
> the {{Sling-GraphQL-Schema}} header and the 
> {{sling.graphql-schema-aggregator}} capability. 
> Unless there are definite advantages in having both, I'd be in favor of 
> requiring just the {{Sling-GraphQL-Schema}} header to keep things as simple 
> as possible.
> [~radu] I know you were in favor of using the capability, if we agree that 
> the above code has no performance impact, do you see another benefit of using 
> the capability?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SLING-7534) Release policy - stop providing MD5 and start providing SHA-512 checksums

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-7534:


I have updated https://sling.apache.org/downloads.cgi to include links to the 
sha512 digests ([commit 
bc6efc08|https://github.com/apache/sling-site/commit/bc6efc08c83cdfcb6f00ee7f325626827885926e]),
 with a warning that some sha* links do not work in this transition phase - 
which might last quite a long time or actually forever for older releases that 
won't be updated.

> Release policy - stop providing MD5 and start providing SHA-512 checksums
> -
>
> Key: SLING-7534
> URL: https://issues.apache.org/jira/browse/SLING-7534
> Project: Sling
>  Issue Type: Task
>  Components: Tooling
>Reporter: Robert Munteanu
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: Parent 43
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> See http://www.apache.org/dev/release-distribution#sigs-and-sums , we SHOULD 
> no longer provide MD5 checksums for new releases.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SLING-10229) [LauncherContainer]Set up automated builds for this Docker image

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on SLING-10229:
-

IIUC the goal of this is to build the Docker image using the 
[https://docs.docker.com/docker-hub/builds/advanced/] mechanism, and I suppose 
this happens on the hub.docker.com infrastructure.

If that's correct, do we know if there are limitations in terms of resource 
usage? There might be limitations on how many build requests hub.docker.com 
accepts from a single GitHub organization (which https://github.com/apache/ is) 
in a given time frame.

RTFM links to existing documentation are welcome!

> [LauncherContainer]Set up automated builds for this Docker image 
> -
>
> Key: SLING-10229
> URL: https://issues.apache.org/jira/browse/SLING-10229
> Project: Sling
>  Issue Type: Improvement
>  Components: Feature Model
>Reporter: Stefan Bischof
>Priority: Minor
>
> This is an leftover from an other PR:
> [~rombert]: in  
> [PR|https://github.com/apache/sling-org-apache-sling-feature-launcher/pull/18]
> "I think it would be good to set up automated builds for this Docker image 
> eventually ( not in scope of this PR ). Looking at 
> https://stackoverflow.com/questions/36853002/writing-dockerfile-for-dockerhub-automated-builds,
>  it looks like the Docker build is basically invoking a top-level Dockerfile. 
> Maybe we should move the 'launch' Dockerfile where the plug-in expects it and 
> leave the top-level Dockerfile as an entry point for Dockerhub automated 
> builds?"
> ---
> I am not sure what you mean with `launch`Dockerfile. And that would mean that 
> we have 2 files?
> The Docker Hub automated build uses a file, that could be specified in 
> Docker-hub. They use the Tag/Branch as the version tag of the image. But we 
> are holding the version just inside maven. So I am not sure that this 
> automated build from the Dockerhub-side is the best way. And we are back at 
> the point where we have to find a way to copy the launcher-${version].jar 
> without changing the Dockerfile in every version just because of the 
> different names. 
> I would really like to have this official container automated in the docker 
> hub.
> But I do not know how to solve this with your CI-Tooling / Access rights on 
> DockerHub.
> Having an jenkins that builds every commit with the -P container option and 
> pushes the images would be the easiest way.
> regards
> Stefan



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (SLING-10622) Query type is required in the aggregated GraphQL schema

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz resolved SLING-10622.
-
Resolution: Fixed

Fixed by commit 
[b9d8322|https://github.com/apache/sling-org-apache-sling-graphql-schema-aggregator/commit/b9d8322e237012bc75e3b080835a63c4c10db7a3]

> Query type is required in the aggregated GraphQL schema
> ---
>
> Key: SLING-10622
> URL: https://issues.apache.org/jira/browse/SLING-10622
> Project: Sling
>  Issue Type: Improvement
>  Components: GraphQL
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Fix For: GraphQL Schema Aggregator 0.0.2
>
>
> Even if a schema only uses Mutation, which might be valid for a schema that's 
> only about commands for example, the Query type is required.
> The aggregator should always generate a "type Query {}" in the output, even 
> if it is empty.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (SLING-10623) CLONE - Query type is required in the aggregated GraphQL schema

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz updated SLING-10623:

Fix Version/s: (was: GraphQL Schema Aggregator 0.0.2)

> CLONE - Query type is required in the aggregated GraphQL schema
> ---
>
> Key: SLING-10623
> URL: https://issues.apache.org/jira/browse/SLING-10623
> Project: Sling
>  Issue Type: Improvement
>  Components: GraphQL
>Reporter: Madison 
>Assignee: Bertrand Delacretaz
>Priority: Minor
>
> Even if a schema only uses Mutation, which might be valid for a schema that's 
> only about commands for example, the Query type is required.
> The aggregator should always generate a "type Query {}" in the output, even 
> if it is empty.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (SLING-10623) CLONE - Query type is required in the aggregated GraphQL schema

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz resolved SLING-10623.
-
Resolution: Duplicate

> CLONE - Query type is required in the aggregated GraphQL schema
> ---
>
> Key: SLING-10623
> URL: https://issues.apache.org/jira/browse/SLING-10623
> Project: Sling
>  Issue Type: Improvement
>  Components: GraphQL
>Reporter: Madison 
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Fix For: GraphQL Schema Aggregator 0.0.2
>
>
> Even if a schema only uses Mutation, which might be valid for a schema that's 
> only about commands for example, the Query type is required.
> The aggregator should always generate a "type Query {}" in the output, even 
> if it is empty.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (SLING-10620) GraphQL schema aggregator parser should fail on invalid section names

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz resolved SLING-10620.
-
Resolution: Fixed

Implemented in commit 
[d842942b|https://github.com/apache/sling-org-apache-sling-graphql-schema-aggregator/commit/d842942b2b23227ad39daf844639cf5a52c04de2]

> GraphQL schema aggregator parser should fail on invalid section names
> -
>
> Key: SLING-10620
> URL: https://issues.apache.org/jira/browse/SLING-10620
> Project: Sling
>  Issue Type: Bug
>  Components: GraphQL
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Fix For: GraphQL Schema Aggregator 0.0.2
>
>
> Using REQUIRE instead of REQUIRES in a partial schema, for example, should 
> cause a parsing error.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (SLING-10622) Query type is required in the aggregated GraphQL schema

[Bertrand Delacretaz (Jira)]

Bertrand Delacretaz created SLING-10622:
---

 Summary: Query type is required in the aggregated GraphQL schema
 Key: SLING-10622
 URL: https://issues.apache.org/jira/browse/SLING-10622
 Project: Sling
  Issue Type: Improvement
  Components: GraphQL
Reporter: Bertrand Delacretaz
Assignee: Bertrand Delacretaz
 Fix For: GraphQL Schema Aggregator 0.0.2


Even if a schema only uses Mutation, which might be valid for a schema that's 
only about commands for example, the Query type is required.

The aggregator should always generate a "type Query {}" in the output, even if 
it is empty.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (SLING-10621) Fail more loudly when GraphQL schema partials are missing

[Bertrand Delacretaz (Jira)]

Bertrand Delacretaz created SLING-10621:
---

 Summary: Fail more loudly when GraphQL schema partials are missing
 Key: SLING-10621
 URL: https://issues.apache.org/jira/browse/SLING-10621
 Project: Sling
  Issue Type: Improvement
  Components: GraphQL
Reporter: Bertrand Delacretaz
 Fix For: GraphQL Schema Aggregator 0.0.2


Currently, missing or invalid schema partials are only logged. They should 
cause "louder" failures to make them obvious.

Maybe failing to generate schema that would use them, with descriptive error 
messages.

A Schema Aggregator Health Check might also be useful to expose such errors.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (SLING-10619) Remove sling.graphql-schema-aggregator capability if not useful

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz updated SLING-10619:

Issue Type: Improvement  (was: Task)

> Remove sling.graphql-schema-aggregator capability if not useful
> ---
>
> Key: SLING-10619
> URL: https://issues.apache.org/jira/browse/SLING-10619
> Project: Sling
>  Issue Type: Improvement
>  Components: GraphQL
>Reporter: Bertrand Delacretaz
>Priority: Minor
> Fix For: GraphQL Schema Aggregator 0.0.2
>
>
> The {{ProviderBundleTracker}} currently requires provider bundles to define 
> an [OSGi 
> capability|https://github.com/apache/sling-org-apache-sling-graphql-schema-aggregator/blob/04474a2fe16389c0df60471922f38e7dcfc637ef/src/main/java/org/apache/sling/graphql/schema/aggregator/impl/ProviderBundleTracker.java#L48],
>  I think the idea is for that class to efficiently ignore bundles which are 
> not provider bundles.
> However I don't think this is more efficient than just having 
> {{addingBundle(...)}} test for the {{Sling-GraphQL-Schema}} header.
> I would argue that doing the following in that method would be at least as 
> efficient than the current code in terms of ignoring non-provider bundles:
> {code:java}
> @Override
> public Object addingBundle(Bundle bundle, BundleEvent event) {
>   final String providersPath = 
> bundle.getHeaders().get("Sling-GraphQL-Schema");
>   if (providersPath == null) {
> // not interested in that bundle
> return;
>   ...
> {code}
> Currently, requiring this capability means provider bundles must declare both 
> the {{Sling-GraphQL-Schema}} header and the 
> {{sling.graphql-schema-aggregator}} capability. 
> Unless there are definite advantages in having both, I'd be in favor of 
> requiring just the {{Sling-GraphQL-Schema}} header to keep things as simple 
> as possible.
> [~radu] I know you were in favor of using the capability, if we agree that 
> the above code has no performance impact, do you see another benefit of using 
> the capability?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (SLING-10620) GraphQL schema aggregator parser should fail on invalid section names

[Bertrand Delacretaz (Jira)]

Bertrand Delacretaz created SLING-10620:
---

 Summary: GraphQL schema aggregator parser should fail on invalid 
section names
 Key: SLING-10620
 URL: https://issues.apache.org/jira/browse/SLING-10620
 Project: Sling
  Issue Type: Bug
  Components: GraphQL
Reporter: Bertrand Delacretaz
Assignee: Bertrand Delacretaz
 Fix For: GraphQL Schema Aggregator 0.0.2


Using REQUIRE instead of REQUIRES in a partial schema, for example, should 
cause a parsing error.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (SLING-10619) Remove sling.graphql-schema-aggregator capability if not useful

[Bertrand Delacretaz (Jira)]

Bertrand Delacretaz created SLING-10619:
---

 Summary: Remove sling.graphql-schema-aggregator capability if not 
useful
 Key: SLING-10619
 URL: https://issues.apache.org/jira/browse/SLING-10619
 Project: Sling
  Issue Type: Task
  Components: GraphQL
Reporter: Bertrand Delacretaz
 Fix For: GraphQL Schema Aggregator 0.0.2


The {{ProviderBundleTracker}} currently requires provider bundles to define an 
[OSGi 
capability|https://github.com/apache/sling-org-apache-sling-graphql-schema-aggregator/blob/04474a2fe16389c0df60471922f38e7dcfc637ef/src/main/java/org/apache/sling/graphql/schema/aggregator/impl/ProviderBundleTracker.java#L48],
 I think the idea is for that class to efficiently ignore bundles which are not 
provider bundles.

However I don't think this is more efficient than just having 
{{addingBundle(...)}} test for the {{Sling-GraphQL-Schema}} header.

I would argue that doing the following in that method would be at least as 
efficient than the current code in terms of ignoring non-provider bundles:
{code:java}
@Override
public Object addingBundle(Bundle bundle, BundleEvent event) {
  final String providersPath = bundle.getHeaders().get("Sling-GraphQL-Schema");
  if (providersPath == null) {
// not interested in that bundle
return;
  ...
{code}
Currently, requiring this capability means provider bundles must declare both 
the {{Sling-GraphQL-Schema}} header and the {{sling.graphql-schema-aggregator}} 
capability. 

Unless there are definite advantages in having both, I'd be in favor of 
requiring just the {{Sling-GraphQL-Schema}} header to keep things as simple as 
possible.

[~radu] I know you were in favor of using the capability, if we agree that the 
above code has no performance impact, do you see another benefit of using the 
capability?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (SLING-10551) New module to assemble GraphQL schemas from partials

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz resolved SLING-10551.
-
Resolution: Fixed

The aggregator has moved to 
https://github.com/apache/sling-org-apache-sling-graphql-schema-aggregator, 
marking this ticket resolved as the initial code is ready.

> New module to assemble GraphQL schemas from partials
> 
>
> Key: SLING-10551
> URL: https://issues.apache.org/jira/browse/SLING-10551
> Project: Sling
>  Issue Type: Improvement
>  Components: GraphQL
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
>
> I need to assemble GraphQL schemas from partial schemas ("partials") provided 
> by multiple bundles.
> A schema can only contain a single {{query}} and a single {{mutation}} 
> section, so the partials  cannot simply be concatenated, they need to be 
> parsed and reassembled.
> I have created an initial spec for this module at 
> https://github.com/apache/sling-whiteboard/tree/master/sling-org-apache-sling-graphql-schema



--
This message was sent by Atlassian Jira
(v8.3.4#803005)