[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[
https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840756#comment-17840756
]
Radu Cotescu commented on SLING-12300:
--
I've updated the PR to include a configuration flag. Let me know what you
think. I'd like to get this merged by the end of next week.
> Provide a way to retrieve a JCR backed resource by its node identifier
> --
>
> Key: SLING-12300
> URL: https://issues.apache.org/jira/browse/SLING-12300
> Project: Sling
> Issue Type: New Feature
> Components: JCR
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: JCR Resource 3.3.0
>
>
> Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would
> be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}}
> property for referenceable nodes or the path. In systems that would like to
> use UUID addressing, this would reduce the need for executing JCR queries for
> resource retrieval and would avoid double-reads via the JCR and then Sling
> API to obtain the resource.
> In order to provide a unified behaviour, paths starting with the {{/jcr:id/}}
> prefix should use the resource retrieval by node identifier.
> [0] -
> https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier()
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[
https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840164#comment-17840164
]
Radu Cotescu commented on SLING-12300:
--
I’m perfectly fine to have this feature disabled by default, behind a
configuration toggle. I’ll update the PR as soon as I find some time to come
back to this issue. Thanks!
> Provide a way to retrieve a JCR backed resource by its node identifier
> --
>
> Key: SLING-12300
> URL: https://issues.apache.org/jira/browse/SLING-12300
> Project: Sling
> Issue Type: New Feature
> Components: JCR
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: JCR Resource 3.3.0
>
>
> Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would
> be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}}
> property for referenceable nodes or the path. In systems that would like to
> use UUID addressing, this would reduce the need for executing JCR queries for
> resource retrieval and would avoid double-reads via the JCR and then Sling
> API to obtain the resource.
> In order to provide a unified behaviour, paths starting with the {{/jcr:id/}}
> prefix should use the resource retrieval by node identifier.
> [0] -
> https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier()
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[
https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840065#comment-17840065
]
Radu Cotescu commented on SLING-12300:
--
Let's compare the three options we have:
||1. Augmenting the JCR Resource Provider - {{/jcr:id/}}||2. Creating a new
Resource Provider for ID addressing||3. Extending the Resource API||
|Pros:
* simple, low effort implementation
* can be implemented behind a configuration toggle|Pros:
* isolates providers and allows for separate configurations
* since a provider has a mount path, the root for ID addressing is
configurable|Pros:
* brings the IDs as first class citizens to the Resource API
* allows resource retrieval by ID or path without providing any special
prefixes|
|Cons:
* adds a path prefix into the resource tree
* might require setting explicit authentication configurations to not allow
any HTTP browsing under {{/jcr:id}} for unauthenticated users|Cons:
* adds a path prefix into the resource tree (via its mount path)
* might require setting explicit authentication configurations to not allow
any HTTP browsing under its root
* duplicates functionality, since this would also be a JCR provider|Cons:
* must ensure ID uniqueness across Resource Providers
* difficult to implement since the Resource API has a large footprint|
This shows clearly that 2 is not really a different option compared to 1. 3 is
interesting, but I don't think we can solve the uniqueness requirement.
> Provide a way to retrieve a JCR backed resource by its node identifier
> --
>
> Key: SLING-12300
> URL: https://issues.apache.org/jira/browse/SLING-12300
> Project: Sling
> Issue Type: New Feature
> Components: JCR
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: JCR Resource 3.3.0
>
>
> Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would
> be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}}
> property for referenceable nodes or the path. In systems that would like to
> use UUID addressing, this would reduce the need for executing JCR queries for
> resource retrieval and would avoid double-reads via the JCR and then Sling
> API to obtain the resource.
> In order to provide a unified behaviour, paths starting with the {{/jcr:id/}}
> prefix should use the resource retrieval by node identifier.
> [0] -
> https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier()
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[
https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839511#comment-17839511
]
Radu Cotescu edited comment on SLING-12300 at 4/22/24 7:01 AM:
---
[~enorman], nobody trivialised your concerns. I’m not sure if everyone is
familiarised with the UUIDv4 standard that Oak uses for the {{jcr:uuid}}
property and I was just trying to explain the problem space. In addition, you
expressed that there would be security issues by implementing this feature, but
didn’t explain which. Predictability is not a security concern IMO if you
correctly use ACLs.
[~paul.bjorkstrand], for my use-case I only need those resources addressable by
ID at the Java API level. The application that is built on top controls the URL
space, but I wanted to use the Sling API for accessing the resource tree. You
could ask why the contradiction: update the JCR resource provider to use a
feature exposed only by JCR, but consume it via Sling?! Well, the Sling API is
just easier to use and simpler to understand for developers than the JCR one.
Adding a new Resource Provider could also be an option, but in the end it would
perform the same function in the same way: it would offer a way to retrieve
resources by ID from its mount root, whichever that will be.
I also thought about extending the Sling Resource API, but given that right now
only one commonly used provider generates IDs for the resources it creates I
thought it would be too complex and not provide so many gains.
I will obviously not push something that the Sling community doesn’t agree
with, but I would like that we discuss the alternatives and pick the solution
that makes the most sense in terms of effort/benefits.
was (Author: radu.cotescu):
[~enorman], nobody trivialised your concerns. I’m not sure if everyone is
familiarised with the UUIDv4 standard that Oak uses for the {{jcr:uuid}}
property and I was just trying to explain the problem space. In addition, you
expressed that there would be security issues by implementing this feature, but
didn’t explain which. Predictability is not a security concern IMO if you
correctly use ACLs.
[~paul.bjorkstrand], for my use-case I only need those resources addressable by
ID at the Java API level. The application that is built on top controls the URL
space, but I wanted to use the Sling API for accessing the resource tree. You
could ask why the contradiction: update the JCR resource provider to use a
feature exposed only by JCR, but consume it via Sling?! Well, the Sling API is
just easier to use and simpler to understand for developers than the JCR one.
Adding a new Resource Provider could also be an option, but in the end it would
perform the same function in the same way: it would offer a way to retrieve
resources by ID from its mount root, whichever that will be.
I also thought about extending the Sling Resource API, but given that right now
only one commonly use provider generates IDs for the resources it creates I
thought it would be too complex and not provide so many gains.
I will obviously not push something that the Sling community doesn’t agree
with, but I would like that we discuss the alternatives and pick the solution
that makes the most sense in terms of effort/benefits.
> Provide a way to retrieve a JCR backed resource by its node identifier
> --
>
> Key: SLING-12300
> URL: https://issues.apache.org/jira/browse/SLING-12300
> Project: Sling
> Issue Type: New Feature
> Components: JCR
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: JCR Resource 3.3.0
>
>
> Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would
> be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}}
> property for referenceable nodes or the path. In systems that would like to
> use UUID addressing, this would reduce the need for executing JCR queries for
> resource retrieval and would avoid double-reads via the JCR and then Sling
> API to obtain the resource.
> In order to provide a unified behaviour, paths starting with the {{/jcr:id/}}
> prefix should use the resource retrieval by node identifier.
> [0] -
> https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier()
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[
https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839511#comment-17839511
]
Radu Cotescu commented on SLING-12300:
--
[~enorman], nobody trivialised your concerns. I’m not sure if everyone is
familiarised with the UUIDv4 standard that Oak uses for the {{jcr:uuid}}
property and I was just trying to explain the problem space. In addition, you
expressed that there would be security issues by implementing this feature, but
didn’t explain which. Predictability is not a security concern IMO if you
correctly use ACLs.
[~paul.bjorkstrand], for my use-case I only need those resources addressable by
ID at the Java API level. The application that is built on top controls the URL
space, but I wanted to use the Sling API for accessing the resource tree. You
could ask why the contradiction: update the JCR resource provider to use a
feature exposed only by JCR, but consume it via Sling?! Well, the Sling API is
just easier to use and simpler to understand for developers than the JCR one.
Adding a new Resource Provider could also be an option, but in the end it would
perform the same function in the same way: it would offer a way to retrieve
resources by ID from its mount root, whichever that will be.
I also thought about extending the Sling Resource API, but given that right now
only one commonly use provider generates IDs for the resources it creates I
thought it would be too complex and not provide so many gains.
I will obviously not push something that the Sling community doesn’t agree
with, but I would like that we discuss the alternatives and pick the solution
that makes the most sense in terms of effort/benefits.
> Provide a way to retrieve a JCR backed resource by its node identifier
> --
>
> Key: SLING-12300
> URL: https://issues.apache.org/jira/browse/SLING-12300
> Project: Sling
> Issue Type: New Feature
> Components: JCR
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: JCR Resource 3.3.0
>
>
> Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would
> be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}}
> property for referenceable nodes or the path. In systems that would like to
> use UUID addressing, this would reduce the need for executing JCR queries for
> resource retrieval and would avoid double-reads via the JCR and then Sling
> API to obtain the resource.
> In order to provide a unified behaviour, paths starting with the {{/jcr:id/}}
> prefix should use the resource retrieval by node identifier.
> [0] -
> https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier()
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[
https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839166#comment-17839166
]
Radu Cotescu commented on SLING-12300:
--
In case you were to build an application that provided web resources identified
by UUIDs, this would allow for efficient resource-by-id retrieval compared to
what you'd have to do without this support at the Resource Provider level.
> Provide a way to retrieve a JCR backed resource by its node identifier
> --
>
> Key: SLING-12300
> URL: https://issues.apache.org/jira/browse/SLING-12300
> Project: Sling
> Issue Type: New Feature
> Components: JCR
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: JCR Resource 3.3.0
>
>
> Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would
> be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}}
> property for referenceable nodes or the path. In systems that would like to
> use UUID addressing, this would reduce the need for executing JCR queries for
> resource retrieval and would avoid double-reads via the JCR and then Sling
> API to obtain the resource.
> In order to provide a unified behaviour, paths starting with the {{/jcr:id/}}
> prefix should use the resource retrieval by node identifier.
> [0] -
> https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier()
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[
https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839151#comment-17839151
]
Radu Cotescu commented on SLING-12300:
--
{quote}
I could get a match on the first try if I get lucky. Basically, I'm not
putting a server on the public internet with predictable addresses.
{quote}
We're talking about UUIDs in this case, which are anything but predictable.
Paths are definitely more predictable if we were to compare the two. But even
so, the resources are either protected by ACLs or public, both making the
security discussion moot.
> Provide a way to retrieve a JCR backed resource by its node identifier
> --
>
> Key: SLING-12300
> URL: https://issues.apache.org/jira/browse/SLING-12300
> Project: Sling
> Issue Type: New Feature
> Components: JCR
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: JCR Resource 3.3.0
>
>
> Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would
> be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}}
> property for referenceable nodes or the path. In systems that would like to
> use UUID addressing, this would reduce the need for executing JCR queries for
> resource retrieval and would avoid double-reads via the JCR and then Sling
> API to obtain the resource.
> In order to provide a unified behaviour, paths starting with the {{/jcr:id/}}
> prefix should use the resource retrieval by node identifier.
> [0] -
> https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier()
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[
https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839137#comment-17839137
]
Radu Cotescu commented on SLING-12300:
--
{quote}That seems to be a security hole where someone could just do a brute
force attack to try all the possible values and find paths that exist.
{quote}
They'd only have to try 2{^}122{^} combinations. In all seriousness now, the
same ACLs apply. I don't see how the addressing mode introduces a security hole.
> Provide a way to retrieve a JCR backed resource by its node identifier
> --
>
> Key: SLING-12300
> URL: https://issues.apache.org/jira/browse/SLING-12300
> Project: Sling
> Issue Type: New Feature
> Components: JCR
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: JCR Resource 3.3.0
>
>
> Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would
> be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}}
> property for referenceable nodes or the path. In systems that would like to
> use UUID addressing, this would reduce the need for executing JCR queries for
> resource retrieval and would avoid double-reads via the JCR and then Sling
> API to obtain the resource.
> In order to provide a unified behaviour, paths starting with the {{/jcr:id/}}
> prefix should use the resource retrieval by node identifier.
> [0] -
> https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier()
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[
https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839133#comment-17839133
]
Radu Cotescu commented on SLING-12300:
--
{quote}
If I were to add in something that provides resources under the path
{{/jcr:id/*}}, it almost seems like it should be from a provider that services
that path.
{quote}
Don't forget that the JCR provider is mounted on {{/}}. So technically
{{/jcr:id}} in this case is a resource provided by this provider. If you were
to reconfigure the provider on let's say {{/oak}}, then the "magic" path for
identifier based retrieval would be {{/oak/jcr:id/}}.
> Provide a way to retrieve a JCR backed resource by its node identifier
> --
>
> Key: SLING-12300
> URL: https://issues.apache.org/jira/browse/SLING-12300
> Project: Sling
> Issue Type: New Feature
> Components: JCR
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: JCR Resource 3.3.0
>
>
> Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would
> be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}}
> property for referenceable nodes or the path. In systems that would like to
> use UUID addressing, this would reduce the need for executing JCR queries for
> resource retrieval and would avoid double-reads via the JCR and then Sling
> API to obtain the resource.
> In order to provide a unified behaviour, paths starting with the {{/jcr:id/}}
> prefix should use the resource retrieval by node identifier.
> [0] -
> https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier()
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[
https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839129#comment-17839129
]
Radu Cotescu commented on SLING-12300:
--
[~joerghoh], how can your two asserts be true at the same time for a
referenceable node?! A JCR node's identifier is its path or, if it has the
{{mix:referenceable}} applied, its {{jcr:uuid}} property, like mentioned in the
issue's description.
In the PR I have provided some tests that show the path behaviour, namely the
path will always be the node's path, regardless of how the resource was
retrieved.
While writing a new Resource Provider might provide better isolation, it would
duplicate everything the JCR Provider does right now and it wouldn't provide
much value compared to the current solution. Accessing a resource like
{{http://localhost:8080/jcr:id/.json}} will be identical to
{{http://localhost:8080/.json}}.
> Provide a way to retrieve a JCR backed resource by its node identifier
> --
>
> Key: SLING-12300
> URL: https://issues.apache.org/jira/browse/SLING-12300
> Project: Sling
> Issue Type: New Feature
> Components: JCR
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: JCR Resource 3.3.0
>
>
> Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would
> be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}}
> property for referenceable nodes or the path. In systems that would like to
> use UUID addressing, this would reduce the need for executing JCR queries for
> resource retrieval and would avoid double-reads via the JCR and then Sling
> API to obtain the resource.
> In order to provide a unified behaviour, paths starting with the {{/jcr:id/}}
> prefix should use the resource retrieval by node identifier.
> [0] -
> https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier()
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[
https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-12300:
-
Description:
Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would be
{{Resource}} retrieval by node id, which could be its {{jcr:uuid}} property for
referenceable nodes or the path. In systems that would like to use UUID
addressing, this would reduce the need for executing JCR queries for resource
retrieval and would avoid double-reads via the JCR and then Sling API to obtain
the resource.
In order to provide a unified behaviour, paths starting with the {{/jcr:id/}}
prefix should use the resource retrieval by node identifier.
[0] -
https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier()
was:
Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would be
{{Resource}} retrieval by node id, which could be its {{jcr:uuid}} property for
referenceable nodes or the path. In systems that would like to use UUID
addressing, this would reduce the need for executing JCR queries for resource
retrieval and would avoid double-reads via the JCR and then Sling API to obtain
the resource.
[0] -
https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier()
> Provide a way to retrieve a JCR backed resource by its node identifier
> --
>
> Key: SLING-12300
> URL: https://issues.apache.org/jira/browse/SLING-12300
> Project: Sling
> Issue Type: New Feature
> Components: JCR
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: JCR Resource 3.3.0
>
>
> Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would
> be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}}
> property for referenceable nodes or the path. In systems that would like to
> use UUID addressing, this would reduce the need for executing JCR queries for
> resource retrieval and would avoid double-reads via the JCR and then Sling
> API to obtain the resource.
> In order to provide a unified behaviour, paths starting with the {{/jcr:id/}}
> prefix should use the resource retrieval by node identifier.
> [0] -
> https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier()
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
Radu Cotescu created SLING-12300:
Summary: Provide a way to retrieve a JCR backed resource by its
node identifier
Key: SLING-12300
URL: https://issues.apache.org/jira/browse/SLING-12300
Project: Sling
Issue Type: New Feature
Components: JCR
Reporter: Radu Cotescu
Assignee: Radu Cotescu
Fix For: JCR Resource 3.3.0
Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would be
{{Resource}} retrieval by node id, which could be its {{jcr:uuid}} property for
referenceable nodes or the path. In systems that would like to use UUID
addressing, this would reduce the need for executing JCR queries for resource
retrieval and would avoid double-reads via the JCR and then Sling API to obtain
the resource.
[0] -
https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier()
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-10901) Allow terminating a GraphQL query after a configured timeout
[ https://issues.apache.org/jira/browse/SLING-10901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-10901: - Fix Version/s: GraphQL Core 0.0.32 (was: GraphQL Core 0.0.30) > Allow terminating a GraphQL query after a configured timeout > > > Key: SLING-10901 > URL: https://issues.apache.org/jira/browse/SLING-10901 > Project: Sling > Issue Type: Improvement > Components: GraphQL >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: GraphQL Core 0.0.32 > > > Since expensive GraphQL queries could lead to a DoS attack, it would be worth > allowing a system administrator to configure the maximum execution time of a > query. When a long running query is interrupted, the returned error should be > transparent for the GraphQL engine, so that the client knows exactly why the > query failed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12221) Upgrade grahpql-java version to 20.3
[ https://issues.apache.org/jira/browse/SLING-12221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu closed SLING-12221. > Upgrade grahpql-java version to 20.3 > > > Key: SLING-12221 > URL: https://issues.apache.org/jira/browse/SLING-12221 > Project: Sling > Issue Type: Bug > Components: GraphQL >Affects Versions: GraphQL Core 0.0.26 >Reporter: Lenard Palko >Assignee: Radu Cotescu >Priority: Minor > Fix For: GraphQL Core 0.0.30 > > > The version of graphql-java currently used is 20.1, but version 20.3 offers > the possibility to configure also MAX_QUERY_CHARACTERS, in addition to > MAX_QUERY_TOKENS and MAX_WHITESPACE_TOKENS. > [https://github.com/graphql-java/graphql-java/blob/v20.3/src/main/java/graphql/parser/ParserOptions.java#L24] > This would allow to configure the full query length in case the already > existing configurations limits are hit. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-12221) Upgrade grahpql-java version to 20.3
[ https://issues.apache.org/jira/browse/SLING-12221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu resolved SLING-12221. -- Fix Version/s: GraphQL Core 0.0.30 Resolution: Fixed > Upgrade grahpql-java version to 20.3 > > > Key: SLING-12221 > URL: https://issues.apache.org/jira/browse/SLING-12221 > Project: Sling > Issue Type: Bug > Components: GraphQL >Affects Versions: GraphQL Core 0.0.26 >Reporter: Lenard Palko >Assignee: Radu Cotescu >Priority: Minor > Fix For: GraphQL Core 0.0.30 > > > The version of graphql-java currently used is 20.1, but version 20.3 offers > the possibility to configure also MAX_QUERY_CHARACTERS, in addition to > MAX_QUERY_TOKENS and MAX_WHITESPACE_TOKENS. > [https://github.com/graphql-java/graphql-java/blob/v20.3/src/main/java/graphql/parser/ParserOptions.java#L24] > This would allow to configure the full query length in case the already > existing configurations limits are hit. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12198) Extending sling.graphql.engine to allow passing custom graphql ParserOptions while executing GraphQL queries
[ https://issues.apache.org/jira/browse/SLING-12198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu closed SLING-12198. > Extending sling.graphql.engine to allow passing custom graphql ParserOptions > while executing GraphQL queries > > > Key: SLING-12198 > URL: https://issues.apache.org/jira/browse/SLING-12198 > Project: Sling > Issue Type: Improvement > Components: GraphQL >Affects Versions: GraphQL Core 0.0.24 >Reporter: Andrzej Kubas >Assignee: Bertrand Delacretaz >Priority: Major > Fix For: GraphQL Core 0.0.28 > > > The graphql-java crates default ParserOptions(if not passed with > ExecutionInput#graphQLContext) while executing GraphQL query. > [https://github.com/graphql-java/graphql-java/blob/v20.3/src/main/java/graphql/ParseAndValidate.java#L67] > [https://github.com/graphql-java/graphql-java/blob/v20.3/src/main/java/graphql/parser/ParserOptions.java#L35] > That could lead to 'Denial Of Service' InvalidSyntax error while executing > GraphQL complex queries. > > However, there should be a way to set graphql-java execution up with custom > values of ParserOprions. > [https://github.com/apache/sling-org-apache-sling-graphql-core/blob/org.apache.sling.graphql.core-0.0.24/src/main/java/org/apache/sling/graphql/core/engine/DefaultQueryExecutor.java#L208] > [https://github.com/apache/sling-org-apache-sling-graphql-core/blob/org.apache.sling.graphql.core-0.0.24/src/main/java/org/apache/sling/graphql/core/engine/DefaultQueryExecutor.java#L202] > https://github.com/apache/sling-org-apache-sling-graphql-core/blob/org.apache.sling.graphql.core-0.0.24/src/main/java/org/apache/sling/graphql/core/engine/DefaultQueryExecutor.java#L155 > > That should help to orchestrate custom graphql-java executions for complex > GraphQL queries. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12200) sling-org-apache-sling-graphql-core unnecessarily uses the shaded guava from graphql-java
[ https://issues.apache.org/jira/browse/SLING-12200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu closed SLING-12200. > sling-org-apache-sling-graphql-core unnecessarily uses the shaded guava from > graphql-java > - > > Key: SLING-12200 > URL: https://issues.apache.org/jira/browse/SLING-12200 > Project: Sling > Issue Type: Improvement > Components: GraphQL >Affects Versions: GraphQL Core 0.0.26 >Reporter: Manfred Baedke >Assignee: Bertrand Delacretaz >Priority: Trivial > Fix For: GraphQL Core 0.0.28 > > > AFAIK shaded Guava is no longer part part of recent releases of graphql-java. > The only usage is > https://github.com/apache/sling-org-apache-sling-graphql-core/blob/30babad3caab0da0dc85bc0d645f76ca6784ef67/src/main/java/org/apache/sling/graphql/core/engine/SelectedFieldWrapper.java#L181, > which is trivial to replace with JavaSE. > cc [~reschke] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (SLING-12221) Upgrade grahpql-java version to 20.3
[ https://issues.apache.org/jira/browse/SLING-12221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu reassigned SLING-12221: Assignee: Radu Cotescu > Upgrade grahpql-java version to 20.3 > > > Key: SLING-12221 > URL: https://issues.apache.org/jira/browse/SLING-12221 > Project: Sling > Issue Type: Bug > Components: GraphQL >Affects Versions: GraphQL Core 0.0.26 >Reporter: Lenard Palko >Assignee: Radu Cotescu >Priority: Minor > > The version of graphql-java currently used is 20.1, but version 20.3 offers > the possibility to configure also MAX_QUERY_CHARACTERS, in addition to > MAX_QUERY_TOKENS and MAX_WHITESPACE_TOKENS. > [https://github.com/graphql-java/graphql-java/blob/v20.3/src/main/java/graphql/parser/ParserOptions.java#L24] > This would allow to configure the full query length in case the already > existing configurations limits are hit. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12027) GraphQL core fails to build with Java 17
[ https://issues.apache.org/jira/browse/SLING-12027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768749#comment-17768749 ] Radu Cotescu commented on SLING-12027: -- [~andysch], could it be that the tests are running with relatively old Sling Engine and Sling Servlet Resolver bundles? Have you tried updating those? > GraphQL core fails to build with Java 17 > > > Key: SLING-12027 > URL: https://issues.apache.org/jira/browse/SLING-12027 > Project: Sling > Issue Type: Bug > Components: GraphQL >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > Fix For: GraphQL Core 0.0.26 > > > 1. Mockito fails to create mocks, probably due to old version > 2. Pax-Exam tests time out -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12014) GraphQL Core needs to support additional fields from GraphQL Java
[ https://issues.apache.org/jira/browse/SLING-12014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-12014: - Summary: GraphQL Core needs to support additional fields from GraphQL Java (was: GraphQL Core needs to Support Addition Fields from GraphQL Java) > GraphQL Core needs to support additional fields from GraphQL Java > - > > Key: SLING-12014 > URL: https://issues.apache.org/jira/browse/SLING-12014 > Project: Sling > Issue Type: Improvement >Reporter: Andreas Schaefer >Assignee: Andreas Schaefer >Priority: Major > > There is a need to have additional fields from the GraphQL Java's Selected > Field. For example there is a need to separate fields with the same name but > different parent through the Fully Qualified Name. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12003) The RequestDispatcher should flush the buffer on forward only if the buffer hasn't already been closed
[
https://issues.apache.org/jira/browse/SLING-12003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu closed SLING-12003.
> The RequestDispatcher should flush the buffer on forward only if the buffer
> hasn't already been closed
> --
>
> Key: SLING-12003
> URL: https://issues.apache.org/jira/browse/SLING-12003
> Project: Sling
> Issue Type: Improvement
> Components: Engine
>Affects Versions: Engine 2.2.10
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Engine 2.15.6
>
>
> The {{SlingRequestDispatcher#forward}} call [0] attempts to close the
> response buffer even if this has already been closed by the servlet to which
> the request was originally forwarded. The Servlet Specification [1] mentions
> the following in section 9.4:
> {quote}Before the forward method of the RequestDispatcher interface returns
> without exception, the response content must be sent and committed, and
> closed by the servlet container, unless the request was put into the
> asynchronous mode.
> {quote}
> As such, the {{RequestDispatcher#forward}} implementation should indeed make
> sure the response is committed, but it's not necessarily the only one that
> must commit the response. Jetty seems to have the same understanding [2],
> where the close is performed only if the response hasn't already been
> committed and the request is not async.
> [0] -
> [https://github.com/apache/sling-org-apache-sling-engine/blob/368690a2a81fd8a121e62767fcd32b63936a65b8/src/main/java/org/apache/sling/engine/impl/request/SlingRequestDispatcher.java#L125-L128]
> [1] -
> [https://download.oracle.com/otn-pub/jcp/servlet-3_1-fr-spec/servlet-3_1-final.pdf]
> [2] -
> [https://github.com/eclipse/jetty.project/blob/jetty-11.0.x/jetty-server/src/main/java/org/eclipse/jetty/server/Dispatcher.java#L218]
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SLING-12003) The RequestDispatcher should flush the buffer on forward only if the buffer hasn't already been closed
[
https://issues.apache.org/jira/browse/SLING-12003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu resolved SLING-12003.
--
Resolution: Fixed
> The RequestDispatcher should flush the buffer on forward only if the buffer
> hasn't already been closed
> --
>
> Key: SLING-12003
> URL: https://issues.apache.org/jira/browse/SLING-12003
> Project: Sling
> Issue Type: Improvement
> Components: Engine
>Affects Versions: Engine 2.2.10
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Engine 2.15.6
>
>
> The {{SlingRequestDispatcher#forward}} call [0] attempts to close the
> response buffer even if this has already been closed by the servlet to which
> the request was originally forwarded. The Servlet Specification [1] mentions
> the following in section 9.4:
> {quote}Before the forward method of the RequestDispatcher interface returns
> without exception, the response content must be sent and committed, and
> closed by the servlet container, unless the request was put into the
> asynchronous mode.
> {quote}
> As such, the {{RequestDispatcher#forward}} implementation should indeed make
> sure the response is committed, but it's not necessarily the only one that
> must commit the response. Jetty seems to have the same understanding [2],
> where the close is performed only if the response hasn't already been
> committed and the request is not async.
> [0] -
> [https://github.com/apache/sling-org-apache-sling-engine/blob/368690a2a81fd8a121e62767fcd32b63936a65b8/src/main/java/org/apache/sling/engine/impl/request/SlingRequestDispatcher.java#L125-L128]
> [1] -
> [https://download.oracle.com/otn-pub/jcp/servlet-3_1-fr-spec/servlet-3_1-final.pdf]
> [2] -
> [https://github.com/eclipse/jetty.project/blob/jetty-11.0.x/jetty-server/src/main/java/org/eclipse/jetty/server/Dispatcher.java#L218]
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SLING-11458) Regress - "Writer has already been closed" exception in GraphQLServlet
[
https://issues.apache.org/jira/browse/SLING-11458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu closed SLING-11458.
> Regress - "Writer has already been closed" exception in GraphQLServlet
> --
>
> Key: SLING-11458
> URL: https://issues.apache.org/jira/browse/SLING-11458
> Project: Sling
> Issue Type: Bug
> Components: GraphQL
>Affects Versions: GraphQL Core 0.0.4
>Reporter: Evgeny Tugarev
>Assignee: Radu Cotescu
>Priority: Major
>
> The GraphQLServlet shouldn't call {{response.getWriter().flush()}} as the
> {{JsonWriter}} used by the {{JsonSerializer}} implements {{Closeable}} and as
> such [closes the
> Writer|https://github.com/jdereg/json-io/blob/cf849f15460decf10a8a320390de11965bb5996b/src/main/java/com/cedarsoftware/util/io/JsonWriter.java#L2413].
> This causes a "Writer has already been closed" Exception when {{flush()}} is
> called.
> This was fixed in commit d27f4bb7 but then this commit: 11c7e389 did undo the
> fix as now the JsonWriter is closed when existing the try-catch block.
> I will undo it and prevent the premature closure as this is causing issues
> like when the call to this servlet is made through a dispatcher.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SLING-11458) Regress - "Writer has already been closed" exception in GraphQLServlet
[
https://issues.apache.org/jira/browse/SLING-11458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu resolved SLING-11458.
--
Assignee: Radu Cotescu (was: Andreas Schaefer)
Resolution: Not A Problem
> Regress - "Writer has already been closed" exception in GraphQLServlet
> --
>
> Key: SLING-11458
> URL: https://issues.apache.org/jira/browse/SLING-11458
> Project: Sling
> Issue Type: Bug
> Components: GraphQL
>Affects Versions: GraphQL Core 0.0.4
>Reporter: Evgeny Tugarev
>Assignee: Radu Cotescu
>Priority: Major
>
> The GraphQLServlet shouldn't call {{response.getWriter().flush()}} as the
> {{JsonWriter}} used by the {{JsonSerializer}} implements {{Closeable}} and as
> such [closes the
> Writer|https://github.com/jdereg/json-io/blob/cf849f15460decf10a8a320390de11965bb5996b/src/main/java/com/cedarsoftware/util/io/JsonWriter.java#L2413].
> This causes a "Writer has already been closed" Exception when {{flush()}} is
> called.
> This was fixed in commit d27f4bb7 but then this commit: 11c7e389 did undo the
> fix as now the JsonWriter is closed when existing the try-catch block.
> I will undo it and prevent the premature closure as this is causing issues
> like when the call to this servlet is made through a dispatcher.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (SLING-12003) The RequestDispatcher should flush the buffer on forward only if the buffer hasn't already been closed
[
https://issues.apache.org/jira/browse/SLING-12003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu reassigned SLING-12003:
Assignee: Radu Cotescu
> The RequestDispatcher should flush the buffer on forward only if the buffer
> hasn't already been closed
> --
>
> Key: SLING-12003
> URL: https://issues.apache.org/jira/browse/SLING-12003
> Project: Sling
> Issue Type: Improvement
> Components: Engine
>Affects Versions: Engine 2.2.10
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Engine 2.15.6
>
>
> The {{SlingRequestDispatcher#forward}} call [0] attempts to close the
> response buffer even if this has already been closed by the servlet to which
> the request was originally forwarded. The Servlet Specification [1] mentions
> the following in section 9.4:
> {quote}Before the forward method of the RequestDispatcher interface returns
> without exception, the response content must be sent and committed, and
> closed by the servlet container, unless the request was put into the
> asynchronous mode.
> {quote}
> As such, the {{RequestDispatcher#forward}} implementation should indeed make
> sure the response is committed, but it's not necessarily the only one that
> must commit the response. Jetty seems to have the same understanding [2],
> where the close is performed only if the response hasn't already been
> committed and the request is not async.
> [0] -
> [https://github.com/apache/sling-org-apache-sling-engine/blob/368690a2a81fd8a121e62767fcd32b63936a65b8/src/main/java/org/apache/sling/engine/impl/request/SlingRequestDispatcher.java#L125-L128]
> [1] -
> [https://download.oracle.com/otn-pub/jcp/servlet-3_1-fr-spec/servlet-3_1-final.pdf]
> [2] -
> [https://github.com/eclipse/jetty.project/blob/jetty-11.0.x/jetty-server/src/main/java/org/eclipse/jetty/server/Dispatcher.java#L218]
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12003) The RequestDispatcher should flush the buffer on forward only if the buffer hasn't already been closed
[
https://issues.apache.org/jira/browse/SLING-12003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17754504#comment-17754504
]
Radu Cotescu commented on SLING-12003:
--
Exactly. I could submit a PR, unless you want to take this over.
> The RequestDispatcher should flush the buffer on forward only if the buffer
> hasn't already been closed
> --
>
> Key: SLING-12003
> URL: https://issues.apache.org/jira/browse/SLING-12003
> Project: Sling
> Issue Type: Improvement
> Components: Engine
>Affects Versions: Engine 2.2.10
>Reporter: Radu Cotescu
>Priority: Major
> Fix For: Engine 2.15.6
>
>
> The {{SlingRequestDispatcher#forward}} call [0] attempts to close the
> response buffer even if this has already been closed by the servlet to which
> the request was originally forwarded. The Servlet Specification [1] mentions
> the following in section 9.4:
> {quote}Before the forward method of the RequestDispatcher interface returns
> without exception, the response content must be sent and committed, and
> closed by the servlet container, unless the request was put into the
> asynchronous mode.
> {quote}
> As such, the {{RequestDispatcher#forward}} implementation should indeed make
> sure the response is committed, but it's not necessarily the only one that
> must commit the response. Jetty seems to have the same understanding [2],
> where the close is performed only if the response hasn't already been
> committed and the request is not async.
> [0] -
> [https://github.com/apache/sling-org-apache-sling-engine/blob/368690a2a81fd8a121e62767fcd32b63936a65b8/src/main/java/org/apache/sling/engine/impl/request/SlingRequestDispatcher.java#L125-L128]
> [1] -
> [https://download.oracle.com/otn-pub/jcp/servlet-3_1-fr-spec/servlet-3_1-final.pdf]
> [2] -
> [https://github.com/eclipse/jetty.project/blob/jetty-11.0.x/jetty-server/src/main/java/org/eclipse/jetty/server/Dispatcher.java#L218]
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-11458) Regress - "Writer has already been closed" exception in GraphQLServlet
[
https://issues.apache.org/jira/browse/SLING-11458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17754497#comment-17754497
]
Radu Cotescu commented on SLING-11458:
--
The GraphQL Servlet doesn't do anything wrong. The error mentioned in this
issue can happen when requests are forwarded to the GraphQL servlet and the
actual cause is described in SLING-12003.
> Regress - "Writer has already been closed" exception in GraphQLServlet
> --
>
> Key: SLING-11458
> URL: https://issues.apache.org/jira/browse/SLING-11458
> Project: Sling
> Issue Type: Bug
> Components: GraphQL
>Affects Versions: GraphQL Core 0.0.4
>Reporter: Evgeny Tugarev
>Assignee: Andreas Schaefer
>Priority: Major
>
> The GraphQLServlet shouldn't call {{response.getWriter().flush()}} as the
> {{JsonWriter}} used by the {{JsonSerializer}} implements {{Closeable}} and as
> such [closes the
> Writer|https://github.com/jdereg/json-io/blob/cf849f15460decf10a8a320390de11965bb5996b/src/main/java/com/cedarsoftware/util/io/JsonWriter.java#L2413].
> This causes a "Writer has already been closed" Exception when {{flush()}} is
> called.
> This was fixed in commit d27f4bb7 but then this commit: 11c7e389 did undo the
> fix as now the JsonWriter is closed when existing the try-catch block.
> I will undo it and prevent the premature closure as this is causing issues
> like when the call to this servlet is made through a dispatcher.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SLING-12003) The RequestDispatcher should flush the buffer on forward only if the buffer hasn't already been closed
Radu Cotescu created SLING-12003:
Summary: The RequestDispatcher should flush the buffer on forward
only if the buffer hasn't already been closed
Key: SLING-12003
URL: https://issues.apache.org/jira/browse/SLING-12003
Project: Sling
Issue Type: Improvement
Components: Engine
Affects Versions: Engine 2.2.10
Reporter: Radu Cotescu
Fix For: Engine 2.15.6
The {{SlingRequestDispatcher#forward}} call [0] attempts to close the response
buffer even if this has already been closed by the servlet to which the request
was originally forwarded. The Servlet Specification [1] mentions the following
in section 9.4:
{quote}Before the forward method of the RequestDispatcher interface returns
without exception, the response content must be sent and committed, and closed
by the servlet container, unless the request was put into the asynchronous mode.
{quote}
As such, the {{RequestDispatcher#forward}} implementation should indeed make
sure the response is committed, but it's not necessarily the only one that must
commit the response. Jetty seems to have the same understanding [2], where the
close is performed only if the response hasn't already been committed and the
request is not async.
[0] -
[https://github.com/apache/sling-org-apache-sling-engine/blob/368690a2a81fd8a121e62767fcd32b63936a65b8/src/main/java/org/apache/sling/engine/impl/request/SlingRequestDispatcher.java#L125-L128]
[1] -
[https://download.oracle.com/otn-pub/jcp/servlet-3_1-fr-spec/servlet-3_1-final.pdf]
[2] -
[https://github.com/eclipse/jetty.project/blob/jetty-11.0.x/jetty-server/src/main/java/org/eclipse/jetty/server/Dispatcher.java#L218]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-11458) Regress - "Writer has already been closed" exception in GraphQLServlet
[
https://issues.apache.org/jira/browse/SLING-11458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17754130#comment-17754130
]
Radu Cotescu commented on SLING-11458:
--
Circling back to this issue.
{quote}Is there a reason why the Servlet Writer needs to be closed?
{quote}
Yes, the GraphQL servlet is the one that controls the execution. What's the
point of having the writer open after the GraphQL execution result has been
sent?
> Regress - "Writer has already been closed" exception in GraphQLServlet
> --
>
> Key: SLING-11458
> URL: https://issues.apache.org/jira/browse/SLING-11458
> Project: Sling
> Issue Type: Bug
> Components: GraphQL
>Affects Versions: GraphQL Core 0.0.4
>Reporter: Evgeny Tugarev
>Assignee: Andreas Schaefer
>Priority: Major
>
> The GraphQLServlet shouldn't call {{response.getWriter().flush()}} as the
> {{JsonWriter}} used by the {{JsonSerializer}} implements {{Closeable}} and as
> such [closes the
> Writer|https://github.com/jdereg/json-io/blob/cf849f15460decf10a8a320390de11965bb5996b/src/main/java/com/cedarsoftware/util/io/JsonWriter.java#L2413].
> This causes a "Writer has already been closed" Exception when {{flush()}} is
> called.
> This was fixed in commit d27f4bb7 but then this commit: 11c7e389 did undo the
> fix as now the JsonWriter is closed when existing the try-catch block.
> I will undo it and prevent the premature closure as this is causing issues
> like when the call to this servlet is made through a dispatcher.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-10901) Allow terminating a GraphQL query after a configured timeout
[ https://issues.apache.org/jira/browse/SLING-10901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-10901: - Fix Version/s: GraphQL Core 0.0.24 (was: GraphQL Core 0.0.22) > Allow terminating a GraphQL query after a configured timeout > > > Key: SLING-10901 > URL: https://issues.apache.org/jira/browse/SLING-10901 > Project: Sling > Issue Type: Improvement > Components: GraphQL >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: GraphQL Core 0.0.24 > > > Since expensive GraphQL queries could lead to a DoS attack, it would be worth > allowing a system administrator to configure the maximum execution time of a > query. When a long running query is interrupted, the returned error should be > transparent for the GraphQL engine, so that the client knows exactly why the > query failed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-11920) Expose Object Type Names in Selected Field
[
https://issues.apache.org/jira/browse/SLING-11920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu resolved SLING-11920.
--
Resolution: Fixed
> Expose Object Type Names in Selected Field
> --
>
> Key: SLING-11920
> URL: https://issues.apache.org/jira/browse/SLING-11920
> Project: Sling
> Issue Type: Bug
>Affects Versions: GraphQL Core 0.0.20
>Reporter: Andreas Schaefer
>Assignee: Andreas Schaefer
>Priority: Critical
> Fix For: GraphQL Core 0.0.22
>
>
> Intermediary fields are not exposed as Selected Fields in Graphql-java and so
> it was added as list of Object Type Name.
> Now for handling '... on ' we need to expose these Object Type
> Names so that a client can deal with them.
> If we have a query where we have a inline fragments
> ([https://graphql.org/learn/queries/#inline-fragments]) like:
> {code:java}
> {
>image {
> ... on ImageRef {
> type{code}
> Then in the graphql-java 15.0 there is an inlined field called *ImageRef* but
> that is now gone in 20.1. Instead we have a list of Object Type Names in a
> field and in our example *type* would have Objet Type Names:
> {*}["ImageRef"]{*}. So for a client to obtain the type of the inlined
> fragments this data must be exposed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (SLING-11850) HTL: Add support for suffix manipulation in ResourceRuntimeExtension
[
https://issues.apache.org/jira/browse/SLING-11850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731675#comment-17731675
]
Radu Cotescu edited comment on SLING-11850 at 6/12/23 4:14 PM:
---
We never thought about adding support for the suffix, as that doesn't influence
which script will be picked up at rendering time, but I can see why the feature
could be useful. However, the URI Manipulation section of the specification
includes details about the suffix handling:
[https://github.com/adobe/htl-spec/blob/1.4/SPECIFICATION.md#125-uri-manipulation.]
Could you use that instead?
was (Author: radu.cotescu):
We never thought about adding support for the suffix, as that doesn't influence
which script will be picked up at rendering time, but I can see why the feature
could be useful.
> HTL: Add support for suffix manipulation in ResourceRuntimeExtension
>
>
> Key: SLING-11850
> URL: https://issues.apache.org/jira/browse/SLING-11850
> Project: Sling
> Issue Type: Improvement
> Components: Scripting
>Affects Versions: Scripting HTL Engine 1.4.22-1.4.0
>Reporter: Robin Brouns
>Priority: Minor
> Labels: Sightly
>
> In JSP there is the possibility to include a resource in a component and
> adjust the suffix of the sub-request, processing this resource:
> {code:java}
> path="my-component"
> resourceType="application/components/other-component"
> replaceSuffix="some-suffix"/>
> {code}
> See also:
> [https://github.com/apache/sling-org-apache-sling-scripting-jsp-taglib/blob/7835da79f1de7c9c14fd478e9fec23f54fd6d711/src/main/java/org/apache/sling/scripting/jsp/taglib/AbstractDispatcherTagHandler.java#L89]
> But HTL lacks this option to adjust the suffix for the sub-request (by using
> data-sly-resource): see
> [https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/3b50f91c4f600081f0585e50dfb775c4b2856b89/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/ResourceRuntimeExtension.java#L58]
>
> Is there a reason why this feature wasn't added and is not supported right
> now?
> Because we can manipulate the suffix in a URI context in HTL
> ([https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/3b50f91c4f600081f0585e50dfb775c4b2856b89/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/URIManipulationFilterExtension.java#L221),]
> but just not in the Resource context.
> The _RequestDispatcher_ is already available and used in the
> _ResourceRuntimeExtension_ so it could be added.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-11850) HTL: Add support for suffix manipulation in ResourceRuntimeExtension
[
https://issues.apache.org/jira/browse/SLING-11850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731675#comment-17731675
]
Radu Cotescu commented on SLING-11850:
--
We never thought about adding support for the suffix, as that doesn't influence
which script will be picked up at rendering time, but I can see why the feature
could be useful.
> HTL: Add support for suffix manipulation in ResourceRuntimeExtension
>
>
> Key: SLING-11850
> URL: https://issues.apache.org/jira/browse/SLING-11850
> Project: Sling
> Issue Type: Improvement
> Components: Scripting
>Affects Versions: Scripting HTL Engine 1.4.22-1.4.0
>Reporter: Robin Brouns
>Priority: Minor
> Labels: Sightly
>
> In JSP there is the possibility to include a resource in a component and
> adjust the suffix of the sub-request, processing this resource:
> {code:java}
> path="my-component"
> resourceType="application/components/other-component"
> replaceSuffix="some-suffix"/>
> {code}
> See also:
> [https://github.com/apache/sling-org-apache-sling-scripting-jsp-taglib/blob/7835da79f1de7c9c14fd478e9fec23f54fd6d711/src/main/java/org/apache/sling/scripting/jsp/taglib/AbstractDispatcherTagHandler.java#L89]
> But HTL lacks this option to adjust the suffix for the sub-request (by using
> data-sly-resource): see
> [https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/3b50f91c4f600081f0585e50dfb775c4b2856b89/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/ResourceRuntimeExtension.java#L58]
>
> Is there a reason why this feature wasn't added and is not supported right
> now?
> Because we can manipulate the suffix in a URI context in HTL
> ([https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/3b50f91c4f600081f0585e50dfb775c4b2856b89/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/URIManipulationFilterExtension.java#L221),]
> but just not in the Resource context.
> The _RequestDispatcher_ is already available and used in the
> _ResourceRuntimeExtension_ so it could be added.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SLING-11852) Make the ThreadsafeMockAdapterManagerWrapper use an InheritableThreadLocal
[
https://issues.apache.org/jira/browse/SLING-11852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu closed SLING-11852.
> Make the ThreadsafeMockAdapterManagerWrapper use an InheritableThreadLocal
> --
>
> Key: SLING-11852
> URL: https://issues.apache.org/jira/browse/SLING-11852
> Project: Sling
> Issue Type: Improvement
> Components: Testing
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Testing Sling Mock 3.4.8
>
>
> For scenarios where the mocked OSGi framework executes calls in other threads
> than the test thread (e.g. servlets under test in Jetty), the only way to
> pass the test's {{AdapterManager}} is to directly call
> {{{}SlingAdaptable#setAdapterManager{}}}. However, this will affect tests
> starting after this initial call.
> A better solution would be to make the
> {{org.apache.sling.testing.mock.sling.ThreadsafeMockAdapterManagerWrapper#THREAD_LOCAL}}
> an {{{}InheritableThreadLocal{}}}. This would allow the tests to still be
> executable in parallel, but threads started from a test thread (e.g. the
> servlets under test in Jetty) could inherit the thread local context.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SLING-11852) Make the ThreadsafeMockAdapterManagerWrapper use an InheritableThreadLocal
[
https://issues.apache.org/jira/browse/SLING-11852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu resolved SLING-11852.
--
Resolution: Fixed
> Make the ThreadsafeMockAdapterManagerWrapper use an InheritableThreadLocal
> --
>
> Key: SLING-11852
> URL: https://issues.apache.org/jira/browse/SLING-11852
> Project: Sling
> Issue Type: Improvement
> Components: Testing
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Testing Sling Mock 3.4.8
>
>
> For scenarios where the mocked OSGi framework executes calls in other threads
> than the test thread (e.g. servlets under test in Jetty), the only way to
> pass the test's {{AdapterManager}} is to directly call
> {{{}SlingAdaptable#setAdapterManager{}}}. However, this will affect tests
> starting after this initial call.
> A better solution would be to make the
> {{org.apache.sling.testing.mock.sling.ThreadsafeMockAdapterManagerWrapper#THREAD_LOCAL}}
> an {{{}InheritableThreadLocal{}}}. This would allow the tests to still be
> executable in parallel, but threads started from a test thread (e.g. the
> servlets under test in Jetty) could inherit the thread local context.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (SLING-11852) Make the ThreadsafeMockAdapterManagerWrapper use an InheritableThreadLocal
[
https://issues.apache.org/jira/browse/SLING-11852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu reassigned SLING-11852:
Assignee: Radu Cotescu
> Make the ThreadsafeMockAdapterManagerWrapper use an InheritableThreadLocal
> --
>
> Key: SLING-11852
> URL: https://issues.apache.org/jira/browse/SLING-11852
> Project: Sling
> Issue Type: Improvement
> Components: Testing
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Testing Sling Mock 3.4.8
>
>
> For scenarios where the mocked OSGi framework executes calls in other threads
> than the test thread (e.g. servlets under test in Jetty), the only way to
> pass the test's {{AdapterManager}} is to directly call
> {{{}SlingAdaptable#setAdapterManager{}}}. However, this will affect tests
> starting after this initial call.
> A better solution would be to make the
> {{org.apache.sling.testing.mock.sling.ThreadsafeMockAdapterManagerWrapper#THREAD_LOCAL}}
> an {{{}InheritableThreadLocal{}}}. This would allow the tests to still be
> executable in parallel, but threads started from a test thread (e.g. the
> servlets under test in Jetty) could inherit the thread local context.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SLING-11852) Make the ThreadsafeMockAdapterManagerWrapper use an InheritableThreadLocal
Radu Cotescu created SLING-11852:
Summary: Make the ThreadsafeMockAdapterManagerWrapper use an
InheritableThreadLocal
Key: SLING-11852
URL: https://issues.apache.org/jira/browse/SLING-11852
Project: Sling
Issue Type: Improvement
Components: Testing
Reporter: Radu Cotescu
Fix For: Testing Sling Mock 3.4.8
For scenarios where the mocked OSGi framework executes calls in other threads
than the test thread (e.g. servlets under test in Jetty), the only way to pass
the test's {{AdapterManager}} is to directly call
{{{}SlingAdaptable#setAdapterManager{}}}. However, this will affect tests
starting after this initial call.
A better solution would be to make the
{{org.apache.sling.testing.mock.sling.ThreadsafeMockAdapterManagerWrapper#THREAD_LOCAL}}
an {{{}InheritableThreadLocal{}}}. This would allow the tests to still be
executable in parallel, but threads started from a test thread (e.g. the
servlets under test in Jetty) could inherit the thread local context.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-8972) Self-explanatory message when the module name and Jira version name do not match
[
https://issues.apache.org/jira/browse/SLING-8972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-8972:
Fix Version/s: Committer CLI 1.0.2
(was: Committer CLI 1.0.0)
> Self-explanatory message when the module name and Jira version name do not
> match
>
>
> Key: SLING-8972
> URL: https://issues.apache.org/jira/browse/SLING-8972
> Project: Sling
> Issue Type: Improvement
> Components: Build and Source Control
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: Committer CLI 1.0.2
>
>
> When the committer CLI does not find a matching Jira release for the module
> name it fails with slightly cryptic error message (see below). We should
> explain to the user what is wrong, e.g. "Unable to match release with a Jira
> version - did not find a Jira version matching ${MODULE_NAME} ${VERSION}"
> {noformat}java.lang.IllegalArgumentException: No version found with name
> Default
> POST Servlets 2.3.34
> at
> org.apache.sling.cli.impl.jira.VersionClient.lambda$find$1(VersionClient.java:84)
> at java.base/java.util.Optional.orElseThrow(Unknown Source)
> at
> org.apache.sling.cli.impl.jira.VersionClient.find(VersionClient.java:84)
> at
> org.apache.sling.cli.impl.release.PrepareVoteEmailCommand.lambda$run$0(PrepareVoteEmailCommand.java:116)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(Unknown Source)
> at java.base/java.util.Iterator.forEachRemaining(Unknown Source)
> at
> java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Unknown
> Source)
> at java.base/java.util.stream.AbstractPipeline.copyInto(Unknown
> Source)
> at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(Unknown Source)
> at
> java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(Unknown
> Source)
> at java.base/java.util.stream.AbstractPipeline.evaluate(Unknown
> Source)
> at java.base/java.util.stream.ReferencePipeline.collect(Unknown
> Source)
> at
> org.apache.sling.cli.impl.release.PrepareVoteEmailCommand.run(PrepareVoteEmailCommand.java:117)
> at picocli.CommandLine.executeUserObject(CommandLine.java:1687)
> at picocli.CommandLine.access$900(CommandLine.java:146)
> at picocli.CommandLine$RunLast.handle(CommandLine.java:2059)
> at picocli.CommandLine$RunLast.handle(CommandLine.java:2026)
> at
> picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:1893)
> at picocli.CommandLine.execute(CommandLine.java:1822)
> at
> org.apache.sling.cli.impl.CommandProcessor.runCommand(CommandProcessor.java:110)
> at
> org.apache.sling.cli.impl.ExecutionTrigger.lambda$activate$0(ExecutionTrigger.java:33)
> at java.base/java.lang.Thread.run(Unknown Source)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-8338) Create sub-command to manage the Nexus stage repository release when promoting a release
[
https://issues.apache.org/jira/browse/SLING-8338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-8338:
Fix Version/s: (was: Committer CLI 1.0.0)
Committer CLI 1.0.2
> Create sub-command to manage the Nexus stage repository release when
> promoting a release
>
>
> Key: SLING-8338
> URL: https://issues.apache.org/jira/browse/SLING-8338
> Project: Sling
> Issue Type: Improvement
> Components: Tooling
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: Committer CLI 1.0.2
>
>
> We should add a new command {{release nexus-release}} which takes care of
> releasing the staged artifacts from Nexus for a new release.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-10355) Update the Commiter CLI to check SHA-512 signatures for the source release
[ https://issues.apache.org/jira/browse/SLING-10355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-10355: - Fix Version/s: Committer CLI 1.0.2 (was: Committer CLI 1.0.0) > Update the Commiter CLI to check SHA-512 signatures for the source release > -- > > Key: SLING-10355 > URL: https://issues.apache.org/jira/browse/SLING-10355 > Project: Sling > Issue Type: Improvement > Components: Tooling >Reporter: Robert Munteanu >Priority: Major > Fix For: Committer CLI 1.0.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-8699) Create sub-command to moving artifacts to dist.apache.org
[
https://issues.apache.org/jira/browse/SLING-8699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-8699:
Fix Version/s: Committer CLI 1.0.2
(was: Committer CLI 1.0.0)
> Create sub-command to moving artifacts to dist.apache.org
> -
>
> Key: SLING-8699
> URL: https://issues.apache.org/jira/browse/SLING-8699
> Project: Sling
> Issue Type: New Feature
> Components: Tooling
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: Committer CLI 1.0.2
>
>
> With SLING-8684 we now have the pieces in place to automate promoting
> artifacts to dist.apache.org.
> This sub-command will perform the following actions:
> - compute SHA-256 checksums and adds them to the files to be deployed
> - not include MD5 checksums
> - use the Java API equivalent of {{svn remove https://dist.apache.org/ ...}}
> to remove all old artifacts of a release
> - use the Java API equivalent of {{svn import . https://dist.apache.org/
> ...}} to import local set of artifacts to SVN
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-8395) Investigate automatically issuing GitHub PRs with the Committer CLI
[ https://issues.apache.org/jira/browse/SLING-8395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-8395: Fix Version/s: Committer CLI 1.0.2 (was: Committer CLI 1.0.0) > Investigate automatically issuing GitHub PRs with the Committer CLI > --- > > Key: SLING-8395 > URL: https://issues.apache.org/jira/browse/SLING-8395 > Project: Sling > Issue Type: Improvement > Components: Tooling >Reporter: Robert Munteanu >Priority: Major > Fix For: Committer CLI 1.0.2 > > > Some actions ( site update, starter update ) would require pushing code. > Ideally we would make these part a bot which issues pull requests which would > then be merged by a Sling Committer. > Major question is - how do we host this? Is Jenkins enough or do we need to > handle our own server (which would be a major disadvantage ). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-9301) CI validator does not take into account additional artifacts
[
https://issues.apache.org/jira/browse/SLING-9301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-9301:
Fix Version/s: Committer CLI 1.0.2
(was: Committer CLI 1.0.0)
> CI validator does not take into account additional artifacts
>
>
> Key: SLING-9301
> URL: https://issues.apache.org/jira/browse/SLING-9301
> Project: Sling
> Issue Type: Bug
> Components: Build and Source Control
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: Committer CLI 1.0.2
>
>
> When verifying a release that stages multiple artifacts, the CI status is
> printed for only one of them
> {noformat} $ ./run.sh release verify -r 2228
> org.apache.sling.repoinit.parser-1.6.2-source-release.zip
> GPG: signed by Bertrand Delacretaz (CODE SIGNING KEY)
> with key (id=0x77B6B69A9E4DCC6B;
> fingerprint=5EFF256585AC5FB607F6D46A77B6B69A9E4DCC6B)
> SHA-1: VALID (c2cf2ecfbdd9ae9de1c34b5c101a3cca5e89ee77)
> MD-5: VALID (cf819d39586ed9a7f2ab27b712354347)
> org.apache.sling.repoinit.parser-1.6.2.pom
> GPG: signed by Bertrand Delacretaz (CODE SIGNING KEY)
> with key (id=0x77B6B69A9E4DCC6B;
> fingerprint=5EFF256585AC5FB607F6D46A77B6B69A9E4DCC6B)
> SHA-1: VALID (a50ec0a3cd9d4cc351851e1fe2f0eb2fc4417263)
> MD-5: VALID (3fc5989f52b6d94a932c4e2ed1092b6e)
> org.apache.sling.jcr.repoinit-1.1.24-javadoc.jar
> GPG: signed by Bertrand Delacretaz (CODE SIGNING KEY)
> with key (id=0x77B6B69A9E4DCC6B;
> fingerprint=5EFF256585AC5FB607F6D46A77B6B69A9E4DCC6B)
> SHA-1: VALID (fe2eac7e58c88a2e1cb94df8890dd28aa9139fb8)
> MD-5: VALID (6557cc5774264eaf3b6b6a0cace03e29)
> org.apache.sling.jcr.repoinit-1.1.24-sources.jar
> GPG: signed by Bertrand Delacretaz (CODE SIGNING KEY)
> with key (id=0x77B6B69A9E4DCC6B;
> fingerprint=5EFF256585AC5FB607F6D46A77B6B69A9E4DCC6B)
> SHA-1: VALID (fc656cbb87cc4de9ed0a75b0832f5af98b86ec77)
> MD-5: VALID (2ddc5461e6a2dd9e7cc265055e857fbc)
> org.apache.sling.jcr.repoinit-1.1.24-source-release.zip
> GPG: signed by Bertrand Delacretaz (CODE SIGNING KEY)
> with key (id=0x77B6B69A9E4DCC6B;
> fingerprint=5EFF256585AC5FB607F6D46A77B6B69A9E4DCC6B)
> SHA-1: VALID (8bbcefb958396b0822e25c49cab0ab3cf8c36afa)
> MD-5: VALID (b8ff72fe65527861702117d70707)
> org.apache.sling.repoinit.parser-1.6.2.jar
> GPG: signed by Bertrand Delacretaz (CODE SIGNING KEY)
> with key (id=0x77B6B69A9E4DCC6B;
> fingerprint=5EFF256585AC5FB607F6D46A77B6B69A9E4DCC6B)
> SHA-1: VALID (54442784c12cb4fe5ae78a6c07d4833a4b814ebe)
> MD-5: VALID (1136e820a52c86e5e1621e9781a5302b)
> org.apache.sling.repoinit.parser-1.6.2-javadoc.jar
> GPG: signed by Bertrand Delacretaz (CODE SIGNING KEY)
> with key (id=0x77B6B69A9E4DCC6B;
> fingerprint=5EFF256585AC5FB607F6D46A77B6B69A9E4DCC6B)
> SHA-1: VALID (0aa8c275106c86d0717ff4a1b1255a6d39170603)
> MD-5: VALID (8c94789be7d15126f786942492d5cfd6)
> org.apache.sling.jcr.repoinit-1.1.24.jar
> GPG: signed by Bertrand Delacretaz (CODE SIGNING KEY)
> with key (id=0x77B6B69A9E4DCC6B;
> fingerprint=5EFF256585AC5FB607F6D46A77B6B69A9E4DCC6B)
> SHA-1: VALID (134f7c334d22f8187c6452762258a071ef454e77)
> MD-5: VALID (e4e73aff04aff5b49805229a03f9358b)
> org.apache.sling.jcr.repoinit-1.1.24.pom
> GPG: signed by Bertrand Delacretaz (CODE SIGNING KEY)
> with key (id=0x77B6B69A9E4DCC6B;
> fingerprint=5EFF256585AC5FB607F6D46A77B6B69A9E4DCC6B)
> SHA-1: VALID (255485068f952d548a24faa5766e918d4680f42c)
> MD-5: VALID (9765d12d2acd46073a0edbcf6bb769f4)
> org.apache.sling.repoinit.parser-1.6.2-sources.jar
> GPG: signed by Bertrand Delacretaz (CODE SIGNING KEY)
> with key (id=0x77B6B69A9E4DCC6B;
> fingerprint=5EFF256585AC5FB607F6D46A77B6B69A9E4DCC6B)
> SHA-1: VALID (bcde5285e0389198a170b0ececf022cad0cf9216)
> MD-5: VALID (15632480b50dd9f3421834d2bfafda39)
> CI Status: INVALID:
> continuous-integration/jenkins/branch
> State: error
> Description: This commit cannot be built
> See:
> https://builds.apache.org/job/Sling/job/sling-org-apache-sling-jcr-repoinit/job/master/311/display/redirect
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-8393) Create sub-command to update the Sling website when a release is made
[ https://issues.apache.org/jira/browse/SLING-8393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-8393: Fix Version/s: Committer CLI 1.0.2 (was: Committer CLI 1.0.0) > Create sub-command to update the Sling website when a release is made > - > > Key: SLING-8393 > URL: https://issues.apache.org/jira/browse/SLING-8393 > Project: Sling > Issue Type: Improvement > Components: Tooling >Reporter: Robert Munteanu >Priority: Major > Fix For: Committer CLI 1.0.2 > > > The current `release update-local-site` command generates a git diff when > ran. It would be useful to have the change committed and pushed to a remote > branch, ideally creating a PR for review. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-9083) Add support for authenticated requests when checking a release's build status
[
https://issues.apache.org/jira/browse/SLING-9083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-9083:
Fix Version/s: Committer CLI 1.0.2
(was: Committer CLI 1.0.0)
> Add support for authenticated requests when checking a release's build status
> -
>
> Key: SLING-9083
> URL: https://issues.apache.org/jira/browse/SLING-9083
> Project: Sling
> Issue Type: Improvement
> Components: Tooling
>Reporter: Radu Cotescu
>Priority: Major
> Fix For: Committer CLI 1.0.2
>
>
> The {{org.apache.sling.cli.impl.ci.CIStatusValidator}} checks if a release's
> build status is valid, when verifying a release. Depending on the network
> from which the requests originate, GitHub might enforce its API rate
> limiting, leading to a failure in the validator - the {{success}} JSON key is
> missing from the response. On one hand, the validator's JSON parsing could be
> improved to not fail if this key is missing. However, if a request is
> authenticated (usually with a GitHub access token), the rate limiting is not
> enforced (or better said the limit is so high that it should not be reached).
> This issue should implement both suggestions from above:
> # make the JSON parsing more resilient
> # optionally use a GitHub access token, if provided in the environment, to
> perform authenticated requests against the GitHub API
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-8394) Create sub-command to update the Sling starter when a release is made
[ https://issues.apache.org/jira/browse/SLING-8394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-8394: Fix Version/s: Committer CLI 1.0.2 (was: Committer CLI 1.0.0) > Create sub-command to update the Sling starter when a release is made > - > > Key: SLING-8394 > URL: https://issues.apache.org/jira/browse/SLING-8394 > Project: Sling > Issue Type: Improvement > Components: Tooling >Reporter: Robert Munteanu >Priority: Major > Fix For: Committer CLI 1.0.2 > > > The command should update the provisioning model files and then issue a pull > request against the starter repo. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-8808) Committer CLI does not record all votes from PMC members as binding
[
https://issues.apache.org/jira/browse/SLING-8808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-8808:
Fix Version/s: Committer CLI 1.0.2
(was: Committer CLI 1.0.0)
> Committer CLI does not record all votes from PMC members as binding
> ---
>
> Key: SLING-8808
> URL: https://issues.apache.org/jira/browse/SLING-8808
> Project: Sling
> Issue Type: Bug
> Components: Build and Source Control
>Reporter: Robert Munteanu
>Priority: Critical
> Fix For: Committer CLI 1.0.2
>
>
> {noformat}$ ./run.sh release tally-votes -r 2146
> The following email would be sent from your @apache.org address (see the
> "From:" header):
> From: Robert Munteanu
> To: "Sling Developers List"
> Reply-To: "Sling Developers List"
> Date: Mon, 28 Oct 2019 09:32:28 +
> Subject: [RESULT] [VOTE] Release Apache Sling Commons Threads 3.2.20
> Hi,
> The vote has passed with the following result:
> +1 (binding): Robert Munteanu, Carsten Ziegeler, Dan Klco, Radu Cotescu
> +1 (non-binding): David Bosschaert
> I will copy this release to the Sling dist directory and
> promote the artifacts to the central Maven repository.
> Regards,
> Robert Munteanu
> {noformat}
> David's vote is definitely binding.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SLING-11097) Committers CLI CI Fails on Tags
[ https://issues.apache.org/jira/browse/SLING-11097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu resolved SLING-11097. -- Resolution: Fixed > Committers CLI CI Fails on Tags > --- > > Key: SLING-11097 > URL: https://issues.apache.org/jira/browse/SLING-11097 > Project: Sling > Issue Type: Improvement >Reporter: Dan Klco >Assignee: Dan Klco >Priority: Major > Fix For: Committer CLI 1.0.0 > > > Currently for most (if not all) releases the Sling Committer CLI fails to > validate the release because the CI check fails. > This is because our Jenkins jobs do not execute on tags and therefore the CI > check doesn't see a success code for the tag commit's build status. > It seems not trivial to add builds on tags to Jenkins (though someone who > knows Jenkins DSL may know better than I) but either way it would seem like a > good idea to check the parent commit's build status if the tag commit does > not have a build status. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-11816) Transliterated project member names break the vote counting algorithm
[ https://issues.apache.org/jira/browse/SLING-11816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu resolved SLING-11816. -- Resolution: Fixed > Transliterated project member names break the vote counting algorithm > - > > Key: SLING-11816 > URL: https://issues.apache.org/jira/browse/SLING-11816 > Project: Sling > Issue Type: Bug > Components: Tooling >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: Committer CLI 1.0.0 > > > If a project member provides their name using transliterated forms between > Whimsy and their email address, the CLI tool won't be able to correctly > record their names when it comes to counting the votes in a release tally > email. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-11816) Transliterated project member names break the vote counting algorithm
Radu Cotescu created SLING-11816: Summary: Transliterated project member names break the vote counting algorithm Key: SLING-11816 URL: https://issues.apache.org/jira/browse/SLING-11816 Project: Sling Issue Type: Bug Components: Tooling Reporter: Radu Cotescu Assignee: Radu Cotescu Fix For: Committer CLI 1.0.0 If a project member provides their name using transliterated forms between Whimsy and their email address, the CLI tool won't be able to correctly record their names when it comes to counting the votes in a release tally email. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-11775) Update the Sling Resource Merger to parent pom version 49
[ https://issues.apache.org/jira/browse/SLING-11775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu closed SLING-11775. > Update the Sling Resource Merger to parent pom version 49 > - > > Key: SLING-11775 > URL: https://issues.apache.org/jira/browse/SLING-11775 > Project: Sling > Issue Type: Improvement > Components: Extensions >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: Resource Merger 1.4.2 > > > The Sling Resource Merger should use the latest available parent pom. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-11773) ResourceTypeHierarchyBasedResourcePicker not working anymore
[
https://issues.apache.org/jira/browse/SLING-11773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu closed SLING-11773.
> ResourceTypeHierarchyBasedResourcePicker not working anymore
>
>
> Key: SLING-11773
> URL: https://issues.apache.org/jira/browse/SLING-11773
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Resource Merger 1.4.0
>Reporter: Sagar Miglani
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Resource Merger 1.4.2
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> In SLING-10168, SCR annotations were replaced by OSGi and configurations of
> {{ResourceTypeHierarchyBasedResourcePicker}} have been designated to an inner
> Configuration class, which are not getting bind properly without
> {{@Activate}} Method.
> And hence {{ResourceTypeHierarchyBasedResourcePicker}} does not seem to be
> registered by
> {{MergedResourcePickerWhiteboard}} [0].
> Compared generated XMLs:
> *With {{Activate}} Method injection:*
> {code:xml}
>
> http://www.osgi.org/xmlns/scr/v1.3.0;
> name="org.apache.sling.resourcemerger.picker.overriding"
> configuration-policy="require" activate="activate">
>
>
>
>
> interface="org.apache.sling.resourcemerger.spi.MergedResourcePicker2"/>
>
> class="org.apache.sling.resourcemerger.impl.picker.ResourceTypeHierarchyBasedResourcePicker"/>
>
> {code}
> *Without {{@Activate}} method injection:*
> {code:xml}
>
> http://www.osgi.org/xmlns/scr/v1.3.0;
> name="org.apache.sling.resourcemerger.picker.overriding"
> configuration-policy="require">
>
>
> interface="org.apache.sling.resourcemerger.spi.MergedResourcePicker2"/>
>
>class="org.apache.sling.resourcemerger.impl.picker.ResourceTypeHierarchyBasedResourcePicker"/>
>
> {code}
> [0]:
> https://github.com/apache/sling-org-apache-sling-resourcemerger/blob/master/src/main/java/org/apache/sling/resourcemerger/impl/MergedResourcePickerWhiteboard.java#L87
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SLING-11506) Streamline and document resource (super) type merging
[
https://issues.apache.org/jira/browse/SLING-11506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu closed SLING-11506.
> Streamline and document resource (super) type merging
> -
>
> Key: SLING-11506
> URL: https://issues.apache.org/jira/browse/SLING-11506
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
>Affects Versions: Resource Merger 1.4.0
>Reporter: Konrad Windszus
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: Resource Merger 1.4.2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In SLING-4340 the merging of resource types has been changed so that it gives
> the resourceType property precedence over {{Resource.getResourceType()}}
> (https://github.com/apache/sling-org-apache-sling-resourcemerger/blob/f821f844ba675e3850189debf8e45239026c5709/src/main/java/org/apache/sling/resourcemerger/impl/MergedResource.java#L74-L92).
> This change is questionable and kind of unexpected from the user's side and
> also leads to undesired side effects like outlined in SLING-11504.
> So in the best case the merging of resource types doesn't rely on properties
> (which are implementation details of the underlying resolvers) but clearly
> derives from either the lowest or highest resource without breaking the use
> cases outlined in SLING-4340.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SLING-11776) Sling ResourceMerger may cause high cpu utilization
[
https://issues.apache.org/jira/browse/SLING-11776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu closed SLING-11776.
> Sling ResourceMerger may cause high cpu utilization
> ---
>
> Key: SLING-11776
> URL: https://issues.apache.org/jira/browse/SLING-11776
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Resource Merger 1.4.0
>Reporter: Sagar Miglani
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: Resource Merger 1.4.2
>
> Attachments: SLING-11776.patch, SLING-11776_test.patch,
> SLING-11776_with_logs.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> If a bogus path like the following is used, resource merger can consume high
> amount of CPU and may lead to Denial of Service:
> {code:xml}
> /mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override
> {code}
> *Steps to reproduce*
> # Spawn an AEM author instance and login
> # Open
> [http://localhost:4502/aem/start.html//mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override]
> OR use
> curl -u :
> [http://localhost:4502/aem/start.html//mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override/mnt/override]
> In
> [MergingResourceProvider|https://github.com/apache/sling-org-apache-sling-resourcemerger/blob/master/src/main/java/org/apache/sling/resourcemerger/impl/MergingResourceProvider.java#L164-L174],
> we are calculating the relative path, which is just removing the merge root
> path from from the actual path.
> And this relative path is used for finding the resources under it.
> eg: if path is {{/mnt/override/mnt/override/mnt/override/bin}} then relative
> path will be {{/mnt/override/mnt/override}}
> And because this relative path again starts with {{/mnt/override}} again
> [MergingResourceProvider|https://github.com/apache/sling-org-apache-sling-resourcemerger/blob/master/src/main/java/org/apache/sling/resourcemerger/impl/MergingResourceProvider.java]
> will be picked and same calls will be executed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-11796) The ResourceResolverFactory dependency should be dynamic
[
https://issues.apache.org/jira/browse/SLING-11796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-11796:
-
Description: The {{BundledScriptTracker}} requires the
{{ResourceResolverFactory}} to determine servlets for resource types should be
added to the servlets hierarchy. However, in a system with a large number of
servlets a restart of the {{ResourceResolverFactory}} forces the servlets'
reregistration. This is an expensive operation which should happen if really
required. Since the tracker only needs the search path information from the
{{ResourceResolverFactory}}, this reference should be made dynamic and the
tracker should reregister the servlets only in the case the search paths array
has changed. (was: The {{BundledScriptTracker}} requires the
{{ResourceResolverFactory}} to determine servlets for resource types should be
added to the servlets hierarchy. However, in a system with a large number of
servlets a restart of the {{ResourceResolverFactory}} forces the servlets'
reregistration. This is an expensive operation which should only happen if
really required. Since the tracker only needs the search path information from
the {{ResourceResolverFactory}}, this reference should be made dynamic and the
tracker should only reregister the servlets if a search paths array change has
been detected.)
> The ResourceResolverFactory dependency should be dynamic
>
>
> Key: SLING-11796
> URL: https://issues.apache.org/jira/browse/SLING-11796
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
>Affects Versions: Servlets Resolver 2.9.4
>Reporter: Radu Cotescu
>Priority: Major
> Fix For: Servlets Resolver 2.9.12
>
>
> The {{BundledScriptTracker}} requires the {{ResourceResolverFactory}} to
> determine servlets for resource types should be added to the servlets
> hierarchy. However, in a system with a large number of servlets a restart of
> the {{ResourceResolverFactory}} forces the servlets' reregistration. This is
> an expensive operation which should happen if really required. Since the
> tracker only needs the search path information from the
> {{ResourceResolverFactory}}, this reference should be made dynamic and the
> tracker should reregister the servlets only in the case the search paths
> array has changed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SLING-11796) The ResourceResolverFactory dependency should be dynamic
Radu Cotescu created SLING-11796:
Summary: The ResourceResolverFactory dependency should be dynamic
Key: SLING-11796
URL: https://issues.apache.org/jira/browse/SLING-11796
Project: Sling
Issue Type: Improvement
Components: Servlets
Affects Versions: Servlets Resolver 2.9.4
Reporter: Radu Cotescu
Fix For: Servlets Resolver 2.9.12
The {{BundledScriptTracker}} requires the {{ResourceResolverFactory}} to
determine servlets for resource types should be added to the servlets
hierarchy. However, in a system with a large number of servlets a restart of
the {{ResourceResolverFactory}} forces the servlets' reregistration. This is an
expensive operation which should only happen if really required. Since the
tracker only needs the search path information from the
{{ResourceResolverFactory}}, this reference should be made dynamic and the
tracker should only reregister the servlets if a search paths array change has
been detected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SLING-11779) Implement mixin support for JCR Mock
[ https://issues.apache.org/jira/browse/SLING-11779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu closed SLING-11779. > Implement mixin support for JCR Mock > > > Key: SLING-11779 > URL: https://issues.apache.org/jira/browse/SLING-11779 > Project: Sling > Issue Type: Improvement > Components: Testing >Affects Versions: Testing JCR Mock 1.6.0 >Reporter: Joerg Hoh >Assignee: Stefan Seifert >Priority: Major > Fix For: Testing JCR Mock 1.6.2 > > > Add rudimentary support for mixins into the JCR Mock library. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-11775) Update the Sling Resource Merger to parent pom version 49
[ https://issues.apache.org/jira/browse/SLING-11775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693114#comment-17693114 ] Radu Cotescu commented on SLING-11775: -- Fixed in https://github.com/apache/sling-org-apache-sling-resourcemerger/commit/622f3b3fae9cacb8a846a027a661fab6a4e673d7. > Update the Sling Resource Merger to parent pom version 49 > - > > Key: SLING-11775 > URL: https://issues.apache.org/jira/browse/SLING-11775 > Project: Sling > Issue Type: Improvement > Components: Extensions >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: Resource Merger 1.4.2 > > > The Sling Resource Merger should use the latest available parent pom. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-11775) Update the Sling Resource Merger to parent pom version 49
[ https://issues.apache.org/jira/browse/SLING-11775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu resolved SLING-11775. -- Resolution: Fixed > Update the Sling Resource Merger to parent pom version 49 > - > > Key: SLING-11775 > URL: https://issues.apache.org/jira/browse/SLING-11775 > Project: Sling > Issue Type: Improvement > Components: Extensions >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: Resource Merger 1.4.2 > > > The Sling Resource Merger should use the latest available parent pom. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-11779) Implement mixin support for JCR Mock
[ https://issues.apache.org/jira/browse/SLING-11779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-11779: - Fix Version/s: Testing JCR Mock 1.6.2 > Implement mixin support for JCR Mock > > > Key: SLING-11779 > URL: https://issues.apache.org/jira/browse/SLING-11779 > Project: Sling > Issue Type: Improvement > Components: Testing >Affects Versions: Testing JCR Mock 1.6.0 >Reporter: Joerg Hoh >Assignee: Stefan Seifert >Priority: Major > Fix For: Testing JCR Mock 1.6.2 > > > Add rudimentary support for mixins into the JCR Mock library. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-11768) Display Context "scriptString" encodes hyphen (-) as \u002D
[
https://issues.apache.org/jira/browse/SLING-11768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17692004#comment-17692004
]
Radu Cotescu commented on SLING-11768:
--
[~kwin], this seems to be the commit that encoded the dash like we see it now:
https://github.com/apache/sling-org-apache-sling-xss/commit/bf2fb9bfb7aad00ece84456b3bd0a015d61788b9
I have to agree with the observations from the commit and the subsequent
comments from SLING-5946/SLING-8879. This issue is therefore not in the HTL
implementation, but in the XSS bundle.
> Display Context "scriptString" encodes hyphen (-) as \u002D
> ---
>
> Key: SLING-11768
> URL: https://issues.apache.org/jira/browse/SLING-11768
> Project: Sling
> Issue Type: Bug
> Components: HTL, XSS Protection API
>Reporter: Konrad Windszus
>Priority: Major
>
> According to
> https://github.com/adobe/htl-spec/blob/master/SPECIFICATION.md#121-display-context
> the context {{scriptString}} should only encode
> {quote}
> ... characters that would break out of the string.
> {quote}
> But {{AAA-BBB}} incorrectly becomes {{AAA\u002DBBB}} through this context
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-11768) Display Context "scriptString" encodes hyphen (-) as \u002D
[
https://issues.apache.org/jira/browse/SLING-11768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-11768:
-
Component/s: (was: XSS Protection API)
> Display Context "scriptString" encodes hyphen (-) as \u002D
> ---
>
> Key: SLING-11768
> URL: https://issues.apache.org/jira/browse/SLING-11768
> Project: Sling
> Issue Type: Bug
> Components: HTL
>Reporter: Konrad Windszus
>Priority: Major
>
> According to
> https://github.com/adobe/htl-spec/blob/master/SPECIFICATION.md#121-display-context
> the context {{scriptString}} should only encode
> {quote}
> ... characters that would break out of the string.
> {quote}
> But {{AAA-BBB}} incorrectly becomes {{AAA\u002DBBB}} through this context
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-11722) The SlingRequestDispatcher doesn't correctly implement the RequestDispatcher API
[
https://issues.apache.org/jira/browse/SLING-11722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17691602#comment-17691602
]
Radu Cotescu commented on SLING-11722:
--
This should be good to go from the POV of the spec. When the two new configs
are enabled it might affect scripts written in JSP, since that engine sets by
default a content type. Depending on the request's rendering chain some JSP
scripts might need to be refactored.
> The SlingRequestDispatcher doesn't correctly implement the RequestDispatcher
> API
>
>
> Key: SLING-11722
> URL: https://issues.apache.org/jira/browse/SLING-11722
> Project: Sling
> Issue Type: Bug
> Components: Engine
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Engine 2.13.4
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> The {{include}} method [0] has the following important sentence in its
> documentation:
> {quote}
> The ServletResponse object has its path elements and parameters remain
> unchanged from the caller's. The included servlet cannot change the response
> status code or set headers; any attempt to make a change is ignored.
> {quote}
> However, the {{SlingRequestDispatcher}} [1] doesn't enforce this in any way.
> [0] -
> https://docs.oracle.com/javaee/7/api/javax/servlet/RequestDispatcher.html#include-javax.servlet.ServletRequest-javax.servlet.ServletResponse-
> [1] -
> https://github.com/apache/sling-org-apache-sling-engine/blob/bbc6acca70e7a27386f47fa9733af3740985f375/src/main/java/org/apache/sling/engine/impl/request/SlingRequestDispatcher.java#L177
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SLING-11722) The SlingRequestDispatcher doesn't correctly implement the RequestDispatcher API
[
https://issues.apache.org/jira/browse/SLING-11722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu resolved SLING-11722.
--
Resolution: Fixed
> The SlingRequestDispatcher doesn't correctly implement the RequestDispatcher
> API
>
>
> Key: SLING-11722
> URL: https://issues.apache.org/jira/browse/SLING-11722
> Project: Sling
> Issue Type: Bug
> Components: Engine
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Engine 2.13.4
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> The {{include}} method [0] has the following important sentence in its
> documentation:
> {quote}
> The ServletResponse object has its path elements and parameters remain
> unchanged from the caller's. The included servlet cannot change the response
> status code or set headers; any attempt to make a change is ignored.
> {quote}
> However, the {{SlingRequestDispatcher}} [1] doesn't enforce this in any way.
> [0] -
> https://docs.oracle.com/javaee/7/api/javax/servlet/RequestDispatcher.html#include-javax.servlet.ServletRequest-javax.servlet.ServletResponse-
> [1] -
> https://github.com/apache/sling-org-apache-sling-engine/blob/bbc6acca70e7a27386f47fa9733af3740985f375/src/main/java/org/apache/sling/engine/impl/request/SlingRequestDispatcher.java#L177
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (SLING-11722) The SlingRequestDispatcher doesn't correctly implement the RequestDispatcher API
[
https://issues.apache.org/jira/browse/SLING-11722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17645173#comment-17645173
]
Radu Cotescu edited comment on SLING-11722 at 2/21/23 1:24 PM:
---
Fixed in [commit
5d8df33|https://github.com/apache/sling-org-apache-sling-engine/commit/5d8df33]
and commit
[ece93401|https://github.com/apache/sling-org-apache-sling-engine/commit/ece93401392f7fb3b75b02af62d392e75120d245].
was (Author: radu.cotescu):
Fixed in [commit
5d8df33|https://github.com/apache/sling-org-apache-sling-engine/commit/5d8df33].
> The SlingRequestDispatcher doesn't correctly implement the RequestDispatcher
> API
>
>
> Key: SLING-11722
> URL: https://issues.apache.org/jira/browse/SLING-11722
> Project: Sling
> Issue Type: Bug
> Components: Engine
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Engine 2.13.4
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> The {{include}} method [0] has the following important sentence in its
> documentation:
> {quote}
> The ServletResponse object has its path elements and parameters remain
> unchanged from the caller's. The included servlet cannot change the response
> status code or set headers; any attempt to make a change is ignored.
> {quote}
> However, the {{SlingRequestDispatcher}} [1] doesn't enforce this in any way.
> [0] -
> https://docs.oracle.com/javaee/7/api/javax/servlet/RequestDispatcher.html#include-javax.servlet.ServletRequest-javax.servlet.ServletResponse-
> [1] -
> https://github.com/apache/sling-org-apache-sling-engine/blob/bbc6acca70e7a27386f47fa9733af3740985f375/src/main/java/org/apache/sling/engine/impl/request/SlingRequestDispatcher.java#L177
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SLING-11774) Fix the registration of the MergedResourcePicker2 implementations
[ https://issues.apache.org/jira/browse/SLING-11774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu closed SLING-11774. > Fix the registration of the MergedResourcePicker2 implementations > - > > Key: SLING-11774 > URL: https://issues.apache.org/jira/browse/SLING-11774 > Project: Sling > Issue Type: Bug > Components: Extensions >Affects Versions: Resource Merger 1.4.0 >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > It seems the improvement from SLING-10168 introduced a subtle bug, where the > components are registered only based on configuration properties, completely > ignoring their default configuration (where applicable). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-11774) Fix the registration of the MergedResourcePicker2 implementations
[ https://issues.apache.org/jira/browse/SLING-11774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-11774: - Fix Version/s: (was: Resource Merger 1.4.2) > Fix the registration of the MergedResourcePicker2 implementations > - > > Key: SLING-11774 > URL: https://issues.apache.org/jira/browse/SLING-11774 > Project: Sling > Issue Type: Bug > Components: Extensions >Affects Versions: Resource Merger 1.4.0 >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > It seems the improvement from SLING-10168 introduced a subtle bug, where the > components are registered only based on configuration properties, completely > ignoring their default configuration (where applicable). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-11774) Fix the registration of the MergedResourcePicker2 implementations
[ https://issues.apache.org/jira/browse/SLING-11774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu resolved SLING-11774. -- Resolution: Duplicate > Fix the registration of the MergedResourcePicker2 implementations > - > > Key: SLING-11774 > URL: https://issues.apache.org/jira/browse/SLING-11774 > Project: Sling > Issue Type: Bug > Components: Extensions >Affects Versions: Resource Merger 1.4.0 >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > It seems the improvement from SLING-10168 introduced a subtle bug, where the > components are registered only based on configuration properties, completely > ignoring their default configuration (where applicable). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-11773) ResourceTypeHierarchyBasedResourcePicker not working anymore
[
https://issues.apache.org/jira/browse/SLING-11773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu resolved SLING-11773.
--
Resolution: Fixed
Fixed in
https://github.com/apache/sling-org-apache-sling-resourcemerger/commit/c8c05f1c72d5269b8453c7539d4c33824755f61a.
> ResourceTypeHierarchyBasedResourcePicker not working anymore
>
>
> Key: SLING-11773
> URL: https://issues.apache.org/jira/browse/SLING-11773
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Resource Merger 1.4.0
>Reporter: Sagar Miglani
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Resource Merger 1.4.2
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> In SLING-10168, SCR annotations were replaced by OSGi and configurations of
> {{ResourceTypeHierarchyBasedResourcePicker}} have been designated to an inner
> Configuration class, which are not getting bind properly without
> {{@Activate}} Method.
> And hence {{ResourceTypeHierarchyBasedResourcePicker}} does not seem to be
> registered by
> {{MergedResourcePickerWhiteboard}} [0].
> Compared generated XMLs:
> *With {{Activate}} Method injection:*
> {code:xml}
>
> http://www.osgi.org/xmlns/scr/v1.3.0;
> name="org.apache.sling.resourcemerger.picker.overriding"
> configuration-policy="require" activate="activate">
>
>
>
>
> interface="org.apache.sling.resourcemerger.spi.MergedResourcePicker2"/>
>
> class="org.apache.sling.resourcemerger.impl.picker.ResourceTypeHierarchyBasedResourcePicker"/>
>
> {code}
> *Without {{@Activate}} method injection:*
> {code:xml}
>
> http://www.osgi.org/xmlns/scr/v1.3.0;
> name="org.apache.sling.resourcemerger.picker.overriding"
> configuration-policy="require">
>
>
> interface="org.apache.sling.resourcemerger.spi.MergedResourcePicker2"/>
>
>class="org.apache.sling.resourcemerger.impl.picker.ResourceTypeHierarchyBasedResourcePicker"/>
>
> {code}
> [0]:
> https://github.com/apache/sling-org-apache-sling-resourcemerger/blob/master/src/main/java/org/apache/sling/resourcemerger/impl/MergedResourcePickerWhiteboard.java#L87
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-11773) ResourceTypeHierarchyBasedResourcePicker not working anymore
[
https://issues.apache.org/jira/browse/SLING-11773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-11773:
-
Fix Version/s: Resource Merger 1.4.2
> ResourceTypeHierarchyBasedResourcePicker not working anymore
>
>
> Key: SLING-11773
> URL: https://issues.apache.org/jira/browse/SLING-11773
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Resource Merger 1.4.0
>Reporter: Sagar Miglani
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Resource Merger 1.4.2
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> In SLING-10168, SCR annotations were replaced by OSGi and configurations of
> {{ResourceTypeHierarchyBasedResourcePicker}} have been designated to an inner
> Configuration class, which are not getting bind properly without
> {{@Activate}} Method.
> And hence {{ResourceTypeHierarchyBasedResourcePicker}} does not seem to be
> registered by
> {{MergedResourcePickerWhiteboard}} [0].
> Compared generated XMLs:
> *With {{Activate}} Method injection:*
> {code:xml}
>
> http://www.osgi.org/xmlns/scr/v1.3.0;
> name="org.apache.sling.resourcemerger.picker.overriding"
> configuration-policy="require" activate="activate">
>
>
>
>
> interface="org.apache.sling.resourcemerger.spi.MergedResourcePicker2"/>
>
> class="org.apache.sling.resourcemerger.impl.picker.ResourceTypeHierarchyBasedResourcePicker"/>
>
> {code}
> *Without {{@Activate}} method injection:*
> {code:xml}
>
> http://www.osgi.org/xmlns/scr/v1.3.0;
> name="org.apache.sling.resourcemerger.picker.overriding"
> configuration-policy="require">
>
>
> interface="org.apache.sling.resourcemerger.spi.MergedResourcePicker2"/>
>
>class="org.apache.sling.resourcemerger.impl.picker.ResourceTypeHierarchyBasedResourcePicker"/>
>
> {code}
> [0]:
> https://github.com/apache/sling-org-apache-sling-resourcemerger/blob/master/src/main/java/org/apache/sling/resourcemerger/impl/MergedResourcePickerWhiteboard.java#L87
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (SLING-11775) Update the Sling Resource Merger to parent pom version 49
[ https://issues.apache.org/jira/browse/SLING-11775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu reassigned SLING-11775: Assignee: Radu Cotescu > Update the Sling Resource Merger to parent pom version 49 > - > > Key: SLING-11775 > URL: https://issues.apache.org/jira/browse/SLING-11775 > Project: Sling > Issue Type: Improvement > Components: Extensions >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: Resource Merger 1.4.2 > > > The Sling Resource Merger should use the latest available parent pom. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-11775) Update the Sling Resource Merger to parent pom version 49
[ https://issues.apache.org/jira/browse/SLING-11775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-11775: - Summary: Update the Sling Resource Merger to parent pom version 49 (was: Update the Sling Resource Merger to parernt pom version 49) > Update the Sling Resource Merger to parent pom version 49 > - > > Key: SLING-11775 > URL: https://issues.apache.org/jira/browse/SLING-11775 > Project: Sling > Issue Type: Improvement > Components: Extensions >Reporter: Radu Cotescu >Priority: Major > Fix For: Resource Merger 1.4.2 > > > The Sling Resource Merger should use the latest available parent pom. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-11775) Update the Sling Resource Merger to parernt pom version 49
[ https://issues.apache.org/jira/browse/SLING-11775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-11775: - Summary: Update the Sling Resource Merger to parernt pom version 49 (was: Update the Sling Resource Merger to pom version 49) > Update the Sling Resource Merger to parernt pom version 49 > -- > > Key: SLING-11775 > URL: https://issues.apache.org/jira/browse/SLING-11775 > Project: Sling > Issue Type: Improvement > Components: Extensions >Reporter: Radu Cotescu >Priority: Major > Fix For: Resource Merger 1.4.2 > > > The Sling Resource Merger should use the latest available parent pom. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-11775) Update the Sling Resource Merger to pom version 49
Radu Cotescu created SLING-11775: Summary: Update the Sling Resource Merger to pom version 49 Key: SLING-11775 URL: https://issues.apache.org/jira/browse/SLING-11775 Project: Sling Issue Type: Improvement Components: Extensions Reporter: Radu Cotescu Fix For: Resource Merger 1.4.2 The Sling Resource Merger should use the latest available parent pom. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (SLING-11773) ResourceTypeHierarchyBasedResourcePicker not working anymore
[
https://issues.apache.org/jira/browse/SLING-11773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu reassigned SLING-11773:
Assignee: Radu Cotescu
> ResourceTypeHierarchyBasedResourcePicker not working anymore
>
>
> Key: SLING-11773
> URL: https://issues.apache.org/jira/browse/SLING-11773
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Resource Merger 1.4.0
>Reporter: Sagar Miglani
>Assignee: Radu Cotescu
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> In SLING-10168, SCR annotations were replaced by OSGi and configurations of
> {{ResourceTypeHierarchyBasedResourcePicker}} have been designated to an inner
> Configuration class, which are not getting bind properly without
> {{@Activate}} Method.
> And hence {{ResourceTypeHierarchyBasedResourcePicker}} does not seem to be
> registered by
> {{MergedResourcePickerWhiteboard}} [0].
> Compared generated XMLs:
> *With {{Activate}} Method injection:*
> {code:xml}
>
> http://www.osgi.org/xmlns/scr/v1.3.0;
> name="org.apache.sling.resourcemerger.picker.overriding"
> configuration-policy="require" activate="activate">
>
>
>
>
> interface="org.apache.sling.resourcemerger.spi.MergedResourcePicker2"/>
>
> class="org.apache.sling.resourcemerger.impl.picker.ResourceTypeHierarchyBasedResourcePicker"/>
>
> {code}
> *Without {{@Activate}} method injection:*
> {code:xml}
>
> http://www.osgi.org/xmlns/scr/v1.3.0;
> name="org.apache.sling.resourcemerger.picker.overriding"
> configuration-policy="require">
>
>
> interface="org.apache.sling.resourcemerger.spi.MergedResourcePicker2"/>
>
>class="org.apache.sling.resourcemerger.impl.picker.ResourceTypeHierarchyBasedResourcePicker"/>
>
> {code}
> [0]:
> https://github.com/apache/sling-org-apache-sling-resourcemerger/blob/master/src/main/java/org/apache/sling/resourcemerger/impl/MergedResourcePickerWhiteboard.java#L87
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (SLING-11773) ResourceTypeHierarchyBasedResourcePicker not working anymore
[
https://issues.apache.org/jira/browse/SLING-11773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17688346#comment-17688346
]
Radu Cotescu edited comment on SLING-11773 at 2/14/23 7:53 AM:
---
There's an additional issue though. With the migration, the components are
registered only based on the configuration properties. The registration
properties are ignored. See SLING-11774. I already have a fix that I'm testing,
haven't committed it yet.
Regarding
bq. That sounds like a bug in the underlying bnd library.
I had thought the same and updated to the latest parent pom, but then I figured
out that the default service registration properties were generated. If you
look at the other picker, its component properties are generated due to the use
of the configuration in the activate method.
was (Author: radu.cotescu):
There's an additional issue though. With the migration, the components are
registered only based on the configuration properties. The registration
properties are ignored. See SLING-11774. I already have a fix that I'm testing,
haven't committed it yet.
> ResourceTypeHierarchyBasedResourcePicker not working anymore
>
>
> Key: SLING-11773
> URL: https://issues.apache.org/jira/browse/SLING-11773
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Resource Merger 1.4.0
>Reporter: Sagar Miglani
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> In SLING-10168, SCR annotations were replaced by OSGi and configurations of
> {{ResourceTypeHierarchyBasedResourcePicker}} have been designated to an inner
> Configuration class, which are not getting bind properly without
> {{@Activate}} Method.
> And hence {{ResourceTypeHierarchyBasedResourcePicker}} does not seem to be
> registered by
> {{MergedResourcePickerWhiteboard}} [0].
> Compared generated XMLs:
> *With {{Activate}} Method injection:*
> {code:xml}
>
> http://www.osgi.org/xmlns/scr/v1.3.0;
> name="org.apache.sling.resourcemerger.picker.overriding"
> configuration-policy="require" activate="activate">
>
>
>
>
> interface="org.apache.sling.resourcemerger.spi.MergedResourcePicker2"/>
>
> class="org.apache.sling.resourcemerger.impl.picker.ResourceTypeHierarchyBasedResourcePicker"/>
>
> {code}
> *Without {{@Activate}} method injection:*
> {code:xml}
>
> http://www.osgi.org/xmlns/scr/v1.3.0;
> name="org.apache.sling.resourcemerger.picker.overriding"
> configuration-policy="require">
>
>
> interface="org.apache.sling.resourcemerger.spi.MergedResourcePicker2"/>
>
>class="org.apache.sling.resourcemerger.impl.picker.ResourceTypeHierarchyBasedResourcePicker"/>
>
> {code}
> [0]:
> https://github.com/apache/sling-org-apache-sling-resourcemerger/blob/master/src/main/java/org/apache/sling/resourcemerger/impl/MergedResourcePickerWhiteboard.java#L87
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-11773) ResourceTypeHierarchyBasedResourcePicker not working anymore
[
https://issues.apache.org/jira/browse/SLING-11773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17688346#comment-17688346
]
Radu Cotescu commented on SLING-11773:
--
There's an additional issue though. With the migration, the components are
registered only based on the configuration properties. The registration
properties are ignored. See SLING-11774. I already have a fix that I'm testing,
haven't committed it yet.
> ResourceTypeHierarchyBasedResourcePicker not working anymore
>
>
> Key: SLING-11773
> URL: https://issues.apache.org/jira/browse/SLING-11773
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Resource Merger 1.4.0
>Reporter: Sagar Miglani
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> In SLING-10168, SCR annotations were replaced by OSGi and configurations of
> {{ResourceTypeHierarchyBasedResourcePicker}} have been designated to an inner
> Configuration class, which are not getting bind properly without
> {{@Activate}} Method.
> And hence {{ResourceTypeHierarchyBasedResourcePicker}} does not seem to be
> registered by
> {{MergedResourcePickerWhiteboard}} [0].
> Compared generated XMLs:
> *With {{Activate}} Method injection:*
> {code:xml}
>
> http://www.osgi.org/xmlns/scr/v1.3.0;
> name="org.apache.sling.resourcemerger.picker.overriding"
> configuration-policy="require" activate="activate">
>
>
>
>
> interface="org.apache.sling.resourcemerger.spi.MergedResourcePicker2"/>
>
> class="org.apache.sling.resourcemerger.impl.picker.ResourceTypeHierarchyBasedResourcePicker"/>
>
> {code}
> *Without {{@Activate}} method injection:*
> {code:xml}
>
> http://www.osgi.org/xmlns/scr/v1.3.0;
> name="org.apache.sling.resourcemerger.picker.overriding"
> configuration-policy="require">
>
>
> interface="org.apache.sling.resourcemerger.spi.MergedResourcePicker2"/>
>
>class="org.apache.sling.resourcemerger.impl.picker.ResourceTypeHierarchyBasedResourcePicker"/>
>
> {code}
> [0]:
> https://github.com/apache/sling-org-apache-sling-resourcemerger/blob/master/src/main/java/org/apache/sling/resourcemerger/impl/MergedResourcePickerWhiteboard.java#L87
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (SLING-11774) Fix the registration of the MergedResourcePicker2 implementations
[ https://issues.apache.org/jira/browse/SLING-11774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17688345#comment-17688345 ] Radu Cotescu edited comment on SLING-11774 at 2/14/23 7:46 AM: --- Ha, yes! It's the same issue. But there's a bit more to it - in addition to that, when the migration was done, only the configuration properties were passed to the pickers. Before we were also passing the registration properties from the ServiceReference. was (Author: radu.cotescu): Ha, yes! It's the same issue. But there's a bit more to it - in addition to that, when the migration was done, only the configuration properties were passed to the pickers. Before we were also passing the registration properties from the ServiceReference. Anyways, let's continue in SLING-11773. > Fix the registration of the MergedResourcePicker2 implementations > - > > Key: SLING-11774 > URL: https://issues.apache.org/jira/browse/SLING-11774 > Project: Sling > Issue Type: Bug > Components: Extensions >Affects Versions: Resource Merger 1.4.0 >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: Resource Merger 1.4.2 > > > It seems the improvement from SLING-10168 introduced a subtle bug, where the > components are registered only based on configuration properties, completely > ignoring their default configuration (where applicable). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-11774) Fix the registration of the MergedResourcePicker2 implementations
[ https://issues.apache.org/jira/browse/SLING-11774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17688345#comment-17688345 ] Radu Cotescu commented on SLING-11774: -- Ha, yes! It's the same issue. But there's a bit more to it - in addition to that, when the migration was done, only the configuration properties were passed to the pickers. Before we were also passing the registration properties from the ServiceReference. Anyways, let's continue in SLING-11773. > Fix the registration of the MergedResourcePicker2 implementations > - > > Key: SLING-11774 > URL: https://issues.apache.org/jira/browse/SLING-11774 > Project: Sling > Issue Type: Bug > Components: Extensions >Affects Versions: Resource Merger 1.4.0 >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: Resource Merger 1.4.2 > > > It seems the improvement from SLING-10168 introduced a subtle bug, where the > components are registered only based on configuration properties, completely > ignoring their default configuration (where applicable). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (SLING-11774) Fix the registration of the MergedResourcePicker2 implementations
[ https://issues.apache.org/jira/browse/SLING-11774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu reassigned SLING-11774: Assignee: Radu Cotescu > Fix the registration of the MergedResourcePicker2 implementations > - > > Key: SLING-11774 > URL: https://issues.apache.org/jira/browse/SLING-11774 > Project: Sling > Issue Type: Bug > Components: Extensions >Affects Versions: Resource Merger 1.4.0 >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: Resource Merger 1.4.2 > > > It seems the improvement from SLING-10168 introduced a subtle bug, where the > components are registered only based on configuration properties, completely > ignoring their default configuration (where applicable). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-11774) Fix the registration of the MergedResourcePicker2 implementations
Radu Cotescu created SLING-11774: Summary: Fix the registration of the MergedResourcePicker2 implementations Key: SLING-11774 URL: https://issues.apache.org/jira/browse/SLING-11774 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Resource Merger 1.4.0 Reporter: Radu Cotescu Fix For: Resource Merger 1.4.2 It seems the improvement from SLING-10168 introduced a subtle bug, where the components are registered only based on configuration properties, completely ignoring their default configuration (where applicable). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-11724) Improve exception handling in generated JSPs
[
https://issues.apache.org/jira/browse/SLING-11724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu closed SLING-11724.
> Improve exception handling in generated JSPs
>
>
> Key: SLING-11724
> URL: https://issues.apache.org/jira/browse/SLING-11724
> Project: Sling
> Issue Type: Improvement
> Components: Scripting
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting JSP 2.6.2
>
>
> The JSP engine generation of the {{_jspService(HttpServletRequest request,
> HttpServletResponse response)}} method should be improved, so that any
> possible thrown exception can be handled by the {{pageContext}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (SLING-11722) The SlingRequestDispatcher doesn't correctly implement the RequestDispatcher API
[
https://issues.apache.org/jira/browse/SLING-11722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu reopened SLING-11722:
--
> The SlingRequestDispatcher doesn't correctly implement the RequestDispatcher
> API
>
>
> Key: SLING-11722
> URL: https://issues.apache.org/jira/browse/SLING-11722
> Project: Sling
> Issue Type: Bug
> Components: Engine
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Engine 2.13.2
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> The {{include}} method [0] has the following important sentence in its
> documentation:
> {quote}
> The ServletResponse object has its path elements and parameters remain
> unchanged from the caller's. The included servlet cannot change the response
> status code or set headers; any attempt to make a change is ignored.
> {quote}
> However, the {{SlingRequestDispatcher}} [1] doesn't enforce this in any way.
> [0] -
> https://docs.oracle.com/javaee/7/api/javax/servlet/RequestDispatcher.html#include-javax.servlet.ServletRequest-javax.servlet.ServletResponse-
> [1] -
> https://github.com/apache/sling-org-apache-sling-engine/blob/bbc6acca70e7a27386f47fa9733af3740985f375/src/main/java/org/apache/sling/engine/impl/request/SlingRequestDispatcher.java#L177
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-11722) The SlingRequestDispatcher doesn't correctly implement the RequestDispatcher API
[
https://issues.apache.org/jira/browse/SLING-11722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-11722:
-
Description:
The {{include}} method [0] has the following important sentence in its
documentation:
{quote}
The ServletResponse object has its path elements and parameters remain
unchanged from the caller's. The included servlet cannot change the response
status code or set headers; any attempt to make a change is ignored.
{quote}
However, the {{SlingRequestDispatcher}} [1] doesn't enforce this in any way.
[0] -
https://docs.oracle.com/javaee/7/api/javax/servlet/RequestDispatcher.html#include-javax.servlet.ServletRequest-javax.servlet.ServletResponse-
[1] -
https://github.com/apache/sling-org-apache-sling-engine/blob/bbc6acca70e7a27386f47fa9733af3740985f375/src/main/java/org/apache/sling/engine/impl/request/SlingRequestDispatcher.java#L177
was:
The {{include}} method [0] has the following important sentence in its
documentation:
{quote}
The ServletResponse object has its path elements and parameters remain
unchanged from the caller's. The included servlet cannot change the response
status code or set headers; any attempt to make a change is ignored.
{quote}
However, the {{SlingRequestDispatcher}} [1] doesn't enforce this in any way.
[0] -
https://docs.oracle.com/javaee/7/api/javax/servlet/RequestDispatcher.html#include-javax.servlet.ServletRequest-javax.servlet.ServletResponse-
> The SlingRequestDispatcher doesn't correctly implement the RequestDispatcher
> API
>
>
> Key: SLING-11722
> URL: https://issues.apache.org/jira/browse/SLING-11722
> Project: Sling
> Issue Type: Bug
> Components: Engine
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Engine 2.13.2
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> The {{include}} method [0] has the following important sentence in its
> documentation:
> {quote}
> The ServletResponse object has its path elements and parameters remain
> unchanged from the caller's. The included servlet cannot change the response
> status code or set headers; any attempt to make a change is ignored.
> {quote}
> However, the {{SlingRequestDispatcher}} [1] doesn't enforce this in any way.
> [0] -
> https://docs.oracle.com/javaee/7/api/javax/servlet/RequestDispatcher.html#include-javax.servlet.ServletRequest-javax.servlet.ServletResponse-
> [1] -
> https://github.com/apache/sling-org-apache-sling-engine/blob/bbc6acca70e7a27386f47fa9733af3740985f375/src/main/java/org/apache/sling/engine/impl/request/SlingRequestDispatcher.java#L177
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SLING-11722) The SlingRequestDispatcher doesn't correctly implement the RequestDispatcher API
[
https://issues.apache.org/jira/browse/SLING-11722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu resolved SLING-11722.
--
Resolution: Fixed
Fixed in [commit
5d8df33|https://github.com/apache/sling-org-apache-sling-engine/commit/5d8df33].
> The SlingRequestDispatcher doesn't correctly implement the RequestDispatcher
> API
>
>
> Key: SLING-11722
> URL: https://issues.apache.org/jira/browse/SLING-11722
> Project: Sling
> Issue Type: Bug
> Components: Engine
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Engine 2.13.2
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> The {{include}} method [0] has the following important sentence in its
> documentation:
> {quote}
> The ServletResponse object has its path elements and parameters remain
> unchanged from the caller's. The included servlet cannot change the response
> status code or set headers; any attempt to make a change is ignored.
> {quote}
> However, the {{SlingRequestDispatcher}} [1] doesn't enforce this in any way.
> [0] -
> https://docs.oracle.com/javaee/7/api/javax/servlet/RequestDispatcher.html#include-javax.servlet.ServletRequest-javax.servlet.ServletResponse-
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SLING-11724) Improve exception handling in generated JSPs
[
https://issues.apache.org/jira/browse/SLING-11724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu resolved SLING-11724.
--
Resolution: Fixed
Fixed in [commit
6f14664|https://github.com/apache/sling-org-apache-sling-scripting-jsp/commit/6f14664],
similarly to
https://github.com/apache/tomcat/blob/66a4bcab40ba28b8b0ead1d360575b19fc383da7/java/org/apache/jasper/compiler/Generator.java#L3242.
> Improve exception handling in generated JSPs
>
>
> Key: SLING-11724
> URL: https://issues.apache.org/jira/browse/SLING-11724
> Project: Sling
> Issue Type: Improvement
> Components: Scripting
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting JSP 2.6.2
>
>
> The JSP engine generation of the {{_jspService(HttpServletRequest request,
> HttpServletResponse response)}} method should be improved, so that any
> possible thrown exception can be handled by the {{pageContext}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-11724) Improve exception handling in generated JSPs
[
https://issues.apache.org/jira/browse/SLING-11724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-11724:
-
Description: The JSP engine generation of the
{{_jspService(HttpServletRequest request, HttpServletResponse response)}}
method should be improved, so that any possible thrown exception can be handled
by the {{pageContext}}.
> Improve exception handling in generated JSPs
>
>
> Key: SLING-11724
> URL: https://issues.apache.org/jira/browse/SLING-11724
> Project: Sling
> Issue Type: Improvement
> Components: Scripting
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting JSP 2.6.2
>
>
> The JSP engine generation of the {{_jspService(HttpServletRequest request,
> HttpServletResponse response)}} method should be improved, so that any
> possible thrown exception can be handled by the {{pageContext}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SLING-11724) Improve exception handling in generated JSPs
Radu Cotescu created SLING-11724: Summary: Improve exception handling in generated JSPs Key: SLING-11724 URL: https://issues.apache.org/jira/browse/SLING-11724 Project: Sling Issue Type: Improvement Components: Scripting Reporter: Radu Cotescu Assignee: Radu Cotescu Fix For: Scripting JSP 2.6.2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (SLING-11722) The SlingRequestDispatcher doesn't correctly implement the RequestDispatcher API
[
https://issues.apache.org/jira/browse/SLING-11722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu reassigned SLING-11722:
Assignee: Radu Cotescu
> The SlingRequestDispatcher doesn't correctly implement the RequestDispatcher
> API
>
>
> Key: SLING-11722
> URL: https://issues.apache.org/jira/browse/SLING-11722
> Project: Sling
> Issue Type: Bug
> Components: Engine
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Engine 2.13.2
>
>
> The {{include}} method [0] has the following important sentence in its
> documentation:
> {quote}
> The ServletResponse object has its path elements and parameters remain
> unchanged from the caller's. The included servlet cannot change the response
> status code or set headers; any attempt to make a change is ignored.
> {quote}
> However, the {{SlingRequestDispatcher}} [1] doesn't enforce this in any way.
> [0] -
> https://docs.oracle.com/javaee/7/api/javax/servlet/RequestDispatcher.html#include-javax.servlet.ServletRequest-javax.servlet.ServletResponse-
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SLING-11722) The SlingRequestDispatcher doesn't correctly implement the RequestDispatcher API
Radu Cotescu created SLING-11722:
Summary: The SlingRequestDispatcher doesn't correctly implement
the RequestDispatcher API
Key: SLING-11722
URL: https://issues.apache.org/jira/browse/SLING-11722
Project: Sling
Issue Type: Bug
Components: Engine
Reporter: Radu Cotescu
Fix For: Engine 2.13.2
The {{include}} method [0] has the following important sentence in its
documentation:
{quote}
The ServletResponse object has its path elements and parameters remain
unchanged from the caller's. The included servlet cannot change the response
status code or set headers; any attempt to make a change is ignored.
{quote}
However, the {{SlingRequestDispatcher}} [1] doesn't enforce this in any way.
[0] -
https://docs.oracle.com/javaee/7/api/javax/servlet/RequestDispatcher.html#include-javax.servlet.ServletRequest-javax.servlet.ServletResponse-
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (SLING-11458) Regress - "Writer has already been closed" exception in GraphQLServlet
[
https://issues.apache.org/jira/browse/SLING-11458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17636659#comment-17636659
]
Radu Cotescu edited comment on SLING-11458 at 11/21/22 12:16 PM:
-
[~andysch], no, I didn't have the time to start a PR for the issue mentioned in
https://lists.apache.org/thread/lytsl0b23d56xkmvsvnoxm4d7skxcq5h (comment to
your original PR).
But like [~kwin] already suggested, we should not skip calling the original
{{close}} method, since it might do more than just closing the writer. Again,
we should fix the chain of calls we see in the stack trace you posted.
was (Author: radu.cotescu):
[~andysch], no, I didn't have the time to start a PR for the issue mentioned in
https://lists.apache.org/thread/lytsl0b23d56xkmvsvnoxm4d7skxcq5h (comment to
your original PR).
> Regress - "Writer has already been closed" exception in GraphQLServlet
> --
>
> Key: SLING-11458
> URL: https://issues.apache.org/jira/browse/SLING-11458
> Project: Sling
> Issue Type: Bug
> Components: GraphQL
>Affects Versions: GraphQL Core 0.0.4
>Reporter: Evgeny Tugarev
>Assignee: Andreas Schaefer
>Priority: Major
>
> The GraphQLServlet shouldn't call {{response.getWriter().flush()}} as the
> {{JsonWriter}} used by the {{JsonSerializer}} implements {{Closeable}} and as
> such [closes the
> Writer|https://github.com/jdereg/json-io/blob/cf849f15460decf10a8a320390de11965bb5996b/src/main/java/com/cedarsoftware/util/io/JsonWriter.java#L2413].
> This causes a "Writer has already been closed" Exception when {{flush()}} is
> called.
> This was fixed in commit d27f4bb7 but then this commit: 11c7e389 did undo the
> fix as now the JsonWriter is closed when existing the try-catch block.
> I will undo it and prevent the premature closure as this is causing issues
> like when the call to this servlet is made through a dispatcher.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-11458) Regress - "Writer has already been closed" exception in GraphQLServlet
[
https://issues.apache.org/jira/browse/SLING-11458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17636659#comment-17636659
]
Radu Cotescu commented on SLING-11458:
--
[~andysch], no, I didn't have the time to start a PR for the issue mentioned in
https://lists.apache.org/thread/lytsl0b23d56xkmvsvnoxm4d7skxcq5h (comment to
your original PR).
> Regress - "Writer has already been closed" exception in GraphQLServlet
> --
>
> Key: SLING-11458
> URL: https://issues.apache.org/jira/browse/SLING-11458
> Project: Sling
> Issue Type: Bug
> Components: GraphQL
>Affects Versions: GraphQL Core 0.0.4
>Reporter: Evgeny Tugarev
>Assignee: Andreas Schaefer
>Priority: Major
>
> The GraphQLServlet shouldn't call {{response.getWriter().flush()}} as the
> {{JsonWriter}} used by the {{JsonSerializer}} implements {{Closeable}} and as
> such [closes the
> Writer|https://github.com/jdereg/json-io/blob/cf849f15460decf10a8a320390de11965bb5996b/src/main/java/com/cedarsoftware/util/io/JsonWriter.java#L2413].
> This causes a "Writer has already been closed" Exception when {{flush()}} is
> called.
> This was fixed in commit d27f4bb7 but then this commit: 11c7e389 did undo the
> fix as now the JsonWriter is closed when existing the try-catch block.
> I will undo it and prevent the premature closure as this is causing issues
> like when the call to this servlet is made through a dispatcher.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SLING-11670) org.apache.sling.testing.mock.osgi.OsgiServiceUtil#getMatchingDynamicReferences doesn't inject references into Components
Radu Cotescu created SLING-11670:
Summary:
org.apache.sling.testing.mock.osgi.OsgiServiceUtil#getMatchingDynamicReferences
doesn't inject references into Components
Key: SLING-11670
URL: https://issues.apache.org/jira/browse/SLING-11670
Project: Sling
Issue Type: Bug
Components: Testing
Affects Versions: Testing OSGi Mock 3.3.2
Reporter: Radu Cotescu
When working with {{Components}} that are not registered as services the
{{org.apache.sling.testing.mock.osgi.OsgiServiceUtil#getMatchingDynamicReferences}}
method doesn't inject references into components when an optional dependency
gets installed into the framework.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-11601) [Scripting] Use the LazyBindings instead of SimpleBindings
[
https://issues.apache.org/jira/browse/SLING-11601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616910#comment-17616910
]
Radu Cotescu commented on SLING-11601:
--
[~joerghoh], none of those modules were using any suppliers anyways, so I don't
think you will achieve anything with the change, unless I'm missing something.
If the bindings that are available in the {{ScriptContext}} are of type
{{LazyBindings}} we should be fine.
> [Scripting] Use the LazyBindings instead of SimpleBindings
> --
>
> Key: SLING-11601
> URL: https://issues.apache.org/jira/browse/SLING-11601
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Affects Versions: Sling Models Impl 1.4.0
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> At various modules Sling Scripting (and Sling Models) code still uses a
> {{SimpleBindings}} implementation of the {{Bindings}}, while it could use
> {{LazyBindings}} which are more efficient in case not all provided bindings
> are required.
> Requires a bump of the dependency to Sling API though (at least 2.21.0 is
> required)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SLING-11608) Cache script dependency resolution
Radu Cotescu created SLING-11608: Summary: Cache script dependency resolution Key: SLING-11608 URL: https://issues.apache.org/jira/browse/SLING-11608 Project: Sling Issue Type: Improvement Components: Scripting Reporter: Radu Cotescu Assignee: Radu Cotescu Fix For: Scripting HTL Engine 1.4.22-1.4.0 Up to version 1.4.20-1.4.0 of the HTL Script Engine, the [ScriptUtils|https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/org.apache.sling.scripting.sightly-1.4.20-1.4.0/src/main/java/org/apache/sling/scripting/sightly/impl/utils/ScriptUtils.java] class walked the resource tree to solve the correct HTL Template/script provided by another script engine based on the resource tree. However, in situations where the script tree is stable (e.g. systems that have a read-only search path, systems that deploy script exclusively via bundled scripts, etc.), it makes sense to cache this resolution. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-11197) GraphQLServlet cache hit rate metric produces invalid json
[
https://issues.apache.org/jira/browse/SLING-11197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu closed SLING-11197.
> GraphQLServlet cache hit rate metric produces invalid json
> --
>
> Key: SLING-11197
> URL: https://issues.apache.org/jira/browse/SLING-11197
> Project: Sling
> Issue Type: Bug
> Components: GraphQL
>Affects Versions: GraphQL Core 0.0.12
>Reporter: Dirk Rudolph
>Assignee: Dirk Rudolph
>Priority: Major
> Fix For: GraphQL Core 0.0.14
>
>
> The GraphQLServlet may produce a NaN for the cache hit rate metric resulting
> in a hard to parse json.
>
> {code:java}
> "sling:org.apache.sling.graphql.core.servlet.GraphQLServlet.rt:my/rt.m:GET_POST.e:json.cache_hit_rate":
> {
> "value": NaN
> }{code}
> NaN is not an allowed value according to https://www.json.org/json-en.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SLING-11429) OSGi configs on same resource type cause IAE
[
https://issues.apache.org/jira/browse/SLING-11429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu closed SLING-11429.
> OSGi configs on same resource type cause IAE
>
>
> Key: SLING-11429
> URL: https://issues.apache.org/jira/browse/SLING-11429
> Project: Sling
> Issue Type: Improvement
> Components: GraphQL
>Affects Versions: GraphQL Core 0.0.12
>Reporter: Stefan Grimm
>Assignee: Radu Cotescu
>Priority: Minor
> Fix For: GraphQL Core 0.0.14
>
>
> Currently, if we have more than one OSGi configuration for {{GraphQLServlet}}
> registered on the same resource type, the {{activate}} method throws an
> {{InvalidArgumentException}}.
> Stacktrace is:
> {noformat}
> org.apache.sling.graphql.core.servlet.GraphQLServlet bundle
> org.apache.sling.graphql.core:0.0.12
> (528)[org.apache.sling.graphql.core.servlet.GraphQLServlet(3271)] : The
> activate method has thrown an exception (java.lang.IllegalArgumentException:
> A metric named
> org.apache.sling.graphql.core.servlet.GraphQLServlet.rt:graphql/sites/components/endpoint.m:GET_POST.e:json.cache_hit_rate
> already exists)
> java.lang.IllegalArgumentException: A metric named
> org.apache.sling.graphql.core.servlet.GraphQLServlet.rt:graphql/sites/components/endpoint.m:GET_POST.e:json.cache_hit_rate
> already exists
> at com.codahale.metrics.MetricRegistry.register(MetricRegistry.java:91)
> at
> org.apache.sling.graphql.core.servlet.GraphQLServlet.activate(GraphQLServlet.java:199)
> {noformat}
> Probably some additional data should be used on top of the resource type to
> create the name for the metric(s). If that's not possible, it would at least
> be great to handle this more gracefully (log a proper error message instead
> of throwing an {{IllegalArgumentException}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SLING-10883) Update the GraphQL implementation to use the Builder API for internal requests
[ https://issues.apache.org/jira/browse/SLING-10883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu closed SLING-10883. > Update the GraphQL implementation to use the Builder API for internal requests > -- > > Key: SLING-10883 > URL: https://issues.apache.org/jira/browse/SLING-10883 > Project: Sling > Issue Type: Improvement > Components: GraphQL >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: GraphQL Core 0.0.14 > > > Since Sling API provides a new Builder API for request objects starting with > SLING-10871, it makes sense to switch to this API rather than using the > Servlet Helpers. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-11248) Post empty body should fail gracefully
[
https://issues.apache.org/jira/browse/SLING-11248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu closed SLING-11248.
> Post empty body should fail gracefully
> --
>
> Key: SLING-11248
> URL: https://issues.apache.org/jira/browse/SLING-11248
> Project: Sling
> Issue Type: Bug
> Components: GraphQL
>Affects Versions: GraphQL Core 0.0.12
>Reporter: Thierry Ygé
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: GraphQL Core 0.0.14
>
>
> We observed following stacktrace, while this is apparently produced by some
> bot YandexBot, it seems that if an empty body is sent, it fails with 500,
> while it should gracefully fail with 400 instead.
> {noformat}
> 02.04.2022 15:43:06.848 *ERROR* [77.88.5.82 [1648914186845] POST
> /content/some_endpoint.json HTTP/1.1]
> org.apache.sling.engine.impl.SlingRequestProcessorImpl service: Uncaught
> Throwable
> at
> org.apache.sling.graphql.core.servlet.QueryParser.fromRequest(QueryParser.java:85)
> [org.apache.sling.graphql.core:0.0.12]
> at
> org.apache.sling.graphql.core.servlet.GraphQLServlet.execute(GraphQLServlet.java:304)
> [org.apache.sling.graphql.core:0.0.12]
> at
> org.apache.sling.graphql.core.servlet.GraphQLServlet.doPost(GraphQLServlet.java:273)
> [org.apache.sling.graphql.core:0.0.12]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SLING-11563) Update to Apache Sling Bundle Parent 49
[ https://issues.apache.org/jira/browse/SLING-11563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu closed SLING-11563. > Update to Apache Sling Bundle Parent 49 > --- > > Key: SLING-11563 > URL: https://issues.apache.org/jira/browse/SLING-11563 > Project: Sling > Issue Type: Improvement > Components: GraphQL >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: GraphQL Core 0.0.14 > > > Update to the latest bundle parent pom available to avoid costlier migrations > in the future. -- This message was sent by Atlassian Jira (v8.20.10#820010)
