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

Re: [VOTE] Release Apache Resource Resolver 1.11.6

[Bertrand Delacretaz]

   [X ] +1 Approve the release

Julian's signature 44F4797A52C336FA666CD9271DE461528F1F1B2A was
missing from https://downloads.apache.org/sling/KEYS , I have added it
[1] from [0], it should appear in a few minutes.

-Bertrand

[0] https://downloads.apache.org/jackrabbit/KEYS

[1] FWIW, here's how to add a key
svn co https://dist.apache.org/repos/dist/release/sling --depth empty
cd sling
svn up KEYS
# edit KEYS as needed
svn diff
svn commit -m ...

Re: [VOTE] Release Apache Sling GraphQL Core 0.0.28

[Bertrand Delacretaz]

[X ] +1 Approve the release

-Bertrand

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

Re: [RT] Path to Jakarta Servlet Specification

[Bertrand Delacretaz]

Hi,

On Sun, Oct 1, 2023 at 3:59 PM Carsten Ziegeler  wrote:
> ..It seems the Java world around us is moving to Jakarta and if we want to
> benefit from upcoming new features in that world, we eventually have to
> move...

The move looks like a lot of work, so I think we should be able to
list actual benefits before deciding to do it.

Especially if there's a cost to users of the Sling APIs - the overall
cost can be huge.

Do people know what exactly we might miss by not moving?

Are there areas where the current servlet APIs prevent Sling's progress ?

> ...Option 3: do nothing now and wait until this switch is actually becoming
> a real problem...

That would be my preferred option right now, but answers to my above
questions might change that.

-Bertrand

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

Re: Sling Models Constructor Injection

[Bertrand Delacretaz]

On Tue, Jun 27, 2023 at 9:05 AM Konrad Windszus  wrote:
> ...If someone can confirm that both levels are supported for constructor 
> injection
> I am gonna adjust our documentation...

Well, "someone" should be "automated tests", right? Otherwise it
didn't happen ;-)

-Bertrand

Re: FYI, new "project state" information in Board reports

[Bertrand Delacretaz]

On Fri, May 26, 2023 at 10:23 AM Robert Munteanu  wrote:
> ...I've updated the draft accordingly...

Thank you! The Sling report is the first one ever to be submitted with
this new project status info, /me proud ;-)

-Bertrand

FYI, new "project state" information in Board reports

[Bertrand Delacretaz]

Hi,

FYI, the Board recently updated the reporting guidelines [1] to ask
projects to include a "project state" information in project reports,
using a finite set of keywords such as New, Ongoing, Dormant etc.

The https://reporter.apache.org/wizard/ has been updated to ask for
this information, which for Sling might look like:

> ## Project Status:
> Current project status: Ongoing, with moderate activity.
> Issues for the board: none.

-Bertrand

[1] https://www.apache.org/foundation/board/reporting#guidelines

Re: Please welcome Julian Reschke

[Bertrand Delacretaz]

Julian Reschke  wrote:
> ...When I'm not working on Apache stuff, I occasionally spend time working
> in the standards space in the IETF; you might have seen my name on a few
> RFCs...

I definitely have ;-)

It's an honor to have you here Julian, thank you and thanks for all
your good work on Sling!

-Bertrand

Re: RepoInit: Intended behaviour in case of failures and backwards-compatibility

[Bertrand Delacretaz]

Hi,

Eric Norman  wrote:
> ...I apologise for trying to be proactive.  It seems my opinions don't matter
> here...

They do matter, and I'm sorry if whatever I wrote made you feel otherwise.

The use case that you mentioned does not fit the way I use Sling:

> ...In other words, if someone else already created a path (with the
> wrong types) that you are not expecting to be there, then failing right
> away seems like a reasonable solution...

So I considered that having a variant of "set node" that fails if
paths already exist does not seem useful *at this point*. And it would
actually get in the way for my use cases - but I could of course
refrain from using it.

Not implementing that variant now does not prevent someone from
implementing it later. I don't think it's useful myself, and I might
have more (unwanted) weight in these discussions as I worked a lot on
repoinit in its beginnings. But don't let that stop you.

-Bertrand

