Re: [PR] SLING-11906 Migrate to slf4j 2.x [sling-org-apache-sling-commons-log]
sonarcloud[bot] commented on PR #18: URL: https://github.com/apache/sling-org-apache-sling-commons-log/pull/18#issuecomment-2076055412 ## [](https://sonarcloud.io/dashboard?id=apache_sling-org-apache-sling-commons-log=18) **Quality Gate passed** Issues  [15 New issues](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-commons-log=18=false=true)  [0 Accepted issues](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-commons-log=18=new_accepted_issues=list) Measures  [0 Security Hotspots](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-commons-log=18=false=true)  [100.0% Coverage on New Code](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-commons-log=18=new_coverage=list)  [0.0% Duplication on New Code](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-commons-log=18=new_duplicated_lines_density=list) [See analysis details on SonarCloud](https://sonarcloud.io/dashboard?id=apache_sling-org-apache-sling-commons-log=18) -- 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] [Commented] (SLING-12173) Configuration errors in Eclipse for projects using the slingfeature-maven-plugin
[
https://issues.apache.org/jira/browse/SLING-12173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840540#comment-17840540
]
Robert Munteanu commented on SLING-12173:
-
[~cziegeler] - that was my attempt to try out and see if the older plug-in
version has the same problem. It does have it, so both the jakarta.json and
javax.json implementations are problematic - in Eclipse, for me.
I suspect this is a classloader interaction between
- Maven/Plexus
- the OSGi runtime from Eclipse (Equinox)
- the ServiceLoader framework
- m2e
I _could_ try and chase this down across these projects but it seems like a lot
of work. Instead, I am experimenting with using our commons.johnzon dependency
instead the official JSON artifacts, and for now it seems to work fine.
IIUC this would avoid any such classloading issues, and hopefully will not
bring any problems with Maven executions. I'll try to run some tests over the
coming days, but wanted to check what you think of this approach.
> Configuration errors in Eclipse for projects using the
> slingfeature-maven-plugin
>
>
> Key: SLING-12173
> URL: https://issues.apache.org/jira/browse/SLING-12173
> Project: Sling
> Issue Type: Bug
> Components: Maven Plugins and Archetypes
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: OSGi Feature Maven Plugin 1.8.2
>
>
> The slingfeature-maven-plugin currently uses the Jakarta JSON implementation
> of the Apache Johnzon parser.
> I have noticed problems in the Eclipse IDE, where projects fail to update
> with hard to isolate errors (see below).
> {noformat}java.util.ServiceConfigurationError: jakarta.json.spi.JsonProvider:
> org.apache.johnzon.core.JsonProviderImpl not a subtype
> at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:593)
> at
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1244)
> at
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1273)
> at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1309)
> at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1393)
> at jakarta.json.spi.JsonProvider.provider(JsonProvider.java:69)
> at jakarta.json.Json.createReader(Json.java:189)
> at
> org.apache.sling.feature.maven.JSONFeatures.read(JSONFeatures.java:64)
> at
> org.apache.sling.feature.maven.ProjectHelper.readFeatureFile(ProjectHelper.java:622)
> at
> org.apache.sling.feature.maven.Preprocessor.readProjectFeatures(Preprocessor.java:304)
> at
> org.apache.sling.feature.maven.Preprocessor.process(Preprocessor.java:145)
> at
> org.apache.sling.feature.maven.Preprocessor.process(Preprocessor.java:110)
> at
> org.apache.sling.feature.maven.extensions.DependencyLifecycleParticipant.afterProjectsRead(DependencyLifecycleParticipant.java:87)
> at
> org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.executeParticipants(ProjectRegistryManager.java:824)
> at
> org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.lambda$15(ProjectRegistryManager.java:791)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:275)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:214)
> at
> org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.lambda$14(ProjectRegistryManager.java:790)
> at java.base/java.util.HashMap$Values.forEach(HashMap.java:1065)
> at
> org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.lambda$11(ProjectRegistryManager.java:788)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:275)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:214)
> at
> org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.readMavenProjectFacades(ProjectRegistryManager.java:760)
> at
> org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.refresh(ProjectRegistryManager.java:392)
> at
> org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.refresh(ProjectRegistryManager.java:366)
> at
> org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.refresh(ProjectRegistryManager.java:318)
>
[jira] [Commented] (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:comment-tabpanel=17840487#comment-17840487
]
Karol Lewandowski commented on SLING-12302:
---
Thanks for the answer and the side note (I copied it from some unofficial
example and wasn't aware it was incorrect).
I provided the PR with the fix in the documentation:
[https://github.com/apache/sling-site/pull/160]
> 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
>Priority: Major
>
> 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">
> jcr:primaryType="sling:OsgiConfig"
> greeting="hello"/>
>
> {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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-12274) Introduce Import Pre-Processor Hook
[ https://issues.apache.org/jira/browse/SLING-12274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated SLING-12274: Fix Version/s: Content Distribution API 0.7.2 > Introduce Import Pre-Processor Hook > --- > > Key: SLING-12274 > URL: https://issues.apache.org/jira/browse/SLING-12274 > Project: Sling > Issue Type: New Feature > Components: Content Distribution >Reporter: Danilo Banjac >Assignee: Christian Schneider >Priority: Major > Fix For: Content Distribution API 0.7.2, Content Distribution > Journal Core 0.3.0 > > > Introduce a pre-processor hook that will be executed before the content > import process begins. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [VOTE] Release Apache Sling Rewriter 1.4.2
+1 Carsten On 24.04.2024 14:35, Carsten Ziegeler wrote: Hi, We solved 1 issues in this release https://issues.apache.org/jira/browse/SLING-12303 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2854/ You can use this UNIX script to download the release and verify the signatures: https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD Usage: sh check_staged_release.sh 2854 /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. Regards Carsten -- Carsten Ziegeler Adobe cziege...@apache.org
RE: [VOTE] Release Apache Sling Rewriter 1.4.2
+1 stefan
[jira] [Resolved] (SLING-12303) Global transformers are not sorted by service ranking
[ https://issues.apache.org/jira/browse/SLING-12303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-12303. -- Resolution: Fixed Added sorting and improved logging in https://github.com/apache/sling-org-apache-sling-rewriter/commit/c98017bc16ee3355dcd00fe080b9c93e387f18dd > Global transformers are not sorted by service ranking > - > > Key: SLING-12303 > URL: https://issues.apache.org/jira/browse/SLING-12303 > Project: Sling > Issue Type: Bug > Components: General >Affects Versions: Rewriter 1.4.0 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Major > Fix For: Rewriter 1.4.2 > > > The service ranking of a transformer (factory) is used to determine its > position in the rewriter pipeline. However, the transformers are not ordered > according to their ranking which makes the order unpredictable. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12211) Update Parent to 52 and make build compatible with Java 17 and above
[ https://issues.apache.org/jira/browse/SLING-12211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-12211: - Fix Version/s: Rewriter 1.4.4 (was: Rewriter 1.4.2) > Update Parent to 52 and make build compatible with Java 17 and above > > > Key: SLING-12211 > URL: https://issues.apache.org/jira/browse/SLING-12211 > Project: Sling > Issue Type: Improvement >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: Rewriter 1.4.4 > > > Updating to Parent 52 allows reproducible builds > (https://issues.apache.org/jira/browse/SLING-11907). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12303) Global transformers are not sorted by service ranking
Carsten Ziegeler created SLING-12303: Summary: Global transformers are not sorted by service ranking Key: SLING-12303 URL: https://issues.apache.org/jira/browse/SLING-12303 Project: Sling Issue Type: Bug Components: General Affects Versions: Rewriter 1.4.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Rewriter 1.4.2 The service ranking of a transformer (factory) is used to determine its position in the rewriter pipeline. However, the transformers are not ordered according to their ranking which makes the order unpredictable. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[Jenkins] Sling » Modules » sling-org-apache-sling-starter » master #1350 is FIXED
Please see https://ci-builds.apache.org/job/Sling/job/modules/job/sling-org-apache-sling-starter/job/master/1350/ for details. No further emails will be sent until the status of the build is changed.
[jira] [Commented] (SLING-12197) cpconverter: Sling-Initial-Content directories created as nt:folder instead of sling:Folder
[
https://issues.apache.org/jira/browse/SLING-12197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840385#comment-17840385
]
Stefan Seifert commented on SLING-12197:
[~rombert] any news on this one?
we need to make sure cpconverter creates a {{.content.xml}} with
{{jcr:primaryType=sling:Folder}} for each folder found in Sling-Initial-Content
which do not have a node type defined explicitly, so it behaves the same as the
Sling Content Loader.
i looked again a bit deeper at the cpconverter implementation, but the handling
of Sling-Initial-Content and handing it over to the other processing is rather
complex, so i currently do not feel confident to come up with a quick patch.
> cpconverter: Sling-Initial-Content directories created as nt:folder instead
> of sling:Folder
> ---
>
> Key: SLING-12197
> URL: https://issues.apache.org/jira/browse/SLING-12197
> Project: Sling
> Issue Type: Bug
> Components: Content-Package to Feature Model Converter
>Affects Versions: Content-Package to Feature Model Converter 1.3.4
>Reporter: Stefan Seifert
>Priority: Major
> Fix For: Content-Package to Feature Model Converter 1.3.8
>
> Attachments: io.wcm.handler.link-apps-1.10.2-cp2fm-converted.zip
>
>
> the cpconverter extracts Sling-Initial-Content from OSGi bundles and creates
> FileVault packages with the transformed content.
> this works well, but there is one difference when the resulting content
> package is installed compared when uploading the OSGi bundle with the
> Sling-Initial-Content directly:
> * the JCR Content Loader by defaults creates a {{sling:Folder}} node type for
> each directory found in the Sling-Initial-Content (see also
> [docs|https://sling.apache.org/documentation/bundles/content-loading-jcr-contentloader.html#initial-content-loading-1])
> * the cpconverter process creates no {{.content.xml}} file for the folders,
> but only for the actual JSON files found in the process. as a result, the
> folders are created as {{nt:folder}} when uploading the transformed package
> * this difference becomes relevant, when a JSON file in Sling-Initial-Content
> defines a primary type of {{nt:unstructured}} - it is not allowed to created
> such a node directly below a {{nt:folder}} node - but it is allowed to do so
> below a {{sling:Folder}} node
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (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:comment-tabpanel=17840363#comment-17840363
]
Stefan Seifert commented on SLING-12302:
the first syntax
{noformat}
${caconfig['com.mysite.core.config.TestConfig/nested'].greeting} {noformat}
should be used.
that the second syntax with {{['nested/greeting']}} is working is probably only
by chance, as a normal value map is used if not annotation class is used, and
that supports by default accessing deeper resource hierarchy levels via
property access. this is not the case if annotation class is used, because
there the value map is constructed by other means, e.g. to support the default
values that may be defined in the annotation class.
sidenote: you should not use {{jcr:primaryType="sling:OsgiConfig"}} in context
of caconfig - it's only use is for defining osgi configurations in the JCR
repository, so using it here could have unwanted side-effect. just use
nt:unstructured (unless you are using a different persistence strategy e.g.
https://wcm.io/caconfig/extensions/ for storing in cq:Page objects).
> 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
>Priority: Major
>
> 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">
> jcr:primaryType="sling:OsgiConfig"
> greeting="hello"/>
>
> {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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[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:
[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:
[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:
[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)
