[jira] [Updated] (SLING-12302) CA Config access syntax is inconsistent in HTL
[
https://issues.apache.org/jira/browse/SLING-12302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karol Lewandowski updated SLING-12302:
--
Description:
I have a problem understanding how nested configs can be accessed in HTL or if
there is a bug in the implementation.
The
[documentation|https://sling.apache.org/documentation/bundles/context-aware-configuration/context-aware-configuration.html#accessing-configuration-from-htlsightly-templates]
gives an example:
{{{}$\{caconfig['x.y.z.ConfigSample']['nestedConfig/stringParam']{
However, it doesn't work when a configuration annotation class is defined.
Steps to reproduce:
1. Create a config node:
{{/conf/we-retail/sling:configs/us/en/sling:configs/com.mysite.core.config.TestConfig}}
{code:xml}
http://sling.apache.org/jcr/sling/1.0";
xmlns:jcr="http://www.jcp.org/jcr/1.0";
jcr:primaryType="sling:OsgiConfig"
email="t...@example.com"
enabled="{Boolean}true"
number="{Long}123">
{code}
and reference it from some path.
2. Access in HTL without configuration annotation class:
{code}
Email: ${caconfig['com.mysite.core.config.TestConfig'].email}
Number: ${caconfig['com.mysite.core.config.TestConfig'].number}
Enabled: ${caconfig['com.mysite.core.config.TestConfig'].enabled}
Greeting (config path):
${caconfig['com.mysite.core.config.TestConfig/nested'].greeting}
Greeting (property path):
${caconfig['com.mysite.core.config.TestConfig']['nested/greeting']} {code}
This gives the output:
{code}
Email: t...@example.com
Number: 123
Enabled: true
Greeting (config path): hello
Greeting (property path): hello {code}
It works as expected.
3. Create annotation classes:
{code:java}
package com.mysite.core.config;
import org.apache.sling.caconfig.annotation.Configuration;
@Configuration
public @interface TestConfig {
String email();
int number() default 5;
boolean enabled();
NestedConfig nested();
}
{code}
and
{code:java}
package com.mysite.core.config;
public @interface NestedConfig {
String greeting();
}
{code}
The previous HTL will print:
{code}
Email: t...@example.com
Number: 123
Enabled: true
Greeting (config path): hello
Greeting (property path): {code}
Accessing nested config value with property name path doesn't work. Is it
expected?
I'm working on support for CA Configs in AEM IDE, so I don't want to make it
work in my AEM application but provide the correct syntax support.
was:
I have a problem understanding how nested configs can be accessed in HTL or if
there is a bug in the implementation.
The
[documentation|https://sling.apache.org/documentation/bundles/context-aware-configuration/context-aware-configuration.html#accessing-configuration-from-htlsightly-templates]
gives an example:
{{{}$\{caconfig['x.y.z.ConfigSample']['nestedConfig/stringParam']{
However, it doesn't work when a configuration annotation class is defined.
Steps to reproduce:
1. Create a config node:
{{/conf/we-retail/sling:configs/us/en/sling:configs/com.mysite.core.config.TestConfig}}
{code:xml}
http://sling.apache.org/jcr/sling/1.0";
xmlns:jcr="http://www.jcp.org/jcr/1.0";
jcr:primaryType="sling:OsgiConfig"
email="t...@example.com"
enabled="{Boolean}true"
number="{Long}123">
{code}
and reference it from some path.
2. Access in HTL without configuration annotation class:
{code:text}
Email: ${caconfig['com.mysite.core.config.TestConfig'].email}
Number: ${caconfig['com.mysite.core.config.TestConfig'].number}
Enabled: ${caconfig['com.mysite.core.config.TestConfig'].enabled}
Greeting (config path):
${caconfig['com.mysite.core.config.TestConfig/nested'].greeting}
Greeting (property path):
${caconfig['com.mysite.core.config.TestConfig']['nested/greeting']} {code}
This gives the output:
{code:text}
Email: t...@example.com
Number: 123
Enabled: true
Greeting (config path): hello
Greeting (property path): hello {code}
It works as expected.
3. Create annotation classes:
{code:java}
package com.mysite.core.config;
import org.apache.sling.caconfig.annotation.Configuration;
@Configuration
public @interface TestConfig {
String email();
int number() default 5;
boolean enabled();
NestedConfig nested();
}
{code}
and
{code:java}
package com.mysite.core.config;
public @interface NestedConfig {
String greeting();
}
{code}
The previous HTL will print:
{code:text}
Email: t...@example.com
Number: 123
Enabled: true
Greeting (config path): hello
Greeting (property path): {code}
Accessing nested config value with property name path doesn't work. Is it
expected?
I'm working on support for CA Configs in AEM IDE, so I don't want to make it
work in my AEM application but provide the correct syntax support.
> CA Config access syntax is inconsistent in HTL
> --
>
> Key: SLING-12302
> URL: https://issues
[jira] [Updated] (SLING-12302) CA Config access syntax is inconsistent in HTL
[
https://issues.apache.org/jira/browse/SLING-12302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karol Lewandowski updated SLING-12302:
--
Description:
I have a problem understanding how nested configs can be accessed in HTL or if
there is a bug in the implementation.
The
[documentation|https://sling.apache.org/documentation/bundles/context-aware-configuration/context-aware-configuration.html#accessing-configuration-from-htlsightly-templates]
gives an example:
{{{}$\{caconfig['x.y.z.ConfigSample']['nestedConfig/stringParam']{
However, it doesn't work when a configuration annotation class is defined.
Steps to reproduce:
1. Create a config node:
{{/conf/we-retail/sling:configs/us/en/sling:configs/com.mysite.core.config.TestConfig}}
{code:xml}
http://sling.apache.org/jcr/sling/1.0";
xmlns:jcr="http://www.jcp.org/jcr/1.0";
jcr:primaryType="sling:OsgiConfig"
email="t...@example.com"
enabled="{Boolean}true"
number="{Long}123">
{code}
and reference it from some path.
2. Access in HTL without configuration annotation class:
{code:text}
Email: ${caconfig['com.mysite.core.config.TestConfig'].email}
Number: ${caconfig['com.mysite.core.config.TestConfig'].number}
Enabled: ${caconfig['com.mysite.core.config.TestConfig'].enabled}
Greeting (config path):
${caconfig['com.mysite.core.config.TestConfig/nested'].greeting}
Greeting (property path):
${caconfig['com.mysite.core.config.TestConfig']['nested/greeting']} {code}
This gives the output:
{code:text}
Email: t...@example.com
Number: 123
Enabled: true
Greeting (config path): hello
Greeting (property path): hello {code}
It works as expected.
3. Create annotation classes:
{code:java}
package com.mysite.core.config;
import org.apache.sling.caconfig.annotation.Configuration;
@Configuration
public @interface TestConfig {
String email();
int number() default 5;
boolean enabled();
NestedConfig nested();
}
{code}
and
{code:java}
package com.mysite.core.config;
public @interface NestedConfig {
String greeting();
}
{code}
The previous HTL will print:
{code:text}
Email: t...@example.com
Number: 123
Enabled: true
Greeting (config path): hello
Greeting (property path): {code}
Accessing nested config value with property name path doesn't work. Is it
expected?
I'm working on support for CA Configs in AEM IDE, so I don't want to make it
work in my AEM application but provide the correct syntax support.
was:
I have a problem understanding how nested configs can be accessed in HTL or if
there is a bug in the implementation.
The
[documentation|https://sling.apache.org/documentation/bundles/context-aware-configuration/context-aware-configuration.html#accessing-configuration-from-htlsightly-templates]
gives an example:
{{{}$\{caconfig['x.y.z.ConfigSample']['nestedConfig/stringParam']{
However, it doesn't work when a configuration annotation class is defined.
Steps to reproduce:
1. Create a config node:
{{/conf/we-retail/sling:configs/us/en/sling:configs/com.mysite.core.config.TestConfig}}
{code:xml}
http://sling.apache.org/jcr/sling/1.0";
xmlns:jcr="http://www.jcp.org/jcr/1.0";
jcr:primaryType="sling:OsgiConfig"
email="t...@example.com"
enabled="{Boolean}true"
number="{Long}123">
{code}
and reference it from some path.
2. Access in HTL without configuration annotation class:
{code}
Email: ${caconfig['com.mysite.core.config.TestConfig'].email}
Number: ${caconfig['com.mysite.core.config.TestConfig'].number}
Enabled: ${caconfig['com.mysite.core.config.TestConfig'].enabled}
Greeting (config path):
${caconfig['com.mysite.core.config.TestConfig/nested'].greeting}
Greeting (property path):
${caconfig['com.mysite.core.config.TestConfig']['nested/greeting']} {code}
This gives the output:
{code}
Email: t...@example.com
Number: 123
Enabled: true
Greeting (config path): hello
Greeting (property path): hello {code}
It works as expected.
3. Create annotation classes:
{code:java}
package com.mysite.core.config;
import org.apache.sling.caconfig.annotation.Configuration;
@Configuration
public @interface TestConfig {
String email();
int number() default 5;
boolean enabled();
NestedConfig nested();
}
{code}
and
{code:java}
package com.mysite.core.config;
public @interface NestedConfig {
String greeting();
}
{code}
The previous HTL will print:
{code}
Email: t...@example.com
Number: 123
Enabled: true
Greeting (config path): hello
Greeting (property path): {code}
Accessing nested config value with property name path doesn't work. Is it
expected?
I'm working on support for CA Configs in AEM IDE, so I don't want to make it
work in my AEM application but provide the correct syntax support.
> CA Config access syntax is inconsistent in HTL
> --
>
> Key: SLING-12302
> URL: https://issues
[jira] [Updated] (SLING-12302) CA Config access syntax is inconsistent in HTL
[
https://issues.apache.org/jira/browse/SLING-12302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karol Lewandowski updated SLING-12302:
--
Description:
I have a problem understanding how nested configs can be accessed in HTL or if
there is a bug in the implementation.
The
[documentation|https://sling.apache.org/documentation/bundles/context-aware-configuration/context-aware-configuration.html#accessing-configuration-from-htlsightly-templates]
gives an example:
{{{}$\{caconfig['x.y.z.ConfigSample']['nestedConfig/stringParam']{
However, it doesn't work when a configuration annotation class is defined.
Steps to reproduce:
1. Create a config node:
{{/conf/we-retail/sling:configs/us/en/sling:configs/com.mysite.core.config.TestConfig}}
{code:xml}
http://sling.apache.org/jcr/sling/1.0";
xmlns:jcr="http://www.jcp.org/jcr/1.0";
jcr:primaryType="sling:OsgiConfig"
email="t...@example.com"
enabled="{Boolean}true"
number="{Long}123">
{code}
and reference it from some path.
2. Access in HTL without configuration annotation class:
{code}
Email: ${caconfig['com.mysite.core.config.TestConfig'].email}
Number: ${caconfig['com.mysite.core.config.TestConfig'].number}
Enabled: ${caconfig['com.mysite.core.config.TestConfig'].enabled}
Greeting (config path):
${caconfig['com.mysite.core.config.TestConfig/nested'].greeting}
Greeting (property path):
${caconfig['com.mysite.core.config.TestConfig']['nested/greeting']} {code}
This gives the output:
{code}
Email: t...@example.com
Number: 123
Enabled: true
Greeting (config path): hello
Greeting (property path): hello {code}
It works as expected.
3. Create annotation classes:
{code:java}
package com.mysite.core.config;
import org.apache.sling.caconfig.annotation.Configuration;
@Configuration
public @interface TestConfig {
String email();
int number() default 5;
boolean enabled();
NestedConfig nested();
}
{code}
and
{code:java}
package com.mysite.core.config;
public @interface NestedConfig {
String greeting();
}
{code}
The previous HTL will print:
{code}
Email: t...@example.com
Number: 123
Enabled: true
Greeting (config path): hello
Greeting (property path): {code}
Accessing nested config value with property name path doesn't work. Is it
expected?
I'm working on support for CA Configs in AEM IDE, so I don't want to make it
work in my AEM application but provide the correct syntax support.
was:
I have a problem understanding how nested configs can be accessed in HTL or if
there is a bug in the implementation.
The
[documentation|https://sling.apache.org/documentation/bundles/context-aware-configuration/context-aware-configuration.html#accessing-configuration-from-htlsightly-templates]
gives an example:
{{{}$\{caconfig['x.y.z.ConfigSample']['nestedConfig/stringParam']{
However, it doesn't work when a configuration annotation class is defined.
Steps to reproduce:
1. Create a config node:
{{/conf/we-retail/sling:configs/us/en/sling:configs/com.mysite.core.config.TestConfig}}
{code:xml}
http://sling.apache.org/jcr/sling/1.0";
xmlns:jcr="http://www.jcp.org/jcr/1.0";
jcr:primaryType="sling:OsgiConfig"
email="t...@example.com"
enabled="{Boolean}true"
number="{Long}123">
{code}
and reference it from some path.
2. Access in HTL without configuration annotation class:
{code:java}
Email: ${caconfig['com.mysite.core.config.TestConfig'].email}
Number: ${caconfig['com.mysite.core.config.TestConfig'].number}
Enabled: ${caconfig['com.mysite.core.config.TestConfig'].enabled}
Greeting (config path):
${caconfig['com.mysite.core.config.TestConfig/nested'].greeting}
Greeting (property path):
${caconfig['com.mysite.core.config.TestConfig']['nested/greeting']} {code}
This gives the output:
{code:java}
Email: t...@example.com
Number: 123
Enabled: true
Greeting (config path): hello
Greeting (property path): hello {code}
It works as expected.
3. Create annotation classes:
{code:java}
package com.mysite.core.config;
import org.apache.sling.caconfig.annotation.Configuration;
@Configuration
public @interface TestConfig {
String email();
int number() default 5;
boolean enabled();
NestedConfig nested();
}
{code}
and
{code:java}
package com.mysite.core.config;
public @interface NestedConfig {
String greeting();
}
{code}
The previous HTL will print:
{code:java}
Email: t...@example.com
Number: 123
Enabled: true
Greeting (config path): hello
Greeting (property path): {code}
Accessing nested config value with property name path doesn't work. Is it
expected?
I'm working on support for CA Configs in AEM IDE, so I don't want to make it
work in my AEM application but provide the correct syntax support.
> CA Config access syntax is inconsistent in HTL
> --
>
> Key: SLING-12302
> URL: https://issues
[jira] [Created] (SLING-12302) CA Config access syntax is inconsistent in HTL
Karol Lewandowski created SLING-12302:
-
Summary: CA Config access syntax is inconsistent in HTL
Key: SLING-12302
URL: https://issues.apache.org/jira/browse/SLING-12302
Project: Sling
Issue Type: Bug
Reporter: Karol Lewandowski
I have a problem understanding how nested configs can be accessed in HTL or if
there is a bug in the implementation.
The
[documentation|https://sling.apache.org/documentation/bundles/context-aware-configuration/context-aware-configuration.html#accessing-configuration-from-htlsightly-templates]
gives an example:
{{{}$\{caconfig['x.y.z.ConfigSample']['nestedConfig/stringParam']{
However, it doesn't work when a configuration annotation class is defined.
Steps to reproduce:
1. Create a config node:
{{/conf/we-retail/sling:configs/us/en/sling:configs/com.mysite.core.config.TestConfig}}
{code:xml}
http://sling.apache.org/jcr/sling/1.0";
xmlns:jcr="http://www.jcp.org/jcr/1.0";
jcr:primaryType="sling:OsgiConfig"
email="t...@example.com"
enabled="{Boolean}true"
number="{Long}123">
{code}
and reference it from some path.
2. Access in HTL without configuration annotation class:
{code:java}
Email: ${caconfig['com.mysite.core.config.TestConfig'].email}
Number: ${caconfig['com.mysite.core.config.TestConfig'].number}
Enabled: ${caconfig['com.mysite.core.config.TestConfig'].enabled}
Greeting (config path):
${caconfig['com.mysite.core.config.TestConfig/nested'].greeting}
Greeting (property path):
${caconfig['com.mysite.core.config.TestConfig']['nested/greeting']} {code}
This gives the output:
{code:java}
Email: t...@example.com
Number: 123
Enabled: true
Greeting (config path): hello
Greeting (property path): hello {code}
It works as expected.
3. Create annotation classes:
{code:java}
package com.mysite.core.config;
import org.apache.sling.caconfig.annotation.Configuration;
@Configuration
public @interface TestConfig {
String email();
int number() default 5;
boolean enabled();
NestedConfig nested();
}
{code}
and
{code:java}
package com.mysite.core.config;
public @interface NestedConfig {
String greeting();
}
{code}
The previous HTL will print:
{code:java}
Email: t...@example.com
Number: 123
Enabled: true
Greeting (config path): hello
Greeting (property path): {code}
Accessing nested config value with property name path doesn't work. Is it
expected?
I'm working on support for CA Configs in AEM IDE, so I don't want to make it
work in my AEM application but provide the correct syntax support.
--
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&focusedCommentId=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&focusedCommentId=17840127#comment-17840127
]
Paul Bjorkstrand commented on SLING-12300:
--
That's a good analysis, [~radu], thanks for sharing. I understand the Resource
API challenges. It makes sense to keep this as a JCR concept. I feel we can
drop that idea from contention given its significant constraints.
Regarding the other two, maybe there is a way to be able to have the best of
both worlds, by making the new {{/jcr:id/}} path available, but behind a
configuration flag ({{false}} by default). I think that would allow you to keep
the simpler implementation, but also addresses any security/exposure related
issues, since it would be an opt-in feature.
Thoughts?
> 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)
[Jenkins] Sling » Modules » sling-org-apache-sling-starter » master #1349 is BROKEN
Please see
https://ci-builds.apache.org/job/Sling/job/modules/job/sling-org-apache-sling-starter/job/master/1349/
for details.
No further emails will be sent until the status of the build is changed.
Build log follows below:
[...truncated 44 lines...]
> git fetch --no-tags --force --progress --
> https://github.com/apache/sling-org-apache-sling-starter.git
> +refs/heads/master:refs/remotes/origin/master # timeout=10
Commit message: "chore(deps): update dependency
com.composum.nodes:composum-nodes-commons to v4.3.2 (#321)"
> git config core.sparsecheckout # timeout=10
> git checkout -f f0efc52cd501a906c1e0e398359bf5f62abe64ef # timeout=10
> git rev-list --no-walk f0efc52cd501a906c1e0e398359bf5f62abe64ef # timeout=10
Cleaning workspace
> git rev-parse --verify HEAD # timeout=10
Resetting working tree
> git reset --hard # timeout=10
> git clean -fdx # timeout=10
[Pipeline] isUnix
[Pipeline] sh
+ git clean -fdx
[Pipeline] sh
+ git config remote.origin.url
[Pipeline] fileExists
[Pipeline] readJSON
[Pipeline] echo
Jenkins overrides: [emailRecipients:[dev@sling.apache.org],
sonarQubeEnabled:false, jdks:[11, 17, 21], operatingSystems:[linux],
rebuildFrequency:@daily, additionalMavenParams:-Dit.startTimeoutSeconds=120,
archivePatterns:[**/logs/*.log]]
[Pipeline] echo
Final job config: [jdks:[11, 17, 21], operatingSystems:[linux],
upstreamProjects:[], archivePatterns:[**/logs/*.log], mavenGoal:,
additionalMavenParams:-Dit.startTimeoutSeconds=120, rebuildFrequency:@daily,
enabled:true, emailRecipients:[dev@sling.apache.org], sonarQubeEnabled:false,
sonarQubeUseAdditionalMavenParams:true, sonarQubeAdditionalParams:,
repoName:sling-org-apache-sling-starter]
[Pipeline] readMavenPom
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // timeout
[Pipeline] }
[Pipeline] // node
[Pipeline] node
Running on builds23 in /home/jenkins/workspace/_org-apache-sling-starter_master
[Pipeline] {
[Pipeline] timeout
Timeout set to expire after 30 min without activity
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Configure Job)
[Pipeline] properties
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // timeout
[Pipeline] }
[Pipeline] // node
[Pipeline] echo
Using operating-system linux specific node label ubuntu
[Pipeline] echo
Using operating-system linux specific node label ubuntu
[Pipeline] echo
Using operating-system linux specific node label ubuntu
[Pipeline] node
Running on builds23 in /home/jenkins/workspace/_org-apache-sling-starter_master
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Sanity Check)
[Pipeline] checkout
The recommended git tool is: NONE
using credential sling-github-token
Fetching changes from the remote Git repository
Fetching without tags
> git rev-parse --resolve-git-dir
> /home/jenkins/workspace/_org-apache-sling-starter_master/.git # timeout=10
> git config remote.origin.url
> https://github.com/apache/sling-org-apache-sling-starter.git # timeout=10
Fetching upstream changes from
https://github.com/apache/sling-org-apache-sling-starter.git
> git --version # timeout=10
> git --version # 'git version 2.34.1'
using GIT_ASKPASS to set credentials Personal access token for Github
repository access. Use with Apache Sling jobs only.
> git fetch --no-tags --force --progress --
> https://github.com/apache/sling-org-apache-sling-starter.git
> +refs/heads/master:refs/remotes/origin/master # timeout=10
Checking out Revision f0efc52cd501a906c1e0e398359bf5f62abe64ef (master)
Commit message: "chore(deps): update dependency
com.composum.nodes:composum-nodes-commons to v4.3.2 (#321)"
> git config core.sparsecheckout # timeout=10
> git checkout -f f0efc52cd501a906c1e0e398359bf5f62abe64ef # timeout=10
Cleaning workspace
> git rev-parse --verify HEAD # timeout=10
Resetting working tree
> git reset --hard # timeout=10
> git clean -fdx # timeout=10
GitHub has been notified of this commit’s build result
[Pipeline] withMaven
[withMaven] WARNING: You are running an old version of Maven (UNKNOWN), you
should update to at least 3.8.x
[Pipeline] {
[Pipeline] isUnix
[Pipeline] sh
+ mvn -U -B -e clean compile -Dit.startTimeoutSeconds=120
Picked up JAVA_TOOL_OPTIONS:
-Dmaven.ext.class.path="/home/jenkins/workspace/_org-apache-sling-starter_master@tmp/withMaven7c715363/pipeline-maven-spy.jar"
-Dorg.jenkinsci.plugins.pipeline.maven.reportsFolder="/home/jenkins/workspace/_org-apache-sling-starter_master@tmp/withMaven7c715363"
[INFO] [jenkins-event-spy] Generate
/home/jenkins/workspace/_org-apache-sling-starter_master@tmp/withMaven7c715363/maven-spy-20240423-111728-86314597227216056361793.log.tmp
...
[INFO] Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO]
[INFO] -< org.apache.sling:org.apache.sling.starter >--
[INFO] Building Apache Sling Starter 13-SNAPSHOT
[INFO] from pom.xml
[INFO] ---
[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&focusedCommentId=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)