Re: RepoInit: Intended behaviour in case of failures and backwards-compatibility

[Bertrand Delacretaz]

Hi,

Konrad Windszus  wrote:

> ...So I will for now only update 
> https://github.com/apache/sling-org-apache-sling-repoinit-parser/pull/27 
>  
> with
>
> Instruction "ensure node" (for creating or updating node(s) with primary and 
> mixin type)

works for me but I think it should be "nodes" and not "node" as a
typical instruction will touch multiple nodes.

Also, I would prefer "set" over "ensure" as we already have "set
properties" with a similar behavior in the language.

So my preference goes to "set nodes ...", but if the majority prefers
"ensure nodes" that also works.

-Bertrand

Re: RepoInit: Intended behaviour in case of failures and backwards-compatibility

[Bertrand Delacretaz]

Hi,

I agree with deprecating "create path" and implementing new instructions.

But I'm not sure why you would need two new instructions:

Konrad Windszus  wrote:
...
> a) ensure node (for creating or updating node(s) with primary and mixin type)
> b) update node (for just updating existing node(s) with primary and mixin 
> type).
...

In both cases, you want the specified nodes to be exactly as described
in the statement, so why two instructions?

What would "update node" do if not all nodes exist yet, fail? Do
nothing? Both are not good IMO.

Whoever writes the repoinit script specifies an end state, I don't
think they care about the previous state, so I think just "create
node" is sufficient and simpler to implement.

But it's actually not a single node that's being created or updated,
it's the whole subtree, when you write something like

create node (nt:folder) /one(mixin nt:art)/step(mixin nt:dance)/two/steps

You're actually touching up to 4 nodes...I think "create nodes" or
"set nodes" is a better name for this new instruction.

-Bertrand

Re: RepoInit: Intended behaviour in case of failures and backwards-compatibility

[Bertrand Delacretaz]

Konrad Windszus  wrote:
> ...I would really appreciate direct feedback in the GH PR (where you are 
> reviewer BTW ;-))...

Sure, but I also want to see if others agree with the general
principles proposed in this thread.

-Bertrand

Re: RepoInit: Intended behaviour in case of failures and backwards-compatibility

[Bertrand Delacretaz]

Konrad Windszus  wrote:
> ...I don’t like this for the reasons outlined at 
> https://github.com/apache/sling-org-apache-sling-jcr-repoinit/pull/41#issuecomment-1354488929
>
> "From an end user perspective deprecating one statement and introducing a new 
> one with a more concise name is better than just adding the option strict to 
> existing statements with fuzzy names like “path”:...

So (assumption A) for SLING-11736 you would add a completely new
"create node" command, that has the exact same behavior as "create
path" except for the behavior changes of SLING-11736 ?

If that's correct, I prefer adding a [strict] option to activate this
new behavior, as that makes the language smaller overall, which is a
good thing in my book.

But that's just different styles in the end, if my assumption A is
correct I guess we'll need someone else to express their preference to
see where the majority is.

-Bertrand

Re: RepoInit: Intended behaviour in case of failures and backwards-compatibility

[Bertrand Delacretaz]

Hi,

Konrad Windszus wrote:
> ...There are some issues with RepoInit with regards to failure behaviour like 
> [1] and [2]...

I think we should keep the existing principles in repoinit, and as you
say clarify them in the documentation:

- repoinit is strictly backwards compatible, we try very hard to avoid
any changes in its behavior for existing scripts
- failing statements prevent the content repository from starting, to
avoid exposing potentially harmful states
- the language can evolve in a backwards compatible way to improve or
clarify the repoinit behavior
- we strive to keep the language evolutions minimalistic, clean and
independent of implementation details

So in the case of SLING-11736 I have proposed adding a [strict] option
to "create path", exemple:

  create path [strict] (nt:folder) /one(mixin nt:art)/step(mixin
nt:dance)/two/steps

which activates the improved behavior proposed in that ticket
(adjusting primary + mixin types of existing nodes if needed), without
changing the behavior for existing code.

I think that's inline with the above principles, WDYT?

-Bertrand

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

Re: Status Module "Sling Scripting ESX"

