[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] [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=17839155#comment-17839155
]
Eric Norman edited comment on SLING-12300 at 4/19/24 11:40 PM:
---
[~radu] I know how long a UUID value is, how it is formatted and what
characters are allowed in there. That is a much smaller universe then all the
possible paths that may exist.
I still haven't seen a good reason why this is needed.
was (Author: enorman):
[~radu] I know how long a UUID value is, how it is formatted and what
characters are allowed in there. That is a much smaller universe then all the
possible paths that may exist.
I still having seen a good reason why this is needed.
> 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=17839155#comment-17839155
]
Eric Norman commented on SLING-12300:
-
[~radu] I know how long a UUID value is, how it is formatted and what
characters are allowed in there. That is a much smaller universe then all the
possible paths that may exist.
I still having seen a good reason why this is needed.
> 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=17839145#comment-17839145
]
Eric Norman commented on SLING-12300:
-
[~radu] the size of the number is irrelevant. 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. The resource path is the only address I
need.
I'm not sure this solution is necessary for general usage and you can make a
private implementation for your use case if you really need it.
> 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=17839135#comment-17839135
]
Eric Norman commented on SLING-12300:
-
I think I would prefer that the uuid not be addressable so easily. 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.
> 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] [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=17839116#comment-17839116
]
Paul Bjorkstrand commented on SLING-12300:
--
I'm leaning towards [~joerghoh]'s opinion as well. To me, this seems better
served by a new method like {{ResourceResolver#getResoureById(String jcrId);}}
Having this functionality in {{getResource(..)}} method seems to be a possible
source for confusion.
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. That may also bring into it more problems, because I don't know if
it is semantically correct for a resource provider under a given path to
provide resources for another path.
Is there a reason why this can't be a new method?
> 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=17839067#comment-17839067
]
Joerg Hoh edited comment on SLING-12300 at 4/19/24 5:30 PM:
I am not that happy with this magic string:
* It does not feel sling-ish (I would expect a ResourceProvider for it)
* I don't know if the implementation fulfills this requirement or not:
{noformat}
String jcrIdPath="/jcr:id/12345678";
Resoure r = resourceResolver.getResource(jcrIdPath);
assertEquals(jcrIdPath,r.getPath());
assertEquals(r.getPath(),r.adaptTo(Node.class).getPath());
{noformat}
(in other words: What's the path of such a retrieved resource?)
* is it possible to do a request to [http://localhost:8080/jcr:id/].html
and get the result rendered? Do we want this to happen?
* Right now it's not possible to turn off this behavior.
was (Author: joerghoh):
I am not that happy with this magic string:
* It does not feel sling-ish (I would expect a ResourceProvider for it)
* I don't know if the implementation fulfills this requirement or not:
{noformat}
String jcrIdPath="/jcr:id/12345678";
Resoure r = resourceResolver.getResource(jcrIdPath);
assertEquals(fullPath,r.getPath());
assertEquals(r.getPath(),r.adaptTo(Node.class).getPath());
{noformat}
(in other words: What's the path of such a retrieved resource?)
* is it possible to do a request to [http://localhost:8080/jcr:id/].html
and get the result rendered? Do we want this to happen?
* Right now it's not possible to turn off this behavior.
> 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=17839067#comment-17839067
]
Joerg Hoh edited comment on SLING-12300 at 4/19/24 5:29 PM:
I am not that happy with this magic string:
* It does not feel sling-ish (I would expect a ResourceProvider for it)
* I don't know if the implementation fulfills this requirement or not:
{noformat}
String jcrIdPath="/jcr:id/12345678";
Resoure r = resourceResolver.getResource(jcrIdPath);
assertEquals(fullPath,r.getPath());
assertEquals(r.getPath(),r.adaptTo(Node.class).getPath());
{noformat}
(in other words: What's the path of such a retrieved resource?)
* is it possible to do a request to [http://localhost:8080/jcr:id/].html
and get the result rendered? Do we want this to happen?
* Right now it's not possible to turn off this behavior.
was (Author: joerghoh):
I am not that happy with this magic string:
* It does not feel sling-ish (I would expect a ResourceProvider for it)
* I don't know if the implementation fulfills this requirement or not:
{noformat}
String jcrIdPath="/jcr:id/12345678";
Resoure r = resourceResolver.getResource(jcrIdPath);
assertEquals(fullPath,r.getPath());
{noformat}
(in other words: What's the path of such a retrieved resource?)
* is it possible to do a request to [http://localhost:8080/jcr:id/].html
and get the result rendered? Do we want this to happen?
* Right now it's not possible to turn off this behavior.
> 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=17839067#comment-17839067
]
Joerg Hoh edited comment on SLING-12300 at 4/19/24 5:28 PM:
I am not that happy with this magic string:
* It does not feel sling-ish (I would expect a ResourceProvider for it)
* I don't know if the implementation fulfills this requirement or not:
{noformat}
String jcrIdPath="/jcr:id/12345678";
Resoure r = resourceResolver.getResource(jcrIdPath);
assertEquals(fullPath,r.getPath());
{noformat}
(in other words: What's the path of such a retrieved resource?)
* is it possible to do a request to [http://localhost:8080/jcr:id/].html
and get the result rendered? Do we want this to happen?
* Right now it's not possible to turn off this behavior.
was (Author: joerghoh):
I am not that happy with this magic string:
* It does not feel sling-ish (I would expect a ResourceProvider for it)
* It might break code, which relies on
{noformat}
String jcrIdPath="/jcr:id/12345678";
Resoure r = resourceResolver.getResource(jcrIdPath);
assertEquals(fullPath,r.getPath());
{noformat}
(although such code might break in other cases already today, when using
aliases and vanity paths)
* is it possible to do a request to [http://localhost:8080/jcr:id/].html
and get the result rendered? Do we want this to happen?
* Right now it's not possible to turn off this behavior.
> 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=17839067#comment-17839067
]
Joerg Hoh commented on SLING-12300:
---
I am not that happy with this magic string:
* It does not feel sling-ish (I would expect a ResourceProvider for it)
* I might break code, which relies on
{noformat}
String jcrIdPath="/jcr:id/12345678";
Resoure r = resourceResolver.getResource(jcrIdPath);
assertEquals(fullPath,r.getPath());
{noformat}
(although such code might break in other cases already today, when using
aliases and vanity paths)
* is it possible to do a request to http://localhost:8080/jcr:id/.html and
get the result rendered? Do we want this to happen?
* Right now it's not possible to turn off this behavior.
> 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=17839067#comment-17839067
]
Joerg Hoh edited comment on SLING-12300 at 4/19/24 5:25 PM:
I am not that happy with this magic string:
* It does not feel sling-ish (I would expect a ResourceProvider for it)
* It might break code, which relies on
{noformat}
String jcrIdPath="/jcr:id/12345678";
Resoure r = resourceResolver.getResource(jcrIdPath);
assertEquals(fullPath,r.getPath());
{noformat}
(although such code might break in other cases already today, when using
aliases and vanity paths)
* is it possible to do a request to [http://localhost:8080/jcr:id/].html
and get the result rendered? Do we want this to happen?
* Right now it's not possible to turn off this behavior.
was (Author: joerghoh):
I am not that happy with this magic string:
* It does not feel sling-ish (I would expect a ResourceProvider for it)
* I might break code, which relies on
{noformat}
String jcrIdPath="/jcr:id/12345678";
Resoure r = resourceResolver.getResource(jcrIdPath);
assertEquals(fullPath,r.getPath());
{noformat}
(although such code might break in other cases already today, when using
aliases and vanity paths)
* is it possible to do a request to http://localhost:8080/jcr:id/.html and
get the result rendered? Do we want this to happen?
* Right now it's not possible to turn off this behavior.
> 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)
Re: [PR] SLING-12300 - Provide a way to retrieve a JCR backed resource by its node identifier [sling-org-apache-sling-jcr-resource]
sonarcloud[bot] commented on PR #42: URL: https://github.com/apache/sling-org-apache-sling-jcr-resource/pull/42#issuecomment-2066875341 ## [](https://sonarcloud.io/dashboard?id=apache_sling-org-apache-sling-jcr-resource=42) **Quality Gate passed** Issues  [0 New issues](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-jcr-resource=42=false=true)  [0 Accepted issues](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-jcr-resource=42=new_accepted_issues=list) Measures  [0 Security Hotspots](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-jcr-resource=42=false=true)  [100.0% Coverage on New Code](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-jcr-resource=42=new_coverage=list)  [0.0% Duplication on New Code](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-jcr-resource=42=new_duplicated_lines_density=list) [See analysis details on SonarCloud](https://sonarcloud.io/dashboard?id=apache_sling-org-apache-sling-jcr-resource=42) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] SLING-12300 - Provide a way to retrieve a JCR backed resource by its node identifier [sling-org-apache-sling-jcr-resource]
raducotescu opened a new pull request, #42: URL: https://github.com/apache/sling-org-apache-sling-jcr-resource/pull/42 * added support for a /jcr:id/ prefix to the JcrItemResourceFactory when retrieving items by path * made sure to return the JCR path no matter which retrieval mode was performed -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Update to latest parent 38, implement healthcheck [sling-org-apache-sling-jcr-resource]
cziegeler commented on PR #7: URL: https://github.com/apache/sling-org-apache-sling-jcr-resource/pull/7#issuecomment-2066866309 Outdated PR, closing -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[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)
Re: [PR] Update to latest parent 38, implement healthcheck [sling-org-apache-sling-jcr-resource]
cziegeler closed pull request #7: Update to latest parent 38, implement healthcheck URL: https://github.com/apache/sling-org-apache-sling-jcr-resource/pull/7 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
Radu Cotescu created SLING-12300:
Summary: Provide a way to retrieve a JCR backed resource by its
node identifier
Key: SLING-12300
URL: https://issues.apache.org/jira/browse/SLING-12300
Project: Sling
Issue Type: New Feature
Components: JCR
Reporter: Radu Cotescu
Assignee: Radu Cotescu
Fix For: JCR Resource 3.3.0
Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would be
{{Resource}} retrieval by node id, which could be its {{jcr:uuid}} property for
referenceable nodes or the path. In systems that would like to use UUID
addressing, this would reduce the need for executing JCR queries for resource
retrieval and would avoid double-reads via the JCR and then Sling API to obtain
the resource.
[0] -
https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier()
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] chore(deps): update dependency com.composum.nodes:composum-nodes-commons to v4.3.2 [sling-org-apache-sling-starter]
rombert merged PR #321: URL: https://github.com/apache/sling-org-apache-sling-starter/pull/321 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [VOTE] Release Apache Sling Testing Sling Mock Oak 3.2.0-1.22.15
On Wed, 2024-04-17 at 18:32 +, Stefan Seifert wrote: > Please vote to approve this release: +1 Robert signature.asc Description: This is a digitally signed message part
Re: [VOTE] Release Apache Sling Testing Sling Mock 3.5.0, Sling Mock Oak 4.0.0-1.62.0
On Wed, 2024-04-17 at 18:32 +, Stefan Seifert wrote: > Please vote to approve this release: +1 Robert signature.asc Description: This is a digitally signed message part
[jira] [Closed] (SLING-12290) Update tenant module to use parent pom 52
[ https://issues.apache.org/jira/browse/SLING-12290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu closed SLING-12290. --- > Update tenant module to use parent pom 52 > - > > Key: SLING-12290 > URL: https://issues.apache.org/jira/browse/SLING-12290 > Project: Sling > Issue Type: Task > Components: Extensions >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > Fix For: Tenant 1.1.8 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12285) adding bind & unbind methods mapping in reference annotation
[ https://issues.apache.org/jira/browse/SLING-12285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu closed SLING-12285. --- > adding bind & unbind methods mapping in reference annotation > > > Key: SLING-12285 > URL: https://issues.apache.org/jira/browse/SLING-12285 > Project: Sling > Issue Type: Bug > Components: Extensions >Reporter: Gagan Malpani >Assignee: Gagan Malpani >Priority: Major > Fix For: Tenant 1.1.8 > > > adding bind & unbind methods mapping in reference annotation for > tenantproviderimpl -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12286) Tenant build fails with Java 17 or newer
[ https://issues.apache.org/jira/browse/SLING-12286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu closed SLING-12286. --- > Tenant build fails with Java 17 or newer > > > Key: SLING-12286 > URL: https://issues.apache.org/jira/browse/SLING-12286 > Project: Sling > Issue Type: Bug > Components: Extensions >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > Fix For: Tenant 1.1.8 > > > [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.038 > s <<< FAILURE! - in org.apache.sling.tenant.internal.TenantProviderImplTest > [ERROR] > org.apache.sling.tenant.internal.TenantProviderImplTest.testListTenantsWithoutTenantRoot > Time elapsed: 0.036 s <<< ERROR! > java.lang.ExceptionInInitializerError > at > org.mockito.cglib.core.KeyFactory$Generator.generateClass(KeyFactory.java:167) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[RESULT] [VOTE] Release Apache Sling Tenant 1.1.8
Hi, The vote has passed with the following result: +1 (binding): Stefan Seifert, Robert Munteanu, Joerg Hoh, Radu Cotescu +1 (non-binding): none I will copy this release to the Sling dist directory and promote the artifacts to the central Maven repository. Regards, Robert Munteanu
Re: [VOTE] Release Apache Sling Rewriter 1.4.0
On Thu, 2024-04-18 at 18:36 +0200, Carsten Ziegeler wrote: > Please vote to approve this release: +1 Robert signature.asc Description: This is a digitally signed message part
Re: [PR] chore(deps): update dependency org.apache.commons:commons-text to v1.12.0 [sling-org-apache-sling-starter]
rombert merged PR #322: URL: https://github.com/apache/sling-org-apache-sling-starter/pull/322 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] chore(deps): update dependency org.apache.commons:commons-text to v1.12.0 [sling-org-apache-sling-starter]
renovate-bot opened a new pull request, #322: URL: https://github.com/apache/sling-org-apache-sling-starter/pull/322 [](https://renovatebot.com) This PR contains the following updates: | Package | Change | Age | Adoption | Passing | Confidence | |---|---|---|---|---|---| | [org.apache.commons:commons-text](https://commons.apache.org/proper/commons-text) ([source](https://gitbox.apache.org/repos/asf?p=commons-text.git)) | `1.11.0` -> `1.12.0` | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | --- ### Configuration **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate](https://www.mend.io/free-developer-tools/renovate/). View repository job log [here](https://developer.mend.io/github/apache/sling-org-apache-sling-starter). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] chore(deps): update dependency com.composum.nodes:composum-nodes-commons to v4.3.2 [sling-org-apache-sling-starter]
renovate-bot opened a new pull request, #321: URL: https://github.com/apache/sling-org-apache-sling-starter/pull/321 [](https://renovatebot.com) This PR contains the following updates: | Package | Change | Age | Adoption | Passing | Confidence | |---|---|---|---|---|---| | [com.composum.nodes:composum-nodes-commons](https://togithub.com/ist-dresden/composum) | `4.3.1` -> `4.3.2` | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | --- ### Release Notes ist-dresden/composum (com.composum.nodes:composum-nodes-commons) ### [`v4.3.2`](https://togithub.com/ist-dresden/composum/compare/composum-nodes-4.3.1...composum-nodes-4.3.2) [Compare Source](https://togithub.com/ist-dresden/composum/compare/composum-nodes-4.3.1...composum-nodes-4.3.2) --- ### Configuration **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate](https://www.mend.io/free-developer-tools/renovate/). View repository job log [here](https://developer.mend.io/github/apache/sling-org-apache-sling-starter). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] SLING-12297 log a warning in case no servlet was found [sling-org-apache-sling-engine]
joerghoh commented on code in PR #41:
URL:
https://github.com/apache/sling-org-apache-sling-engine/pull/41#discussion_r1572210729
##
src/main/java/org/apache/sling/engine/impl/request/RequestData.java:
##
@@ -517,6 +518,11 @@ public static void service(SlingHttpServletRequest request,
Servlet servlet = requestData.getContentData().getServlet();
if (servlet == null) {
+log.warn("Did not find a servlet to handle the request
(path=%s,selectors=%,extension=%s,suffix=%s)",
Review Comment:
I don't expect that this code path is taken very frequently, as it's in a
error path, which results in a 404.
But are so right about (1)
Fix in #42
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[PR] SLING-12297 fix logging parameters [sling-org-apache-sling-engine]
joerghoh opened a new pull request, #42: URL: https://github.com/apache/sling-org-apache-sling-engine/pull/42 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] SLING-12297 log a warning in case no servlet was found [sling-org-apache-sling-engine]
joerghoh commented on code in PR #41:
URL:
https://github.com/apache/sling-org-apache-sling-engine/pull/41#discussion_r1572210729
##
src/main/java/org/apache/sling/engine/impl/request/RequestData.java:
##
@@ -517,6 +518,11 @@ public static void service(SlingHttpServletRequest request,
Servlet servlet = requestData.getContentData().getServlet();
if (servlet == null) {
+log.warn("Did not find a servlet to handle the request
(path=%s,selectors=%,extension=%s,suffix=%s)",
Review Comment:
I don't expect that this code path is taken very frequently, as it's in a
error path, which results in a 404.
But are so right about (1)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [VOTE] Release Apache Sling Rewriter 1.4.0
+1 On Thu, 18 Apr 2024 at 18:36, Carsten Ziegeler wrote: > > Please vote to approve this release: > >[ ] +1 Approve the release >[ ] 0 Don't care >[ ] -1 Don't release, because ... >
Re: [VOTE] Release Apache Sling Testing Sling Mock Oak 3.2.0-1.22.15
+1 On Wed, 17 Apr 2024 at 20:32, Stefan Seifert wrote: > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... >
Re: [VOTE] Release Apache Sling Testing Sling Mock 3.5.0, Sling Mock Oak 4.0.0-1.62.0
+1 On Wed, 17 Apr 2024 at 20:32, Stefan Seifert wrote: > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... >
Re: [VOTE] Release Apache Sling Tenant 1.1.8
+1 On Thu, 11 Apr 2024 at 15:35, Robert Munteanu wrote: > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... >
Re: [VOTE] Release Apache Sling JUnit Tests Teleporter 1.0.26
+1 On Wed, 17 Apr 2024 at 12:03, Robert Munteanu wrote: > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... >
[CANCELLED] [Vote] Release Apache Sling Engine 2.15.12
The fix SLING-12297 does not work as intended, will therefor cancel the release. Thanks Paul Bjorkstrand for spotting it. Jörg Am Do., 18. Apr. 2024 um 10:14 Uhr schrieb Jörg Hoh : > Hi, > > We solved 1 issue in this > release:https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310710=12354582=Text > > Staging > repository:https://repository.apache.org/content/repositories/orgapachesling-2850/ > > You can use this UNIX script to download the release and verify the > signatures:https://raw.githubusercontent.com/apache/sling-tooling-release/master/check_staged_release.sh > Usage: > sh check_staged_release.sh 2850 /tmp/sling-staging > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > > This majority vote is open for at least 72 hours. > > Jörg > > -- > https://cqdump.joerghoh.de > > -- https://cqdump.joerghoh.de
[jira] [Updated] (SLING-12297) Logging in case no servlet can be resolved
[ https://issues.apache.org/jira/browse/SLING-12297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Hoh updated SLING-12297: -- Fix Version/s: Engine 2.15.14 (was: Engine 2.15.12) > Logging in case no servlet can be resolved > -- > > Key: SLING-12297 > URL: https://issues.apache.org/jira/browse/SLING-12297 > Project: Sling > Issue Type: Task >Affects Versions: Engine 2.15.10 >Reporter: Joerg Hoh >Assignee: Joerg Hoh >Priority: Major > Fix For: Engine 2.15.14 > > > Right now the SlingEngine just returns a 404, if the no servlet was found to > render the resource. It should also log a WARN message indicating that this > happened. -- This message was sent by Atlassian Jira (v8.20.10#820010)
RE: [VOTE] Release Apache Sling Rewriter 1.4.0
+1 stefan
Re: [Vote] Release Apache Sling Engine 2.15.12
HI Paul, you are absolutely right. I will cancel this release, fix the issue and restart the release process. Thanks, Jörg Am Do., 18. Apr. 2024 um 15:11 Uhr schrieb Paul Bjorkstrand < paul.bjorkstr...@gmail.com>: > -1 (non-binding) > > I have a concern with one change that was merged recently. I added a > comment, but it was already merged by the time I read through it. I think a > recent log addition [1] is incorrect. I think this logging addition will > not log what is desired. > > [1]: > > https://github.com/apache/sling-org-apache-sling-engine/pull/41/files#diff-6457a924a51a1c233c4c4c45de49a05b0e438032ac111c0c1644c6dcd546ab9bR521 > > // Paul > > > On Thu, Apr 18, 2024 at 6:08 AM Stefan Seifert > wrote: > > > +1 > > > > stefan > > > -- https://cqdump.joerghoh.de