[Bertrand Delacretaz]

Hi Joerg,


Le jeu. 29 sept. 2022 à 13:03, Jörg Hoh
 a écrit :
> ...Are there any users of this module out there which are interested in it?

I think it's safe to assume that that module remained an experimental
contribution (as mentioned in its README), commits after April 2017
are just housekeeping and it was never released AFAICS.

I suggest deprecating it as per [2], that can always be undone if
someone wants to resurrect it later.

-Bertrand

> [1]
> https://github.com/apache/sling-org-apache-sling-scripting-esx/commits/master
[2] 
https://sling.apache.org/documentation/development/deprecating-sling-modules.html

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

Re: [VOTE] Release Apache Sling GraphQL Core 0.0.14

[Bertrand Delacretaz]

Le mar. 30 août 2022 à 18:25, Radu Cotescu  a écrit :
> ...Please vote to approve this release..

+1

-Bertrand

Re: Releases out of the whiteboard repo?

[Bertrand Delacretaz]

Hi,

Le mer. 22 juin 2022 à 12:32, Jörg Hoh
 a écrit :
> ...I am not sure if I should
> request a dedicated repository for it ("sling-jmx-exporter"), because it's
> really a tiny function...

Unless you can include that function in an existing module I have no
problem with small repositories - we know how to handle those.

> ...Doing a release on the whiteboard would have solved
> my requirement perfectly...

I think it's good to keep the whiteboard for (often wildly)
experimental things, and releasing from there might cause confusion.

-Bertrand

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

SlingRequestDispatcher and nested forwards

[Bertrand Delacretaz]

Hi,

A colleague mentioned getting "SlingRequestProcessorImpl Writer has
already been closed" error messages when using
SlingRequestDispatcher.forward(...), and looking at the code [1] I
wonder if we should change the request flushing behavior.

Unfortunately, unless I missed something that code is not covered by
units tests, but I suppose nested calls to
SlingRequestDispatcher.forward(...) would cause the problem:
SlingRequestDispatcher blindly calls response.flushBuffer(), which
causes logged errors if the response Writer is already closed. So if a
Servlet that's been forwarded to calls
SlingRequestDispatcher.forward(...) I suppose we get this problem.

I could write a test to verify all that of course, but maybe someone
already has a clear idea on this.

Shall we modify that code to check the request status before calling
flushBuffer() ? I don't think there's a direct way to check if the
Writer is closed already, but maybe there's another call on the
request that would check that?

-Bertrand

[1] 
https://github.com/apache/sling-org-apache-sling-engine/blob/631a54f45abf5fd6d7c56dac43fd499db543bcd7/src/main/java/org/apache/sling/engine/impl/request/SlingRequestDispatcher.java#L151

Re: Improve JSON serialization and response data types

[Bertrand Delacretaz]

Le ven. 3 juin 2022 à 11:46, Julian Reschke  a écrit :
> ...I believe the answer is javax.json.

Yes, many "newer" Sling modules are using that.

I think the homegrown JSON code is here for historical reasons.

If someone wants to change that that's fine, but backwards
compatibility has to be preserved.

The strong modularity of Sling means it's not necessarily a problem
(even if not optimal) to use different techniques in different
modules. To be evaluated on a case-by-case basis, IMO.

-Bertrand

Re: Should Sling refuse to register multiple servlets with the same mount parameters?

[Bertrand Delacretaz]

Le mer. 11 mai 2022 à 17:32, Konrad Windszus  a écrit :
> ...Service IDs are always unique, so this mechanism will always establish one 
> winner!..

Yes, but that winner is not predictable from the programmer's point of
view, that's why I'd like us to reject cases where it's the Service ID
that defines behavior, or at least log a warning if they happen.

-Bertrand

Re: Should Sling refuse to register multiple servlets with the same mount parameters?

[Bertrand Delacretaz]

Hi,

Le mer. 11 mai 2022 à 17:23, Carsten Ziegeler  a écrit :
> ...Service ranking is more predictable than just using the "first"...

I agree, but what if two servlets have the exact same service
parameters including service ranking?

That's what I think we should reject.

-Bertrand

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

Should Sling refuse to register multiple servlets with the same mount parameters?

[Bertrand Delacretaz]

Hi,

I forgot if we discussed this already, if that's the case pointers are welcome.

Adrian Kozma created SLING-11315 about this, and I tentatively added a
new test [1] to explore the current behavior.

It looks like the first registered servlet wins, but that might be
just by chance.

Do people agree that Sling should refuse to register servlets that
have the same set of mount parameters as existing ones?

I think that would help avoid difficult to troubleshoot situations.

-Bertrand

[1] 
https://github.com/apache/sling-org-apache-sling-servlets-resolver/commit/1603a0ecb2ab8b4395560c0d53d9e5569b68a568

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

Re: [starter] Tentative JBang starter script

[Bertrand Delacretaz]

Hi Robert,

Le mer. 23 mars 2022 à 11:02, Robert Munteanu  a écrit :
> ...I don't have a strong opinion on where this ends up. It would be nice
> to include 'starter' somewhere in the same; we can potentially launch
> e.g. the Sling CMS or other Sling applications using JBang and should
> IMO make early on the distinction about what part of Sling we are
> launching

We might also have other types of scripts, how about a new
sling-scripts repository for this?

And then set it up so that the Sling Starter can be started with

   jbang starter@apache/sling-scripts

And if we want to start other things later, instead of "starter" those
can use "cms", "colossal-cave", etc.

While leaving space in that repository for other types of scripts, if
needed. The JBang setup just needs a jbang-catalog.json at the root,
with the corresponding scripts in subfolders as desired.

WDYT?

-Bertrand

[starter] Tentative JBang starter script

[Bertrand Delacretaz]

Hi,

I've written a tentative script to start the Sling Starter 12 with jbang,
at [1],

To try it, install https://www.jbang.dev and run

   jbang start@apache/sling-whiteboard

Optionally with Feature Launcher options at the end ( try -h )

If we think this is useful we might create a dedicated GitHub repository
for such JBang scripts, to avoid having "whiteboard" in the command line.

Feedback is welcome!

-Bertrand

[1]
https://github.com/apache/sling-whiteboard/blob/master/jbang/SlingStarter.java

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

Re: Enable Web Analytics with Matomo?

[Bertrand Delacretaz]

Hi,

Le lun. 7 mars 2022 à 16:34, Konrad Windszus  a écrit :
>... WDYT about enabling web analytics with Matomo to learn more about our 
>visitors?..

I'm +0, meaning If someone wants to do the work I'm all for it.

-Bertrand

Re: [VOTE] Release Apache Sling Repoinit Parser 1.6.14, Apache Sling Repoinit JCR 1.1.38

[Bertrand Delacretaz]

Le jeu. 3 mars 2022 à 10:56, ang...@apache.org  a écrit :
...
> Please vote to approve this release:

+1

-Bertrand

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

Re: Marking issues to attract new contributors

[Bertrand Delacretaz]

On Thu, Jan 20, 2022 at 10:11 AM Dirk Rudolph  wrote:
>...Regarding the naming, we may want to adapt the naming
> Github uses for that: "good-first-issue"..

+1

-Bertrand

Re: PATCH support in SlingAllMethodsServlet

[Bertrand Delacretaz]

On Fri, Dec 17, 2021 at 2:14 PM Carsten Ziegeler  wrote:
> Interestingly even servlet api 5 has no notion of patch ...

Interesting indeed...and we might have a similar problem soon if (like
I hope) QUERY [1] becomes a thing.

-Bertrand

[1] 
https://www.ietf.org/archive/id/draft-ietf-httpbis-safe-method-w-body-02.html

Re: PATCH support in SlingAllMethodsServlet

[Bertrand Delacretaz]

Hi Radu,

On Fri, Dec 17, 2021 at 1:46 PM Radu Cotescu  wrote:
>... Adding a method to this class should be a minor change to the API, unless 
>I’m missing something...

I was thinking of potential problems if classes have inherited from
SlingAllMethodsServlet and added their own mechanism to handle PATCH.
But if they've done that correctly that shouldn't be a problem. Or at
least I cannot think of a concrete case where this might be a problem.

-Bertrand

Re: PATCH support in SlingAllMethodsServlet

[Bertrand Delacretaz]

Hi,

On Fri, Dec 17, 2021 at 11:59 AM Radu Cotescu  wrote:
> ...is there a specific reason for which we haven’t yet added support for PATCH
> in SlingAllMethodsServlet [0]?...

I don't see why we wouldn't support it, as long as we keep backwards
compatibility in mind.

-Bertrand

Re: Log4Shell

[Bertrand Delacretaz]

Hi,

On Mon, Dec 13, 2021 at 11:36 AM Carsten Ziegeler  wrote:
> ...we could state that Sling based applications are not affected if they
> use the standard logging setup with commons log and log4j-over-slf4j and
> if there no application bundles embedding a vulnerable log4j version...

Isn't there a (vague) risk that one of our transitive dependencies
embeds log4j2 ?

If we make a statement I think it should include the list of modules
we have checked as "not embedding log4j2" and describe the method used
for that check.

I suppose running "mvn dependency:tree | grep " is a
reasonable way of checking, so maybe this can be the script used to
check, from the top of a complete checkout of the Sling modules:

  $ export PATTERN=
  $ find . -name pom.xml | while read pom; do pushd $(dirname $pom);
mvn dependency:tree | grep $PATTERN ; popd ; done

-Bertrand

Re: Proposal: Recommend mechanism for launching the feature-model based Starter

[Bertrand Delacretaz]

Hi Robert,

On Wed, Dec 8, 2021 at 11:43 AM Robert Munteanu  wrote:
> ...For the Sling Starter, it would be great if you could find the time to
> add an entry to the wiki page [1] so we can see how it compares with
> the other entries...

Done, and IMHO I see JBang as a winner: simple installation, simple
usage, flexible glue scripts (probably in a new sling-scripts
repository)

-Bertrand

> [1]:
> https://cwiki.apache.org/confluence/display/SLING/Recommend+mechanism+for+launching+the+feature-model+based+Starter

Re: Proposal: Recommend mechanism for launching the feature-model based Starter

[Bertrand Delacretaz]

Hi,

On Fri, Dec 3, 2021 at 4:55 PM Robert Munteanu  wrote:
> ...In the context of the upcoming Sling 12 launch we should settle on a
> recommended mechanism for launching the Sling Starter...

I don't remember us discussing jbang but it might be a good alternative.

As a demo I have setup a stub startup script [1] which you can call with

  jbang start@apache/sling-whiteboard -p 1234

After installing jbang if needed from [2], without even requiring a
JVM to be preinstalled. The right JVM version can be selected by the
script [5].

Another example [3] parses a repoinit script after downloading the
required dependencies listed in the script with //DEPS :

  echo "create path /itworks" | jbang repoinitValidator@apache/sling-whiteboard

The mapping between those jbang commands and the scripts happens via a
jbang catalog JSON file at [4].

I think this would be a nice way of creating the necessary glue to
start Sling from scratch, and the instructions fit in a tweet which I
like a lot ;-)

We'd probably create a specific repository for those scripts, so the
above commands would use sling-start instead of sling-whiteboard.

-Bertrand

[1] https://github.com/apache/sling-whiteboard/blob/master/start.java
[2] https://www.jbang.dev/download/
[3] 
https://github.com/apache/sling-whiteboard/blob/master/jbang/RepoinitValidator.java
[4] https://github.com/apache/sling-whiteboard/blob/master/jbang-catalog.json
[5] https://www.jbang.dev/documentation/guide/latest/javaversions.html

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

Re: Maven Archetypes

[Bertrand Delacretaz]

Hi,

On Fri, Oct 8, 2021 at 10:35 AM Robert Munteanu  wrote:
> ...Thanks for looking into this. We do have lots of archetypes, and
> technically all of them are supported, even the launchpad one...

Technically yes, but in practice not really, until someone is willing
to spend time maintaining them.

Shall we mark those archetypes as deprecated for now?

It would make the situation clearer, that doesn't prevent people from
using them, and that status can be reverted if someone wants to work
on them later.

-Bertrand

Re: Add builders to create request/response objects

[Bertrand Delacretaz]

On Thu, Sep 30, 2021 at 10:23 AM Carsten Ziegeler  wrote:
> ...I'll probably create a prototype in the whiteboard which we then can
> further discuss..

+1, and note that the InternalRequest and child classes at [1] already
define a "builder protocol" that can probably apply in the same way to
creating a Request object. We'll probably need to unify those, maybe
create a Java interface for that builder that both variants implement.

-Bertrand

Re: Add builders to create request/response objects

[Bertrand Delacretaz]

Hi,

On Wed, Sep 29, 2021 at 6:40 PM Carsten Ziegeler  wrote:
> ...we should probably have some proper
> API to create an initial request and response without backing it out or
> wrapping an existing request / response...

IIUC you mean a service or utility class that provides objects that
implement SlingHttpServletRequest and SlingHttpServletResponse and can
be used for example with the SlingRequestProcessor service?

That works for me, just wanted to make sure I understand.

> ...I don't have any real preference, API is probably the better location as
> this is general purpose functionality which can be used without the
> processor...

I agree that the API bundle is a good place, with the new class or
service in its own package to avoid interference with other things.

-Bertrand

[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 p

[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 

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

Re: Release Management doc question

[Bertrand Delacretaz]

On Tue, Aug 31, 2021 at 12:27 PM Bertrand Delacretaz
 wrote:
...
> https://github.com/apache/sling-site/commit/bd12870ac - should be live
> soon at 
> https://sling.apache.org/documentation/development/release-management.html
...

Also removed duplicated details about public key servers, in the next commit.

-Bertrand

Re: Release Management doc question

[Bertrand Delacretaz]

Hi,

On Mon, Jul 19, 2021 at 9:48 PM Henry Saginor  wrote:
> ...It looks like key server sks-keyservers.net  
> has been deprecated and is no longer maintained

As suggested by Konrad, I have updated the release management page to
point to the ASF infra reference:

https://github.com/apache/sling-site/commit/bd12870ac - should be live
soon at 
https://sling.apache.org/documentation/development/release-management.html

A more extensive reworking of Appendix A might be useful, but I think
it's already better in terms of not duplicating too much information.

-Bertrand

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

Re: [DISCUSS] Sling RepoInit Webconsole

[Bertrand Delacretaz]

On Fri, Aug 6, 2021 at 2:40 PM Bertrand Delacretaz
 wrote:
> ...Jbang scripts [1] for example might be a nice way to do that...

I tried that [1] and that works well, at least if your goal is only to
check the syntax of repoinit scripts.

To run that script, use:

$ jbang trust add https://github.com/apache/sling-whiteboard/

$ cat > /tmp/xx <https://github.com/apache/sling-whiteboard/blob/master/jbang/RepoinitValidator.java
< /tmp/xx
Repoinit parsing successful:
[CreatePath [testing], CreateUser leonardo]

The alias+catalog features of jbang [2] would allow for using a
simpler script name.

To go further and apply the repoinit operations to an actual
repository you'd need to pull in more bundles, I haven't tried if
that's practical or if you'd end up downloading half the Web.

-Bertrand

[1] 
https://github.com/apache/sling-whiteboard/blob/master/jbang/RepoinitValidator.java
[2] https://www.jbang.dev/documentation/guide/latest/alias_catalogs.html

Re: [DISCUSS] Sling RepoInit Webconsole

[Bertrand Delacretaz]

Hi Dan,

On Fri, Aug 6, 2021 at 3:55 PM Daniel Klco  wrote:
> On Fri, Aug 6, 2021 at 8:40 AM Bertrand Delacretaz 
> wrote:
> >...I think nowadays we'd rather create command-line
> > utilities for such things,...

> ...The question I have though is how would I get access to the running OSGi
> context? I've done JCR over RMI, but I'm not seeing a good way to invoke
> services remotely...

I think you either need a specific servlet on the Sling side, which
kind of defeats the whole purpose of a command-line tool, or you can
inject code from the client side given the appropriate permissions.
Uploading a Sling script comes to mind, but that won't work if the
target instance uses read-only scripts.

-Bertrand