[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=17845977#comment-17845977
]
Stefan Seifert commented on SLING-12302:
for 1.: this looks like a bug, i assume that it probably not only affects HTL
context, but in general. i think it would be worth creating a dedicated issue
for it, probably with a unit test case, if possible.
for 2: i'm not sure how much this syntax to fetch complex caconfigs directly
from HTL is used in practice - probably not so much, esp. considering the fact
you are the first asking that detailed questions after all that years it's
available... i think there is no easy way to iterate over nested child lists,
and currently we do not plan to add support for that, unless there is a high
need. i think in most cases caconfigs are consumed in sling models, and
consumed in HTL from there. a benefit of that approach is to use strong typing
and compile-time check.
> 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
>Assignee: Stefan Seifert
>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] [Closed] (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:all-tabpanel
]
Stefan Seifert closed SLING-12197.
--
> 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
> 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] [Resolved] (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:all-tabpanel
]
Stefan Seifert resolved SLING-12197.
Fix Version/s: (was: Content-Package to Feature Model Converter 1.3.8)
Resolution: Not A Bug
closing this ticket, as the root cause was not in the cpconverter
> 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
> 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-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=17841445#comment-17841445
]
Stefan Seifert commented on SLING-12197:
thanks for the analysis!
> 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-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=17841068#comment-17841068
]
Stefan Seifert commented on SLING-12197:
bq. At least for mutable content, if i'm not wrong we use the order of the
generated packages.csv from the cpconverter to deploy later.
yes, but in this case its about the ordering of (sticking to the unit test
example):
1. repoinit statements generated from {{io.wcm.handler.media-1.11.6.jar}}
2. content package {{io.wcm.handler.media-apps-1.11.6-cp2fm-converted.zip}}
with *immutable* content generated from {{io.wcm.handler.media-1.11.6.jar}},
containing nodes and scripts below {{/apps}}
they have to be executed in exactly this order - if the folders already exists
after installing the package the repoinit statements have no effect.
> 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] [Comment Edited] (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=17841068#comment-17841068
]
Stefan Seifert edited comment on SLING-12197 at 4/26/24 7:02 AM:
-
bq. At least for mutable content, if i'm not wrong we use the order of the
generated packages.csv from the cpconverter to deploy later.
yes, but in this case its about the ordering of (sticking to the unit test
example):
# repoinit statements generated from {{io.wcm.handler.media-1.11.6.jar}}
# content package {{io.wcm.handler.media-apps-1.11.6-cp2fm-converted.zip}} with
*immutable* content generated from {{io.wcm.handler.media-1.11.6.jar}},
containing nodes and scripts below {{/apps}}
they have to be executed in exactly this order - if the folders already exists
after installing the package the repoinit statements have no effect.
was (Author: sseif...@pro-vision.de):
bq. At least for mutable content, if i'm not wrong we use the order of the
generated packages.csv from the cpconverter to deploy later.
yes, but in this case its about the ordering of (sticking to the unit test
example):
1. repoinit statements generated from {{io.wcm.handler.media-1.11.6.jar}}
2. content package {{io.wcm.handler.media-apps-1.11.6-cp2fm-converted.zip}}
with *immutable* content generated from {{io.wcm.handler.media-1.11.6.jar}},
containing nodes and scripts below {{/apps}}
they have to be executed in exactly this order - if the folders already exists
after installing the package the repoinit statements have no effect.
> 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] [Resolved] (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
]
Stefan Seifert resolved SLING-12302.
Assignee: Stefan Seifert
Resolution: Fixed
thanks, i've merged the PR
> 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
>Assignee: Stefan Seifert
>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] [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=17840834#comment-17840834
]
Stefan Seifert commented on SLING-12197:
good point - i discovered that most of the test code for Sling-Initial-Content
is in this test class:
https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/master/src/test/java/org/apache/sling/feature/cpconverter/handlers/BundleEntryHandleSlingInitialContentTest.java
and the good thing the unit test uses already a jar file
{{io.wcm.handler.media-1.11.6.jar}} which is affected exactly by the problem.
i've found that there is already an implementation that should fix the problem
described in this ticket (but does not actually), this path is exactly verified
here as repoinit statement, but fails to be created with sling:Folder currently
(nt:folder instead):
https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/2ed5bdc8ccaf8ab9079268bfbc9d1fdc77bbd485/src/test/java/org/apache/sling/feature/cpconverter/handlers/BundleEntryHandleSlingInitialContentTest.java#L146
so maybe this is a pointer to a strange thing: the whole initial content
processing with the folder primary types worked initially fine (e.g. with
cpconverter around 1.1.25), and broke some time later. maybe the root cause is
not the sling-initial-content processing, but the processing of the repoinit
statements it creates?
e.g. if the order of deploying the content package generated from the jar file,
and execution of the repoinit statements is done in the wrong way (package
first), it will break, if it is done right it will work. because the repoinit
statements in the unit test look correct and should fix the problem.
maybe the problem is not within cpconverter, but in downstream code picking up
the resulting packages and repoinit statements, and the problem lies there
(i.e. AEMaaCS build pipeline)?
> 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-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=17840751#comment-17840751
]
Stefan Seifert commented on SLING-12197:
can we reach out to [~Sc0rpic0m] who did the initial implementation as part of
SLING-10931?
> 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-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] [Closed] (SLING-12278) Improve handling of late instantiated context in SlingContextExtension/OsgiContextExtension
[
https://issues.apache.org/jira/browse/SLING-12278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert closed SLING-12278.
--
> Improve handling of late instantiated context in
> SlingContextExtension/OsgiContextExtension
> ---
>
> Key: SLING-12278
> URL: https://issues.apache.org/jira/browse/SLING-12278
> Project: Sling
> Issue Type: Improvement
> Components: Testing
>Affects Versions: Testing OSGi Mock 3.4.2, Testing Sling Mock 3.5.0
>Reporter: Konrad Windszus
>Assignee: Stefan Seifert
>Priority: Major
>
> Currently neither in
> https://sling.apache.org/documentation/development/osgi-mock.html#junit-5-osgi-context-junit-extension
> nor in
> https://sling.apache.org/documentation/development/sling-mock.html#junit-5-sling-context-junit-extension
> it is mentioned that the context must not be instantiated in {{@BeforeAll}}
> or {{@BeforeEach}} as at that point in time the extension has already
> instantiated another context. Those two contexts may lead to subtle issues
> (for example if resources are only added in the second context). For a
> concrete example look at
> https://github.com/wcm-io/io.wcm.testing.aem-mock/issues/37.
> In the best case the JUnit5 extension never creates a context (but only uses
> the existing instance) or at least creation should be deferred until the
> Before methods have been executed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SLING-12278) Improve handling of late instantiated context in SlingContextExtension/OsgiContextExtension
[
https://issues.apache.org/jira/browse/SLING-12278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert resolved SLING-12278.
Resolution: Fixed
https://github.com/apache/sling-site/commit/5c122e825c6cf212e74fadeb2e6cc2afce0666a8
> Improve handling of late instantiated context in
> SlingContextExtension/OsgiContextExtension
> ---
>
> Key: SLING-12278
> URL: https://issues.apache.org/jira/browse/SLING-12278
> Project: Sling
> Issue Type: Improvement
> Components: Testing
>Affects Versions: Testing OSGi Mock 3.4.2, Testing Sling Mock 3.5.0
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently neither in
> https://sling.apache.org/documentation/development/osgi-mock.html#junit-5-osgi-context-junit-extension
> nor in
> https://sling.apache.org/documentation/development/sling-mock.html#junit-5-sling-context-junit-extension
> it is mentioned that the context must not be instantiated in {{@BeforeAll}}
> or {{@BeforeEach}} as at that point in time the extension has already
> instantiated another context. Those two contexts may lead to subtle issues
> (for example if resources are only added in the second context). For a
> concrete example look at
> https://github.com/wcm-io/io.wcm.testing.aem-mock/issues/37.
> In the best case the JUnit5 extension never creates a context (but only uses
> the existing instance) or at least creation should be deferred until the
> Before methods have been executed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (SLING-12278) Improve handling of late instantiated context in SlingContextExtension/OsgiContextExtension
[
https://issues.apache.org/jira/browse/SLING-12278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert reassigned SLING-12278:
--
Assignee: Stefan Seifert
> Improve handling of late instantiated context in
> SlingContextExtension/OsgiContextExtension
> ---
>
> Key: SLING-12278
> URL: https://issues.apache.org/jira/browse/SLING-12278
> Project: Sling
> Issue Type: Improvement
> Components: Testing
>Affects Versions: Testing OSGi Mock 3.4.2, Testing Sling Mock 3.5.0
>Reporter: Konrad Windszus
>Assignee: Stefan Seifert
>Priority: Major
>
> Currently neither in
> https://sling.apache.org/documentation/development/osgi-mock.html#junit-5-osgi-context-junit-extension
> nor in
> https://sling.apache.org/documentation/development/sling-mock.html#junit-5-sling-context-junit-extension
> it is mentioned that the context must not be instantiated in {{@BeforeAll}}
> or {{@BeforeEach}} as at that point in time the extension has already
> instantiated another context. Those two contexts may lead to subtle issues
> (for example if resources are only added in the second context). For a
> concrete example look at
> https://github.com/wcm-io/io.wcm.testing.aem-mock/issues/37.
> In the best case the JUnit5 extension never creates a context (but only uses
> the existing instance) or at least creation should be deferred until the
> Before methods have been executed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12278) Improve handling of late instantiated context in SlingContextExtension/OsgiContextExtension
[
https://issues.apache.org/jira/browse/SLING-12278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839637#comment-17839637
]
Stefan Seifert commented on SLING-12278:
documentation PR: https://github.com/apache/sling-site/pull/159
> Improve handling of late instantiated context in
> SlingContextExtension/OsgiContextExtension
> ---
>
> Key: SLING-12278
> URL: https://issues.apache.org/jira/browse/SLING-12278
> Project: Sling
> Issue Type: Improvement
> Components: Testing
>Affects Versions: Testing OSGi Mock 3.4.2, Testing Sling Mock 3.5.0
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently neither in
> https://sling.apache.org/documentation/development/osgi-mock.html#junit-5-osgi-context-junit-extension
> nor in
> https://sling.apache.org/documentation/development/sling-mock.html#junit-5-sling-context-junit-extension
> it is mentioned that the context must not be instantiated in {{@BeforeAll}}
> or {{@BeforeEach}} as at that point in time the extension has already
> instantiated another context. Those two contexts may lead to subtle issues
> (for example if resources are only added in the second context). For a
> concrete example look at
> https://github.com/wcm-io/io.wcm.testing.aem-mock/issues/37.
> In the best case the JUnit5 extension never creates a context (but only uses
> the existing instance) or at least creation should be deferred until the
> Before methods have been executed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-12278) Improve handling of late instantiated context in SlingContextExtension/OsgiContextExtension
[
https://issues.apache.org/jira/browse/SLING-12278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert updated SLING-12278:
---
Component/s: Testing
Affects Version/s: Testing Sling Mock 3.5.0
Testing OSGi Mock 3.4.2
the way the current junit 5 implemention is done in sling-mock, osgi-mock and
aem-mock dates back to the time of JUnit 5.0 ([PR
#5|[https://github.com/wcm-io/wcm-io-testing/pull/5]),] and i've never
investigated much further if this is nowadays still the best way to do an junit
5 extension. it seems the programmatic extension registration was introduced in
junit 5.1.
i currently cannot oversee how much benefit a switch or additional support of
programmatic extension registration would bring - in any case it would be a lot
of work to make sure it all works as expected, and we cannot remove the current
way to register it for backwards compatibility.
so for now, i will only extend the documentation to make sure context objects
are not created e.g. in BeforeEach/BeforeAll methods.
> Improve handling of late instantiated context in
> SlingContextExtension/OsgiContextExtension
> ---
>
> Key: SLING-12278
> URL: https://issues.apache.org/jira/browse/SLING-12278
> Project: Sling
> Issue Type: Improvement
> Components: Testing
>Affects Versions: Testing OSGi Mock 3.4.2, Testing Sling Mock 3.5.0
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently neither in
> https://sling.apache.org/documentation/development/osgi-mock.html#junit-5-osgi-context-junit-extension
> nor in
> https://sling.apache.org/documentation/development/sling-mock.html#junit-5-sling-context-junit-extension
> it is mentioned that the context must not be instantiated in {{@BeforeAll}}
> or {{@BeforeEach}} as at that point in time the extension has already
> instantiated another context. Those two contexts may lead to subtle issues
> (for example if resources are only added in the second context). For a
> concrete example look at
> https://github.com/wcm-io/io.wcm.testing.aem-mock/issues/37.
> In the best case the JUnit5 extension never creates a context (but only uses
> the existing instance) or at least creation should be deferred until the
> Before methods have been executed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (SLING-12278) Improve handling of late instantiated context in SlingContextExtension/OsgiContextExtension
[
https://issues.apache.org/jira/browse/SLING-12278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839626#comment-17839626
]
Stefan Seifert edited comment on SLING-12278 at 4/22/24 11:51 AM:
--
the way the current junit 5 implemention is done in sling-mock, osgi-mock and
aem-mock dates back to the time of JUnit 5.0 ([PR
#5|https://github.com/wcm-io/wcm-io-testing/pull/5]), and i've never
investigated much further if this is nowadays still the best way to do an junit
5 extension. it seems the programmatic extension registration was introduced in
junit 5.1.
i currently cannot oversee how much benefit a switch or additional support of
programmatic extension registration would bring - in any case it would be a lot
of work to make sure it all works as expected, and we cannot remove the current
way to register it for backwards compatibility.
so for now, i will only extend the documentation to make sure context objects
are not created e.g. in BeforeEach/BeforeAll methods.
was (Author: sseif...@pro-vision.de):
the way the current junit 5 implemention is done in sling-mock, osgi-mock and
aem-mock dates back to the time of JUnit 5.0 ([PR
#5|[https://github.com/wcm-io/wcm-io-testing/pull/5]),] and i've never
investigated much further if this is nowadays still the best way to do an junit
5 extension. it seems the programmatic extension registration was introduced in
junit 5.1.
i currently cannot oversee how much benefit a switch or additional support of
programmatic extension registration would bring - in any case it would be a lot
of work to make sure it all works as expected, and we cannot remove the current
way to register it for backwards compatibility.
so for now, i will only extend the documentation to make sure context objects
are not created e.g. in BeforeEach/BeforeAll methods.
> Improve handling of late instantiated context in
> SlingContextExtension/OsgiContextExtension
> ---
>
> Key: SLING-12278
> URL: https://issues.apache.org/jira/browse/SLING-12278
> Project: Sling
> Issue Type: Improvement
> Components: Testing
>Affects Versions: Testing OSGi Mock 3.4.2, Testing Sling Mock 3.5.0
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently neither in
> https://sling.apache.org/documentation/development/osgi-mock.html#junit-5-osgi-context-junit-extension
> nor in
> https://sling.apache.org/documentation/development/sling-mock.html#junit-5-sling-context-junit-extension
> it is mentioned that the context must not be instantiated in {{@BeforeAll}}
> or {{@BeforeEach}} as at that point in time the extension has already
> instantiated another context. Those two contexts may lead to subtle issues
> (for example if resources are only added in the second context). For a
> concrete example look at
> https://github.com/wcm-io/io.wcm.testing.aem-mock/issues/37.
> In the best case the JUnit5 extension never creates a context (but only uses
> the existing instance) or at least creation should be deferred until the
> Before methods have been executed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SLING-12287) sling-mock-oak: Update to Oak 1.60 and provide separate 1.22 release
[ https://issues.apache.org/jira/browse/SLING-12287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-12287. -- > sling-mock-oak: Update to Oak 1.60 and provide separate 1.22 release > > > Key: SLING-12287 > URL: https://issues.apache.org/jira/browse/SLING-12287 > Project: Sling > Issue Type: Improvement > Components: Testing >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: Testing Sling Mock Oak 3.2.0-1.22.15, Testing Sling Mock > Oak 4.0.0-1.62.0 > > > following the discussion with [~reschke] in SLING-12266 we should move away > from oak 1.44 which is quite outdated. however, we need to ensure to keep > compatibility with the old 1.22.x version range to support all sorts of > projects using the mocks. > a solution might be to switch to a recent version of oak in the POM, and > create dedicated ITs to test against this and older 1.22.x versions to ensure > compatibility. > the benefit is, that all projects that are "just using" sling-mock-oak > without thinking about the dependency management (e.g. not using something > like [https://wcm.io/tooling/maven/aem-dependencies.html)] will get the > latest version which is better supported. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12266) Cache initial repository state to improve JCR_OAK performance
[ https://issues.apache.org/jira/browse/SLING-12266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-12266. -- > Cache initial repository state to improve JCR_OAK performance > - > > Key: SLING-12266 > URL: https://issues.apache.org/jira/browse/SLING-12266 > Project: Sling > Issue Type: Improvement > Components: Testing >Affects Versions: Testing Sling Mock 3.4.18 >Reporter: Csaba Varga >Assignee: Stefan Seifert >Priority: Minor > Fix For: Testing Sling Mock Oak 3.2.0-1.22.15, Testing Sling Mock > 3.5.0, Testing Sling Mock Oak 4.0.0-1.62.0 > > > A lot of effort goes into preparing an Oak Mock repository from scratch: node > types need to be registered, indexes need to be created, and all this happens > over several commits. None of this work depends on the test case itself, so > it will always result in the exact same repository state. We could take the > root NodeState from the first repository we build, then build subsequent > repositories on top of it, avoiding most of the redundant work. Commits can > be relatively expensive even in memory, so each one we avoid can save a lot > of time in the long term. > > This would require extending the contract between Testing Sling Mock and the > ResourceResolverTypeAdapters, to add optional "make snapshot" and "build repo > from snapshot" operations. For adapters that don't support them, we would > keep rebuilding things from scratch. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12265) Node type registration is inefficient during unit tests when using the JCR_OAK resolver type
[ https://issues.apache.org/jira/browse/SLING-12265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-12265. -- > Node type registration is inefficient during unit tests when using the > JCR_OAK resolver type > > > Key: SLING-12265 > URL: https://issues.apache.org/jira/browse/SLING-12265 > Project: Sling > Issue Type: Improvement > Components: Testing >Affects Versions: Testing Sling Mock 3.4.18 >Reporter: Csaba Varga >Assignee: Stefan Seifert >Priority: Minor > Labels: performance > Fix For: Testing Sling Mock 3.5.0 > > > I did some profiling on my company's slow-running unit tests today, and found > that 70+% of the CPU time is spent inside NodeTypeDefinitionScanner, more > specifically in the commit() call triggered by it. Our test classpath > includes AEM Mocks and the Cloud SDK, resulting in 30+ CND files being > detected, and as many commits done preparing the repository before each test. > (Slightly more, because some commits fail and get retried later.) > It should be possible to parse each CND into memory structures in a separate > pass, then create the node types all at once in a single commit. This > wouldn't just eliminate the extra commits, but would also remove the need to > retry, since all dependencies would also be provided in the same call. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12296) sling-mock-oak: Update to Oak 1.62.0
[ https://issues.apache.org/jira/browse/SLING-12296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-12296. -- > sling-mock-oak: Update to Oak 1.62.0 > > > Key: SLING-12296 > URL: https://issues.apache.org/jira/browse/SLING-12296 > Project: Sling > Issue Type: Improvement > Components: Testing >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Minor > Fix For: Testing Sling Mock Oak 4.0.0-1.62.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12284) sling/jcr/osgi/resourceresolver-mock: Update to Parent 60, Java 11 Minimum Version
[ https://issues.apache.org/jira/browse/SLING-12284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-12284. -- > sling/jcr/osgi/resourceresolver-mock: Update to Parent 60, Java 11 Minimum > Version > -- > > Key: SLING-12284 > URL: https://issues.apache.org/jira/browse/SLING-12284 > Project: Sling > Issue Type: Improvement > Components: Testing >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: Testing Logging Mock 2.1.0, Testing Sling Mock Oak > 3.2.0-1.22.15, Context-Aware Configuration Mock Plugin 1.6.0, Testing JCR > Mock 1.7.0, Testing OSGi Mock 3.5.0, Testing ResourceResolver Mock 1.5.0, > Testing Sling Mock 3.5.0, Testing Sling Mock Oak 4.0.0-1.62.0 > > > update to parent 60, see also [https://cwiki.apache.org/confluence/x/SI75E] > this drops java 8 support, and instead supports java 11, 17, 21 - build is > done with java 17 > minimum java requirement for runtime is java 11 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-12296) sling-mock-oak: Update to Oak 1.62.0
[ https://issues.apache.org/jira/browse/SLING-12296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert resolved SLING-12296. Resolution: Fixed https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/commit/68e22b7f3087f1caafbc457ddb2b20df7e8c1beb > sling-mock-oak: Update to Oak 1.62.0 > > > Key: SLING-12296 > URL: https://issues.apache.org/jira/browse/SLING-12296 > Project: Sling > Issue Type: Improvement > Components: Testing >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Minor > Fix For: Testing Sling Mock Oak 4.0.0-1.62.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12296) sling-mock-oak: Update to Oak 1.62.0
Stefan Seifert created SLING-12296: -- Summary: sling-mock-oak: Update to Oak 1.62.0 Key: SLING-12296 URL: https://issues.apache.org/jira/browse/SLING-12296 Project: Sling Issue Type: Improvement Components: Testing Reporter: Stefan Seifert Assignee: Stefan Seifert Fix For: Testing Sling Mock Oak 4.0.0-1.62.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-12287) sling-mock-oak: Update to Oak 1.60 and provide separate 1.22 release
[ https://issues.apache.org/jira/browse/SLING-12287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert resolved SLING-12287. Resolution: Fixed * 4.x: (master): [https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/commit/d4f0388ac9cf592a218230ee01cf14a6c3a93463] * 3.2.x: https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/commit/edf70e21c3e06b9e4960d99332669050727c7251 > sling-mock-oak: Update to Oak 1.60 and provide separate 1.22 release > > > Key: SLING-12287 > URL: https://issues.apache.org/jira/browse/SLING-12287 > Project: Sling > Issue Type: Improvement > Components: Testing >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: Testing Sling Mock Oak 3.2.0-1.22.15, Testing Sling Mock > Oak 4.0.0-1.60.0 > > > following the discussion with [~reschke] in SLING-12266 we should move away > from oak 1.44 which is quite outdated. however, we need to ensure to keep > compatibility with the old 1.22.x version range to support all sorts of > projects using the mocks. > a solution might be to switch to a recent version of oak in the POM, and > create dedicated ITs to test against this and older 1.22.x versions to ensure > compatibility. > the benefit is, that all projects that are "just using" sling-mock-oak > without thinking about the dependency management (e.g. not using something > like [https://wcm.io/tooling/maven/aem-dependencies.html)] will get the > latest version which is better supported. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (SLING-12287) sling-mock-oak: Update to Oak 1.60 and provide separate 1.22 release
[ https://issues.apache.org/jira/browse/SLING-12287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836439#comment-17836439 ] Stefan Seifert edited comment on SLING-12287 at 4/17/24 2:00 PM: - looking deeper into this, i think it's not easy possible to have a single JAR/POM supporting both oak 1.22 and latest oak version at the same time. there is too much change between them, regarding supported jdks and the change guava is embedded. i currently plan to do a branching of sling-mock-oak - one maintenance branch for 1.22.x and one for latest versions - this is in-line how oak itself it is doing. i started two draft PRs and will continue test the produced JARs in different project environments if this is working. maybe we can eliminate more of the shading/embedding in the latest sling-mock-oak version which would be a good thing. * sling-mock-oak 4.x with Oak 1.60: [https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/pull/14] * sling-mock-oak 3.2.x with Oak 1.22: [https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/pull/13] was (Author: sseif...@pro-vision.de): looking deeper into this, i think it's not easy possible to have a single JAR/POM supporting both oak 1.22 and latest oak version at the same time. there is too much change between them, regarding supported jdks and the change guava is embedded. i currently plan to do a branching of sling-mock-oak - one maintenance branch for 1.22.x and one for latest versions - this is in-line how oak itself it is doing. i started two draft PRs and will continue test the produced JARs in different project environments if this is working. maybe we can eliminate more of the shading/embedding in the latest sling-mock-oak version which would be a good thing. * sling-mock-oak 4.x with Oak 1.60: https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/pull/13 * sling-mock-oak 3.2.x with Oak 1.22: https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/pull/14 > sling-mock-oak: Update to Oak 1.60 and provide separate 1.22 release > > > Key: SLING-12287 > URL: https://issues.apache.org/jira/browse/SLING-12287 > Project: Sling > Issue Type: Improvement > Components: Testing >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: Testing Sling Mock Oak 3.2.0-1.22.15, Testing Sling Mock > Oak 4.0.0-1.60.0 > > > following the discussion with [~reschke] in SLING-12266 we should move away > from oak 1.44 which is quite outdated. however, we need to ensure to keep > compatibility with the old 1.22.x version range to support all sorts of > projects using the mocks. > a solution might be to switch to a recent version of oak in the POM, and > create dedicated ITs to test against this and older 1.22.x versions to ensure > compatibility. > the benefit is, that all projects that are "just using" sling-mock-oak > without thinking about the dependency management (e.g. not using something > like [https://wcm.io/tooling/maven/aem-dependencies.html)] will get the > latest version which is better supported. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12287) sling-mock-oak: Update to Oak 1.60 and provide separate 1.22 release
[ https://issues.apache.org/jira/browse/SLING-12287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert updated SLING-12287: --- Fix Version/s: Testing Sling Mock Oak 4.0.0-1.60.0 > sling-mock-oak: Update to Oak 1.60 and provide separate 1.22 release > > > Key: SLING-12287 > URL: https://issues.apache.org/jira/browse/SLING-12287 > Project: Sling > Issue Type: Improvement > Components: Testing >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: Testing Sling Mock Oak 3.2.0-1.22.15, Testing Sling Mock > Oak 4.0.0-1.60.0 > > > following the discussion with [~reschke] in SLING-12266 we should move away > from oak 1.44 which is quite outdated. however, we need to ensure to keep > compatibility with the old 1.22.x version range to support all sorts of > projects using the mocks. > a solution might be to switch to a recent version of oak in the POM, and > create dedicated ITs to test against this and older 1.22.x versions to ensure > compatibility. > the benefit is, that all projects that are "just using" sling-mock-oak > without thinking about the dependency management (e.g. not using something > like [https://wcm.io/tooling/maven/aem-dependencies.html)] will get the > latest version which is better supported. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12287) sling-mock-oak: Update to Oak 1.60 and provide separate 1.22 release
[ https://issues.apache.org/jira/browse/SLING-12287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert updated SLING-12287: --- Summary: sling-mock-oak: Update to Oak 1.60 and provide separate 1.22 release (was: sling-mock-oak: Use latest Oak Version and add ITs to ensure compatiblity with 1.22.x) > sling-mock-oak: Update to Oak 1.60 and provide separate 1.22 release > > > Key: SLING-12287 > URL: https://issues.apache.org/jira/browse/SLING-12287 > Project: Sling > Issue Type: Improvement > Components: Testing >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: Testing Sling Mock Oak 3.2.0-1.44.0 > > > following the discussion with [~reschke] in SLING-12266 we should move away > from oak 1.44 which is quite outdated. however, we need to ensure to keep > compatibility with the old 1.22.x version range to support all sorts of > projects using the mocks. > a solution might be to switch to a recent version of oak in the POM, and > create dedicated ITs to test against this and older 1.22.x versions to ensure > compatibility. > the benefit is, that all projects that are "just using" sling-mock-oak > without thinking about the dependency management (e.g. not using something > like [https://wcm.io/tooling/maven/aem-dependencies.html)] will get the > latest version which is better supported. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12281) Content Parser: Update to Parent 60, Java 11 Minimum Version
[ https://issues.apache.org/jira/browse/SLING-12281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-12281. -- > Content Parser: Update to Parent 60, Java 11 Minimum Version > > > Key: SLING-12281 > URL: https://issues.apache.org/jira/browse/SLING-12281 > Project: Sling > Issue Type: Improvement > Components: Content Parser >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: Content Parser API 2.1.0, Content Parser Test Utilities > 2.1.0, Content Parser JSON 2.1.0, Content Parser XML 2.1.0, Content Parser > XML JCR 2.1.0 > > > update to parent 60, regarding [https://cwiki.apache.org/confluence/x/SI75E] > this drops java 8 support, and instead supports java 11, 17, 21 - build is > done with java 17 > minimum java requirement for runtime is java 11 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12102) Content Parser: Update to Parent 52
[ https://issues.apache.org/jira/browse/SLING-12102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-12102. -- > Content Parser: Update to Parent 52 > --- > > Key: SLING-12102 > URL: https://issues.apache.org/jira/browse/SLING-12102 > Project: Sling > Issue Type: Improvement > Components: Content Parser >Affects Versions: Content Parser API 2.0.0, Content Parser JSON 2.0.0, > Content Parser XML 2.0.0, Content Parser XML JCR 2.0.0, Content Parser Test > Utilities 2.0.0 >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: Content Parser API 2.1.0, Content Parser Test Utilities > 2.1.0, Content Parser JSON 2.1.0, Content Parser XML 2.1.0, Content Parser > XML JCR 2.1.0 > > > update to latest parent, fix build with java 17 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12282) Content Parser: Update Dependencies to 2023
[ https://issues.apache.org/jira/browse/SLING-12282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-12282. -- > Content Parser: Update Dependencies to 2023 > --- > > Key: SLING-12282 > URL: https://issues.apache.org/jira/browse/SLING-12282 > Project: Sling > Issue Type: Improvement > Components: Content Parser >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: Content Parser Test Utilities 2.1.0, Content Parser JSON > 2.1.0, Content Parser XML 2.1.0, Content Parser XML JCR 2.1.0 > > > in line with and using the same concept of SLING-12208 update 3rdparty > dependencies to a newer version for content parser modules -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12280) Migrate org.apache.sling.contentparser.json to jakarta.json
[ https://issues.apache.org/jira/browse/SLING-12280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-12280. -- > Migrate org.apache.sling.contentparser.json to jakarta.json > --- > > Key: SLING-12280 > URL: https://issues.apache.org/jira/browse/SLING-12280 > Project: Sling > Issue Type: Sub-task > Components: Content Parser >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: Content Parser JSON 2.1.0 > > > to support johnzon 2.0 in unit tests with sling-mocks, we need to switch to > jakarta.json for the JSON content parser as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12287) sling-mock-oak: Use latest Oak Version and add ITs to ensure compatiblity with 1.22.x
[ https://issues.apache.org/jira/browse/SLING-12287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836439#comment-17836439 ] Stefan Seifert commented on SLING-12287: looking deeper into this, i think it's not easy possible to have a single JAR/POM supporting both oak 1.22 and latest oak version at the same time. there is too much change between them, regarding supported jdks and the change guava is embedded. i currently plan to do a branching of sling-mock-oak - one maintenance branch for 1.22.x and one for latest versions - this is in-line how oak itself it is doing. i started two draft PRs and will continue test the produced JARs in different project environments if this is working. maybe we can eliminate more of the shading/embedding in the latest sling-mock-oak version which would be a good thing. * sling-mock-oak 4.x with Oak 1.60: https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/pull/13 * sling-mock-oak 3.2.x with Oak 1.22: https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/pull/14 > sling-mock-oak: Use latest Oak Version and add ITs to ensure compatiblity > with 1.22.x > - > > Key: SLING-12287 > URL: https://issues.apache.org/jira/browse/SLING-12287 > Project: Sling > Issue Type: Improvement > Components: Testing >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: Testing Sling Mock Oak 3.2.0-1.44.0 > > > following the discussion with [~reschke] in SLING-12266 we should move away > from oak 1.44 which is quite outdated. however, we need to ensure to keep > compatibility with the old 1.22.x version range to support all sorts of > projects using the mocks. > a solution might be to switch to a recent version of oak in the POM, and > create dedicated ITs to test against this and older 1.22.x versions to ensure > compatibility. > the benefit is, that all projects that are "just using" sling-mock-oak > without thinking about the dependency management (e.g. not using something > like [https://wcm.io/tooling/maven/aem-dependencies.html)] will get the > latest version which is better supported. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-12266) Cache initial repository state to improve JCR_OAK performance
[ https://issues.apache.org/jira/browse/SLING-12266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert resolved SLING-12266. Fix Version/s: Testing Sling Mock Oak 3.2.0-1.44.0 Testing Sling Mock 3.5.0 Resolution: Fixed * [https://github.com/apache/sling-org-apache-sling-testing-sling-mock/commit/0fb97232b98a91bdca3b5accaa3d499175e4685b] * [https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/commit/7a8c92c3f6995c54d38aebecd8225d2fa3a2f5ee] * > Cache initial repository state to improve JCR_OAK performance > - > > Key: SLING-12266 > URL: https://issues.apache.org/jira/browse/SLING-12266 > Project: Sling > Issue Type: Improvement > Components: Testing >Affects Versions: Testing Sling Mock 3.4.18 >Reporter: Csaba Varga >Assignee: Stefan Seifert >Priority: Minor > Fix For: Testing Sling Mock Oak 3.2.0-1.44.0, Testing Sling Mock > 3.5.0 > > > A lot of effort goes into preparing an Oak Mock repository from scratch: node > types need to be registered, indexes need to be created, and all this happens > over several commits. None of this work depends on the test case itself, so > it will always result in the exact same repository state. We could take the > root NodeState from the first repository we build, then build subsequent > repositories on top of it, avoiding most of the redundant work. Commits can > be relatively expensive even in memory, so each one we avoid can save a lot > of time in the long term. > > This would require extending the contract between Testing Sling Mock and the > ResourceResolverTypeAdapters, to add optional "make snapshot" and "build repo > from snapshot" operations. For adapters that don't support them, we would > keep rebuilding things from scratch. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12287) sling-mock-oak: Use latest Oak Version and add ITs to ensure compatiblity with 1.22.x
Stefan Seifert created SLING-12287: -- Summary: sling-mock-oak: Use latest Oak Version and add ITs to ensure compatiblity with 1.22.x Key: SLING-12287 URL: https://issues.apache.org/jira/browse/SLING-12287 Project: Sling Issue Type: Improvement Components: Testing Reporter: Stefan Seifert Assignee: Stefan Seifert Fix For: Testing Sling Mock Oak 3.2.0-1.44.0 following the discussion with [~reschke] in SLING-12266 we should move away from oak 1.44 which is quite outdated. however, we need to ensure to keep compatibility with the old 1.22.x version range to support all sorts of projects using the mocks. a solution might be to switch to a recent version of oak in the POM, and create dedicated ITs to test against this and older 1.22.x versions to ensure compatibility. the benefit is, that all projects that are "just using" sling-mock-oak without thinking about the dependency management (e.g. not using something like [https://wcm.io/tooling/maven/aem-dependencies.html)] will get the latest version which is better supported. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12266) Cache initial repository state to improve JCR_OAK performance
[ https://issues.apache.org/jira/browse/SLING-12266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836068#comment-17836068 ] Stefan Seifert commented on SLING-12266: ah, ok. there was some need form other sling modules to have a slightly newer version from oak in sling-mock-oak than 1.22, so we are currently between chairs of supporting the "old and the new world". usually, the actual version that is used in the unit tests should be controlled by the project environment e.g. when using [https://wcm.io/tooling/maven/aem-dependencies.html] for either AEMaaCS or AEM 6.5, so this is a bit of an academic discussion. of course, there may be projects that to not care about that dependency management and end up with 1.44. we might think about a way to ensure compatibility with different old and new versions in CI and use a newer version in the POM. however, this is off-topic for this ticket. [~Csaba Varga] it would be great if you can remove the makeJcr optimization then we can merge the PRs. > Cache initial repository state to improve JCR_OAK performance > - > > Key: SLING-12266 > URL: https://issues.apache.org/jira/browse/SLING-12266 > Project: Sling > Issue Type: Improvement > Components: Testing >Affects Versions: Testing Sling Mock 3.4.18 >Reporter: Csaba Varga >Assignee: Stefan Seifert >Priority: Minor > > A lot of effort goes into preparing an Oak Mock repository from scratch: node > types need to be registered, indexes need to be created, and all this happens > over several commits. None of this work depends on the test case itself, so > it will always result in the exact same repository state. We could take the > root NodeState from the first repository we build, then build subsequent > repositories on top of it, avoiding most of the redundant work. Commits can > be relatively expensive even in memory, so each one we avoid can save a lot > of time in the long term. > > This would require extending the contract between Testing Sling Mock and the > ResourceResolverTypeAdapters, to add optional "make snapshot" and "build repo > from snapshot" operations. For adapters that don't support them, we would > keep rebuilding things from scratch. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12266) Cache initial repository state to improve JCR_OAK performance
[ https://issues.apache.org/jira/browse/SLING-12266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836059#comment-17836059 ] Stefan Seifert commented on SLING-12266: yes - and we should be using that oak 1.22.x version in all sling mocks, sling-mock-oak is using 1.44 > Cache initial repository state to improve JCR_OAK performance > - > > Key: SLING-12266 > URL: https://issues.apache.org/jira/browse/SLING-12266 > Project: Sling > Issue Type: Improvement > Components: Testing >Affects Versions: Testing Sling Mock 3.4.18 >Reporter: Csaba Varga >Assignee: Stefan Seifert >Priority: Minor > > A lot of effort goes into preparing an Oak Mock repository from scratch: node > types need to be registered, indexes need to be created, and all this happens > over several commits. None of this work depends on the test case itself, so > it will always result in the exact same repository state. We could take the > root NodeState from the first repository we build, then build subsequent > repositories on top of it, avoiding most of the redundant work. Commits can > be relatively expensive even in memory, so each one we avoid can save a lot > of time in the long term. > > This would require extending the contract between Testing Sling Mock and the > ResourceResolverTypeAdapters, to add optional "make snapshot" and "build repo > from snapshot" operations. For adapters that don't support them, we would > keep rebuilding things from scratch. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12266) Cache initial repository state to improve JCR_OAK performance
[ https://issues.apache.org/jira/browse/SLING-12266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836054#comment-17836054 ] Stefan Seifert commented on SLING-12266: i tested both PRs locally with the unit tests from aem-mock (which runs all tests on all resource resolver types), and it again was a considerable improvement in run time (from 45s to 32s on my machine). i did not see any difference with and without [https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/pull/12/commits/11de72022bf969e7253c6f6725b528963d3638db,] so i recommend to remove this optimization again - it seems oak is smart enough to not re-register the CND files again or it does not make a difference. concerning the latest jackrabbit/oak versions: we have an eye on this, but as described in SLING-12208 we have to maintain a wide range of compatibility for project contexts these mocks are used. esp. if used in AEM 6.x context, a very old oak version is still in use, and we have to support this. that's why we cannot always update to latest and greatest in the mocks here. > Cache initial repository state to improve JCR_OAK performance > - > > Key: SLING-12266 > URL: https://issues.apache.org/jira/browse/SLING-12266 > Project: Sling > Issue Type: Improvement > Components: Testing >Affects Versions: Testing Sling Mock 3.4.18 >Reporter: Csaba Varga >Assignee: Stefan Seifert >Priority: Minor > > A lot of effort goes into preparing an Oak Mock repository from scratch: node > types need to be registered, indexes need to be created, and all this happens > over several commits. None of this work depends on the test case itself, so > it will always result in the exact same repository state. We could take the > root NodeState from the first repository we build, then build subsequent > repositories on top of it, avoiding most of the redundant work. Commits can > be relatively expensive even in memory, so each one we avoid can save a lot > of time in the long term. > > This would require extending the contract between Testing Sling Mock and the > ResourceResolverTypeAdapters, to add optional "make snapshot" and "build repo > from snapshot" operations. For adapters that don't support them, we would > keep rebuilding things from scratch. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12266) Cache initial repository state to improve JCR_OAK performance
[ https://issues.apache.org/jira/browse/SLING-12266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835756#comment-17835756 ] Stefan Seifert commented on SLING-12266: the approach looks good to me in general. it would be nice if there is a way to avoid code like [https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/pull/12/commits/11de72022bf969e7253c6f6725b528963d3638db] which seems to duplicate some logic from the Jcr class implementation. but i have too less insight there from an oak impl perspective. [~reschke] can you have a look at PR [https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/pull/12] as well from an oak perspective? > Cache initial repository state to improve JCR_OAK performance > - > > Key: SLING-12266 > URL: https://issues.apache.org/jira/browse/SLING-12266 > Project: Sling > Issue Type: Improvement > Components: Testing >Affects Versions: Testing Sling Mock 3.4.18 >Reporter: Csaba Varga >Priority: Minor > > A lot of effort goes into preparing an Oak Mock repository from scratch: node > types need to be registered, indexes need to be created, and all this happens > over several commits. None of this work depends on the test case itself, so > it will always result in the exact same repository state. We could take the > root NodeState from the first repository we build, then build subsequent > repositories on top of it, avoiding most of the redundant work. Commits can > be relatively expensive even in memory, so each one we avoid can save a lot > of time in the long term. > > This would require extending the contract between Testing Sling Mock and the > ResourceResolverTypeAdapters, to add optional "make snapshot" and "build repo > from snapshot" operations. For adapters that don't support them, we would > keep rebuilding things from scratch. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (SLING-12266) Cache initial repository state to improve JCR_OAK performance
[ https://issues.apache.org/jira/browse/SLING-12266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert reassigned SLING-12266: -- Assignee: Stefan Seifert > Cache initial repository state to improve JCR_OAK performance > - > > Key: SLING-12266 > URL: https://issues.apache.org/jira/browse/SLING-12266 > Project: Sling > Issue Type: Improvement > Components: Testing >Affects Versions: Testing Sling Mock 3.4.18 >Reporter: Csaba Varga >Assignee: Stefan Seifert >Priority: Minor > > A lot of effort goes into preparing an Oak Mock repository from scratch: node > types need to be registered, indexes need to be created, and all this happens > over several commits. None of this work depends on the test case itself, so > it will always result in the exact same repository state. We could take the > root NodeState from the first repository we build, then build subsequent > repositories on top of it, avoiding most of the redundant work. Commits can > be relatively expensive even in memory, so each one we avoid can save a lot > of time in the long term. > > This would require extending the contract between Testing Sling Mock and the > ResourceResolverTypeAdapters, to add optional "make snapshot" and "build repo > from snapshot" operations. For adapters that don't support them, we would > keep rebuilding things from scratch. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-12284) sling/jcr/osgi/resourceresolver-mock: Update to Parent 60, Java 11 Minimum Version
[ https://issues.apache.org/jira/browse/SLING-12284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert resolved SLING-12284. Resolution: Fixed logging-mock * [https://github.com/apache/sling-org-apache-sling-testing-logging-mock/commit/cb4e079f89240290e32ec0d2ba103be89707a33a] * [https://github.com/apache/sling-org-apache-sling-testing-logging-mock/commit/3ed3f3eb7fd4f9ea0910a7619d4c3a6f8dcf4cde] * [https://github.com/apache/sling-org-apache-sling-testing-logging-mock/commit/77933617b033b98ba983fa9e00bea5fea548ef3d] jcr-mock * [https://github.com/apache/sling-org-apache-sling-testing-jcr-mock/commit/74f6c497295699a66db3d6fd2f9147f8faa24404] * [https://github.com/apache/sling-org-apache-sling-testing-jcr-mock/commit/423f2856db8d03d5accb12dd3b55c5fc6311c020] * [https://github.com/apache/sling-org-apache-sling-testing-jcr-mock/commit/2b964f2b6e7db301aa51258deffa7af7f53a98e2] osgi-mock * [https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/commit/771ed600ac3347f8f0c563e10a06fd0ed73d2d1a] * [https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/commit/5cb642928aab2001b8fbfb326ea92b58f713b4de] * [https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/commit/dbc9d3051a741de52c64ea6c32bd00b883c8fdbb] resourceresolver-mock * [https://github.com/apache/sling-org-apache-sling-testing-resourceresolver-mock/commit/b86313a0fb75f067ddcddd5b184e032c17e27434] * [https://github.com/apache/sling-org-apache-sling-testing-resourceresolver-mock/commit/d4090be2060ec63d87f1a505b9ca5c0a1fc3] * [https://github.com/apache/sling-org-apache-sling-testing-resourceresolver-mock/commit/0f2acd051d0bf40139e19ea58787931c8b9bf02b] sling-mock * [https://github.com/apache/sling-org-apache-sling-testing-sling-mock/commit/bf72c05b952fc688442e0d0a3bc3c7ea2df3f478] * [https://github.com/apache/sling-org-apache-sling-testing-sling-mock/commit/74c1f1ec587abb9dcf8a115aa8fe4b5eee6b9f72] * [https://github.com/apache/sling-org-apache-sling-testing-sling-mock/commit/211ce26e26de49822fad6bad3ce6dd4941b80dd0] sling-mock-oak * [https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/commit/16c34e2aa6f8cbfb384ddb324d6b3a6bc51f48a4] * [https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/commit/61ee823f52beeca205edd2aafbf5b0f2779c6619] * [https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/commit/7998acc66ba183b371839f27f1a9cfaa46b4ea07] caconfig-mock-plugin * [https://github.com/apache/sling-org-apache-sling-testing-caconfig-mock-plugin/commit/fd5f9e100d7de2125a3a2731367d04d4d926b94e] * [https://github.com/apache/sling-org-apache-sling-testing-caconfig-mock-plugin/commit/1468f9ec381a74a2c4e59cda67e3e296210ede34] * [https://github.com/apache/sling-org-apache-sling-testing-caconfig-mock-plugin/commit/c3b5889cc26b0900baadb2cd4c350707d215ffa2] > sling/jcr/osgi/resourceresolver-mock: Update to Parent 60, Java 11 Minimum > Version > -- > > Key: SLING-12284 > URL: https://issues.apache.org/jira/browse/SLING-12284 > Project: Sling > Issue Type: Improvement > Components: Testing >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: Testing Logging Mock 2.1.0, Testing Sling Mock Oak > 3.2.0-1.44.0, Context-Aware Configuration Mock Plugin 1.6.0, Testing JCR Mock > 1.7.0, Testing OSGi Mock 3.5.0, Testing ResourceResolver Mock 1.5.0, Testing > Sling Mock 3.5.0 > > > update to parent 60, see also [https://cwiki.apache.org/confluence/x/SI75E] > this drops java 8 support, and instead supports java 11, 17, 21 - build is > done with java 17 > minimum java requirement for runtime is java 11 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-12265) Node type registration is inefficient during unit tests when using the JCR_OAK resolver type
[ https://issues.apache.org/jira/browse/SLING-12265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert resolved SLING-12265. Fix Version/s: Testing Sling Mock 3.5.0 Resolution: Fixed https://github.com/apache/sling-org-apache-sling-testing-sling-mock/commit/4ff35ad95143d85bc1f91888cd53a3f624f86e06 > Node type registration is inefficient during unit tests when using the > JCR_OAK resolver type > > > Key: SLING-12265 > URL: https://issues.apache.org/jira/browse/SLING-12265 > Project: Sling > Issue Type: Improvement > Components: Testing >Affects Versions: Testing Sling Mock 3.4.18 >Reporter: Csaba Varga >Assignee: Stefan Seifert >Priority: Minor > Labels: performance > Fix For: Testing Sling Mock 3.5.0 > > > I did some profiling on my company's slow-running unit tests today, and found > that 70+% of the CPU time is spent inside NodeTypeDefinitionScanner, more > specifically in the commit() call triggered by it. Our test classpath > includes AEM Mocks and the Cloud SDK, resulting in 30+ CND files being > detected, and as many commits done preparing the repository before each test. > (Slightly more, because some commits fail and get retried later.) > It should be possible to parse each CND into memory structures in a separate > pass, then create the node types all at once in a single commit. This > wouldn't just eliminate the extra commits, but would also remove the need to > retry, since all dependencies would also be provided in the same call. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12284) sling/jcr/osgi/resourceresolver-mock: Update to Parent 60, Java 11 Minimum Version
[ https://issues.apache.org/jira/browse/SLING-12284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert updated SLING-12284: --- Fix Version/s: Testing Logging Mock 2.1.0 Testing Sling Mock Oak 3.2.0-1.44.0 Context-Aware Configuration Mock Plugin 1.6.0 Testing JCR Mock 1.7.0 Testing OSGi Mock 3.5.0 Testing ResourceResolver Mock 1.5.0 Testing Sling Mock 3.5.0 > sling/jcr/osgi/resourceresolver-mock: Update to Parent 60, Java 11 Minimum > Version > -- > > Key: SLING-12284 > URL: https://issues.apache.org/jira/browse/SLING-12284 > Project: Sling > Issue Type: Improvement > Components: Testing >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: Testing Logging Mock 2.1.0, Testing Sling Mock Oak > 3.2.0-1.44.0, Context-Aware Configuration Mock Plugin 1.6.0, Testing JCR Mock > 1.7.0, Testing OSGi Mock 3.5.0, Testing ResourceResolver Mock 1.5.0, Testing > Sling Mock 3.5.0 > > > update to parent 60, see also [https://cwiki.apache.org/confluence/x/SI75E] > this drops java 8 support, and instead supports java 11, 17, 21 - build is > done with java 17 > minimum java requirement for runtime is java 11 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12284) sling/jcr/osgi/resourceresolver-mock: Update to Parent 60, Java 11 Minimum Version
Stefan Seifert created SLING-12284: -- Summary: sling/jcr/osgi/resourceresolver-mock: Update to Parent 60, Java 11 Minimum Version Key: SLING-12284 URL: https://issues.apache.org/jira/browse/SLING-12284 Project: Sling Issue Type: Improvement Components: Testing Reporter: Stefan Seifert Assignee: Stefan Seifert update to parent 60, see also [https://cwiki.apache.org/confluence/x/SI75E] this drops java 8 support, and instead supports java 11, 17, 21 - build is done with java 17 minimum java requirement for runtime is java 11 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12265) Node type registration is inefficient during unit tests when using the JCR_OAK resolver type
[ https://issues.apache.org/jira/browse/SLING-12265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835436#comment-17835436 ] Stefan Seifert commented on SLING-12265: thanks for the contribution! i've added comments in the PR. > Node type registration is inefficient during unit tests when using the > JCR_OAK resolver type > > > Key: SLING-12265 > URL: https://issues.apache.org/jira/browse/SLING-12265 > Project: Sling > Issue Type: Improvement > Components: Testing >Affects Versions: Testing Sling Mock 3.4.18 >Reporter: Csaba Varga >Assignee: Stefan Seifert >Priority: Minor > Labels: performance > > I did some profiling on my company's slow-running unit tests today, and found > that 70+% of the CPU time is spent inside NodeTypeDefinitionScanner, more > specifically in the commit() call triggered by it. Our test classpath > includes AEM Mocks and the Cloud SDK, resulting in 30+ CND files being > detected, and as many commits done preparing the repository before each test. > (Slightly more, because some commits fail and get retried later.) > It should be possible to parse each CND into memory structures in a separate > pass, then create the node types all at once in a single commit. This > wouldn't just eliminate the extra commits, but would also remove the need to > retry, since all dependencies would also be provided in the same call. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12266) Cache initial repository state to improve JCR_OAK performance
[ https://issues.apache.org/jira/browse/SLING-12266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835343#comment-17835343 ] Stefan Seifert commented on SLING-12266: sounds like an idea worth to experiment with - we have to make sure that still for each test run a completely clean repository is prepared. i have not much experience with the related details of the in-memory oak we are using. if you can come up with a PR with your idea i would be happy to check it further. > Cache initial repository state to improve JCR_OAK performance > - > > Key: SLING-12266 > URL: https://issues.apache.org/jira/browse/SLING-12266 > Project: Sling > Issue Type: Improvement > Components: Testing >Affects Versions: Testing Sling Mock 3.4.18 >Reporter: Csaba Varga >Priority: Minor > > A lot of effort goes into preparing an Oak Mock repository from scratch: node > types need to be registered, indexes need to be created, and all this happens > over several commits. None of this work depends on the test case itself, so > it will always result in the exact same repository state. We could take the > root NodeState from the first repository we build, then build subsequent > repositories on top of it, avoiding most of the redundant work. Commits can > be relatively expensive even in memory, so each one we avoid can save a lot > of time in the long term. > > This would require extending the contract between Testing Sling Mock and the > ResourceResolverTypeAdapters, to add optional "make snapshot" and "build repo > from snapshot" operations. For adapters that don't support them, we would > keep rebuilding things from scratch. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (SLING-12265) Node type registration is inefficient during unit tests when using the JCR_OAK resolver type
[ https://issues.apache.org/jira/browse/SLING-12265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert reassigned SLING-12265: -- Assignee: Stefan Seifert > Node type registration is inefficient during unit tests when using the > JCR_OAK resolver type > > > Key: SLING-12265 > URL: https://issues.apache.org/jira/browse/SLING-12265 > Project: Sling > Issue Type: Improvement > Components: Testing >Affects Versions: Testing Sling Mock 3.4.18 >Reporter: Csaba Varga >Assignee: Stefan Seifert >Priority: Minor > Labels: performance > > I did some profiling on my company's slow-running unit tests today, and found > that 70+% of the CPU time is spent inside NodeTypeDefinitionScanner, more > specifically in the commit() call triggered by it. Our test classpath > includes AEM Mocks and the Cloud SDK, resulting in 30+ CND files being > detected, and as many commits done preparing the repository before each test. > (Slightly more, because some commits fail and get retried later.) > It should be possible to parse each CND into memory structures in a separate > pass, then create the node types all at once in a single commit. This > wouldn't just eliminate the extra commits, but would also remove the need to > retry, since all dependencies would also be provided in the same call. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-12282) Content Parser: Update Dependencies to 2023
[ https://issues.apache.org/jira/browse/SLING-12282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert resolved SLING-12282. Fix Version/s: Content Parser Test Utilities 2.0.2 Content Parser JSON 2.1.0 Content Parser XML 2.0.2 Content Parser XML JCR 2.0.2 Resolution: Fixed * [https://github.com/apache/sling-org-apache-sling-contentparser-json/commit/4603719426ed0835622f8763f5e988e0f3204066] * [https://github.com/apache/sling-org-apache-sling-contentparser-testutils/commit/9f2285f0814829d7e46d7ae1e387a855a01e989d] * [https://github.com/apache/sling-org-apache-sling-contentparser-xml/commit/7481cad4a4ab0908e37698cacfb3cbe2603a0536] * [https://github.com/apache/sling-org-apache-sling-contentparser-xml-jcr/commit/7785f84968e7558fe12529d4afccb78d60e50932] > Content Parser: Update Dependencies to 2023 > --- > > Key: SLING-12282 > URL: https://issues.apache.org/jira/browse/SLING-12282 > Project: Sling > Issue Type: Improvement > Components: Content Parser >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: Content Parser Test Utilities 2.0.2, Content Parser JSON > 2.1.0, Content Parser XML 2.0.2, Content Parser XML JCR 2.0.2 > > > in line with and using the same concept of SLING-12208 update 3rdparty > dependencies to a newer version for content parser modules -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12282) Content Parser: Update Dependencies to 2023
Stefan Seifert created SLING-12282: -- Summary: Content Parser: Update Dependencies to 2023 Key: SLING-12282 URL: https://issues.apache.org/jira/browse/SLING-12282 Project: Sling Issue Type: Improvement Components: Content Parser Reporter: Stefan Seifert Assignee: Stefan Seifert in line with and using the same concept of SLING-12208 update 3rdparty dependencies to a newer version for content parser modules -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (SLING-12281) Content Parser: Update to Parent 60, Java 11 Minimum Version
[ https://issues.apache.org/jira/browse/SLING-12281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835317#comment-17835317 ] Stefan Seifert edited comment on SLING-12281 at 4/9/24 9:18 AM: api * [https://github.com/apache/sling-org-apache-sling-contentparser-api/commit/5da0a66e4bd1fb665372a4fb032a559d2ad8a395] * [https://github.com/apache/sling-org-apache-sling-contentparser-api/commit/93ca1c43db8fd67d6f6f7feccdabc73cb8bb40a9] * [https://github.com/apache/sling-org-apache-sling-contentparser-api/commit/bfa02530164493302ff3725d8c39178b8965a908] * [https://github.com/apache/sling-org-apache-sling-contentparser-api/commit/d94752766a39a89c1338ecf9fa94b86c71bf4772] testutils * [https://github.com/apache/sling-org-apache-sling-contentparser-testutils/commit/eab27e12d2859c6abe0081bbaf222120df6b398b] * [https://github.com/apache/sling-org-apache-sling-contentparser-testutils/commit/044f9aac4e8f29490137a88a94dff2b6bae8182c] * [https://github.com/apache/sling-org-apache-sling-contentparser-testutils/commit/619c56e5256ea6c8901ea25d2f6cd47c80289ab6] json * [https://github.com/apache/sling-org-apache-sling-contentparser-json/commit/003f277c5cbff1a9b1757b423a27e496b6313b6a] * [https://github.com/apache/sling-org-apache-sling-contentparser-json/commit/c44e65544895cb2c2076e7a0aeebbb0585382733] * [https://github.com/apache/sling-org-apache-sling-contentparser-json/commit/d1aa7a6b1908902bfe94f8f619a8a12cfa4b023d] * [https://github.com/apache/sling-org-apache-sling-contentparser-json/commit/f298b41a7aadf3eba985afec5adff413bb5843bc] xml * [https://github.com/apache/sling-org-apache-sling-contentparser-xml/commit/edc6f841e62a011d37f90f64a61650f9d51a0f42] * [https://github.com/apache/sling-org-apache-sling-contentparser-xml/commit/5af3f77f9eb497135a9cf641ef99f98e9c199986] * [https://github.com/apache/sling-org-apache-sling-contentparser-xml/commit/4ca3c865cdafa504b1f6de6759cfa90500a07a91] xml-jcr * [https://github.com/apache/sling-org-apache-sling-contentparser-xml-jcr/commit/692df61a55137e855406e2713bedf3e820599f66] * [https://github.com/apache/sling-org-apache-sling-contentparser-xml-jcr/commit/3b87b0e718eacdce1197bdb4f07e8160d0ec68b1] * [https://github.com/apache/sling-org-apache-sling-contentparser-xml-jcr/commit/60b907ee5a4956573bcda1508329c9b381d0fe72] was (Author: sseif...@pro-vision.de): api * [https://github.com/apache/sling-org-apache-sling-contentparser-api/commit/5da0a66e4bd1fb665372a4fb032a559d2ad8a395] * [https://github.com/apache/sling-org-apache-sling-contentparser-api/commit/93ca1c43db8fd67d6f6f7feccdabc73cb8bb40a9] * [https://github.com/apache/sling-org-apache-sling-contentparser-api/commit/bfa02530164493302ff3725d8c39178b8965a908] testutils * [https://github.com/apache/sling-org-apache-sling-contentparser-testutils/commit/eab27e12d2859c6abe0081bbaf222120df6b398b] * [https://github.com/apache/sling-org-apache-sling-contentparser-testutils/commit/044f9aac4e8f29490137a88a94dff2b6bae8182c] * [https://github.com/apache/sling-org-apache-sling-contentparser-testutils/commit/619c56e5256ea6c8901ea25d2f6cd47c80289ab6] json * [https://github.com/apache/sling-org-apache-sling-contentparser-json/commit/003f277c5cbff1a9b1757b423a27e496b6313b6a] * [https://github.com/apache/sling-org-apache-sling-contentparser-json/commit/c44e65544895cb2c2076e7a0aeebbb0585382733] * [https://github.com/apache/sling-org-apache-sling-contentparser-json/commit/d1aa7a6b1908902bfe94f8f619a8a12cfa4b023d] xml * [https://github.com/apache/sling-org-apache-sling-contentparser-xml/commit/edc6f841e62a011d37f90f64a61650f9d51a0f42] * [https://github.com/apache/sling-org-apache-sling-contentparser-xml/commit/5af3f77f9eb497135a9cf641ef99f98e9c199986] * [https://github.com/apache/sling-org-apache-sling-contentparser-xml/commit/4ca3c865cdafa504b1f6de6759cfa90500a07a91] xml-jcr * [https://github.com/apache/sling-org-apache-sling-contentparser-xml-jcr/commit/692df61a55137e855406e2713bedf3e820599f66] * [https://github.com/apache/sling-org-apache-sling-contentparser-xml-jcr/commit/3b87b0e718eacdce1197bdb4f07e8160d0ec68b1] * [https://github.com/apache/sling-org-apache-sling-contentparser-xml-jcr/commit/60b907ee5a4956573bcda1508329c9b381d0fe72] > Content Parser: Update to Parent 60, Java 11 Minimum Version > > > Key: SLING-12281 > URL: https://issues.apache.org/jira/browse/SLING-12281 > Project: Sling > Issue Type: Improvement > Components: Content Parser >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: Content Parser API 2.0.2, Content Parser Test Utilities > 2.0.2, Content Parser JSON 2.1.0, Content Parser XML 2.0.2, Content Parser > XML JCR 2.0.2 > > > update to parent 60,
[jira] [Resolved] (SLING-12281) Content Parser: Update to Parent 60, Java 11 Minimum Version
[ https://issues.apache.org/jira/browse/SLING-12281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert resolved SLING-12281. Resolution: Fixed api * [https://github.com/apache/sling-org-apache-sling-contentparser-api/commit/5da0a66e4bd1fb665372a4fb032a559d2ad8a395] * [https://github.com/apache/sling-org-apache-sling-contentparser-api/commit/93ca1c43db8fd67d6f6f7feccdabc73cb8bb40a9] * [https://github.com/apache/sling-org-apache-sling-contentparser-api/commit/bfa02530164493302ff3725d8c39178b8965a908] testutils * [https://github.com/apache/sling-org-apache-sling-contentparser-testutils/commit/eab27e12d2859c6abe0081bbaf222120df6b398b] * [https://github.com/apache/sling-org-apache-sling-contentparser-testutils/commit/044f9aac4e8f29490137a88a94dff2b6bae8182c] * [https://github.com/apache/sling-org-apache-sling-contentparser-testutils/commit/619c56e5256ea6c8901ea25d2f6cd47c80289ab6] json * [https://github.com/apache/sling-org-apache-sling-contentparser-json/commit/003f277c5cbff1a9b1757b423a27e496b6313b6a] * [https://github.com/apache/sling-org-apache-sling-contentparser-json/commit/c44e65544895cb2c2076e7a0aeebbb0585382733] * [https://github.com/apache/sling-org-apache-sling-contentparser-json/commit/d1aa7a6b1908902bfe94f8f619a8a12cfa4b023d] xml * [https://github.com/apache/sling-org-apache-sling-contentparser-xml/commit/edc6f841e62a011d37f90f64a61650f9d51a0f42] * [https://github.com/apache/sling-org-apache-sling-contentparser-xml/commit/5af3f77f9eb497135a9cf641ef99f98e9c199986] * [https://github.com/apache/sling-org-apache-sling-contentparser-xml/commit/4ca3c865cdafa504b1f6de6759cfa90500a07a91] xml-jcr * [https://github.com/apache/sling-org-apache-sling-contentparser-xml-jcr/commit/692df61a55137e855406e2713bedf3e820599f66] * [https://github.com/apache/sling-org-apache-sling-contentparser-xml-jcr/commit/3b87b0e718eacdce1197bdb4f07e8160d0ec68b1] * [https://github.com/apache/sling-org-apache-sling-contentparser-xml-jcr/commit/60b907ee5a4956573bcda1508329c9b381d0fe72] > Content Parser: Update to Parent 60, Java 11 Minimum Version > > > Key: SLING-12281 > URL: https://issues.apache.org/jira/browse/SLING-12281 > Project: Sling > Issue Type: Improvement > Components: Content Parser >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: Content Parser API 2.0.2, Content Parser Test Utilities > 2.0.2, Content Parser JSON 2.1.0, Content Parser XML 2.0.2, Content Parser > XML JCR 2.0.2 > > > update to parent 60, regarding [https://cwiki.apache.org/confluence/x/SI75E] > this drops java 8 support, and instead supports java 11, 17, 21 - build is > done with java 17 > minimum java requirement for runtime is java 11 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12281) Content Parser: Update to Parent 60, Java 11 Minimum Version
Stefan Seifert created SLING-12281: -- Summary: Content Parser: Update to Parent 60, Java 11 Minimum Version Key: SLING-12281 URL: https://issues.apache.org/jira/browse/SLING-12281 Project: Sling Issue Type: Improvement Components: Content Parser Reporter: Stefan Seifert Assignee: Stefan Seifert Fix For: Content Parser API 2.0.2, Content Parser Test Utilities 2.0.2, Content Parser JSON 2.1.0, Content Parser XML 2.0.2, Content Parser XML JCR 2.0.2 update to parent 60, regarding [https://cwiki.apache.org/confluence/x/SI75E] this drops java 8 support, and instead supports java 11, 17, 21 - build is done with java 17 minimum java requirement for runtime is java 11 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-12280) Migrate org.apache.sling.contentparser.json to jakarta.json
[ https://issues.apache.org/jira/browse/SLING-12280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert resolved SLING-12280. Resolution: Fixed https://github.com/apache/sling-org-apache-sling-contentparser-json/commit/b9589121fd01e644c55ac9aae69dfe32f6fa5969 > Migrate org.apache.sling.contentparser.json to jakarta.json > --- > > Key: SLING-12280 > URL: https://issues.apache.org/jira/browse/SLING-12280 > Project: Sling > Issue Type: Sub-task > Components: Content Parser >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: Content Parser JSON 2.1.0 > > > to support johnzon 2.0 in unit tests with sling-mocks, we need to switch to > jakarta.json for the JSON content parser as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12280) Migrate org.apache.sling.contentparser.json to jakarta.json
Stefan Seifert created SLING-12280: -- Summary: Migrate org.apache.sling.contentparser.json to jakarta.json Key: SLING-12280 URL: https://issues.apache.org/jira/browse/SLING-12280 Project: Sling Issue Type: Sub-task Components: Content Parser Reporter: Stefan Seifert Assignee: Stefan Seifert Fix For: Content Parser JSON 2.1.0 to support johnzon 2.0 in unit tests with sling-mocks, we need to switch to jakarta.json for the JSON content parser as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12234) Commons Log builds fail on Windows
[
https://issues.apache.org/jira/browse/SLING-12234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827913#comment-17827913
]
Stefan Seifert commented on SLING-12234:
{quote}[~sseifert], Can you run the build successful on your local Windows?
{quote}
i can reproduce the problem on my windows machine. i started a bit debugging,
but did not found the root case with the temp file creation fails in
ITPackaingData:
{noformat}
java.io.IOException: Zugriff verweigert
at java.base/java.io.WinNTFileSystem.createFileExclusively(Native Method)
at java.base/java.io.File.createTempFile(File.java:2129)
at java.base/java.io.File.createTempFile(File.java:2175)
at
org.ops4j.pax.tinybundles.core.intern.BndBuilder.sink(BndBuilder.java:127)
at
org.ops4j.pax.tinybundles.core.intern.BndBuilder.createBundle(BndBuilder.java:100)
at
org.ops4j.pax.tinybundles.core.intern.BndBuilder.wrapWithBnd(BndBuilder.java:76)
at
org.ops4j.pax.tinybundles.core.intern.BndBuilder.build(BndBuilder.java:68)
at
org.ops4j.pax.tinybundles.core.intern.TinyBundleImpl.build(TinyBundleImpl.java:206)
at
org.apache.sling.commons.log.logback.integration.PackagingDataTestUtil.createTestBundle(PackagingDataTestUtil.java:59)
at
org.apache.sling.commons.log.logback.integration.ITPackagingData.packageDataWorking(ITPackagingData.java:148)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runLeafWithRetry(ContainerTestRunner.java:97)
at
org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChildWithRetry(ContainerTestRunner.java:84)
at
org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:75)
at
org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:43)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
at
org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.invokeViaJUnit(JUnitProbeInvoker.java:124)
at
org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.findAndInvoke(JUnitProbeInvoker.java:97)
at
org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.call(JUnitProbeInvoker.java:73)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.invokeMethodOnService(RemoteFrameworkImpl.java:435)
at
org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.invokeMethodOnService(RemoteFrameworkImpl.java:408)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:359)
at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200)
at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at
java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:562)
at
[jira] [Commented] (SLING-12250) Adding Resource with sling:vanityPath set causes mismatch when resolving vanity URL (timing issue)
[ https://issues.apache.org/jira/browse/SLING-12250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817033#comment-17817033 ] Stefan Seifert commented on SLING-12250: the initializing that part of sling resource resolver which also interprets the vanity paths changed a couple of times of the last years for performance and stability improvements, and is done mostly async in the latest release. as using vanity paths in unit test is more an edge case, it makes no sense to automatically wait for it's completion for all tests. if you have a test that really needs vanity paths, probably use libraries like [https://github.com/awaitility/awaitility] to wait until it's available and then proceed with the tests. > Adding Resource with sling:vanityPath set causes mismatch when resolving > vanity URL (timing issue) > -- > > Key: SLING-12250 > URL: https://issues.apache.org/jira/browse/SLING-12250 > Project: Sling > Issue Type: Bug > Components: Testing >Affects Versions: Testing Sling Mock 3.4.18 >Reporter: Henry Kuijpers >Priority: Major > > It could happen that a Resource containing sling:vanityPath is added and then > resolved, but the Resource did not end up yet in the vanity logic. > Observed with JCR_OAK mock context. > Adding Thread.sleep(1000) fixes the issue, but it's of course not a very good > solution. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12208) sling/jcr/osgi/resourceresolver-mock: Update Dependencies to 2023
[ https://issues.apache.org/jira/browse/SLING-12208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-12208. -- > sling/jcr/osgi/resourceresolver-mock: Update Dependencies to 2023 > - > > Key: SLING-12208 > URL: https://issues.apache.org/jira/browse/SLING-12208 > Project: Sling > Issue Type: Improvement > Components: Testing >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: Testing JCR Mock 1.6.14, Testing Sling Mock Oak > 3.1.12-1.44.0, Testing ResourceResolver Mock 1.4.6, Testing OSGi Mock 3.4.2, > Testing Sling Mock 3.4.18 > > > every 1-2 years we update the dependencies of sling-mock and related mock > modules to a new "baseline" of dependencies. as sling-mock is used in a lot > of user projects with very different context (applications, deployment > target) we try to be as backwards-compatible as possible but dropping out > older versions from time to time. > the baseline we target for this ticket is: > [https://repo1.maven.org/maven2/io/wcm/maven/io.wcm.maven.aem-dependencies/6.5.17.0001/io.wcm.maven.aem-dependencies-6.5.17.0001.pom] > several dependencies from this POM esp. from Sling and Oak are not the latest > version from mid 2023, but it's a consistent baseline that is still used in a > lot of projects. > the goal is to stick to this baseline for the next 1-2 years and only deviate > from it with a good reason. such a reason might be security warnings in > artifact scanners - but only if it deviates not too much or in a potential > risky way from this baseline. > the goal is that all mock code that is written sticks to this baseline. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-12208) sling/jcr/osgi/resourceresolver-mock: Update Dependencies to 2023
[ https://issues.apache.org/jira/browse/SLING-12208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert resolved SLING-12208. Resolution: Fixed * [https://github.com/apache/sling-org-apache-sling-testing-jcr-mock/commit/c9cf4bc35580394dcd2327cc25a3baf479647de3] * [https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/commit/2ff8736b466ef13c449adb0bb3df125cd9430e63] * [https://github.com/apache/sling-org-apache-sling-testing-resourceresolver-mock/commit/34db5a5a8ad48adb7e041a135af6cc239cd65fe6] * [https://github.com/apache/sling-org-apache-sling-testing-sling-mock/commit/39a864df8893025de7db92cc55528d0fd0fda160] * [https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/commit/83747eff96ad0804e5b772257edeb010317a8841] > sling/jcr/osgi/resourceresolver-mock: Update Dependencies to 2023 > - > > Key: SLING-12208 > URL: https://issues.apache.org/jira/browse/SLING-12208 > Project: Sling > Issue Type: Improvement > Components: Testing >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: Testing Sling Mock Oak 3.1.12-1.44.0, Testing > ResourceResolver Mock 1.4.6, Testing OSGi Mock 3.4.2, Testing Sling Mock > 3.4.18, Testing JCR Mock 1.6.14 > > > every 1-2 years we update the dependencies of sling-mock and related mock > modules to a new "baseline" of dependencies. as sling-mock is used in a lot > of user projects with very different context (applications, deployment > target) we try to be as backwards-compatible as possible but dropping out > older versions from time to time. > the baseline we target for this ticket is: > [https://repo1.maven.org/maven2/io/wcm/maven/io.wcm.maven.aem-dependencies/6.5.17.0001/io.wcm.maven.aem-dependencies-6.5.17.0001.pom] > several dependencies from this POM esp. from Sling and Oak are not the latest > version from mid 2023, but it's a consistent baseline that is still used in a > lot of projects. > the goal is to stick to this baseline for the next 1-2 years and only deviate > from it with a good reason. such a reason might be security warnings in > artifact scanners - but only if it deviates not too much or in a potential > risky way from this baseline. > the goal is that all mock code that is written sticks to this baseline. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12208) sling/jcr/osgi/resourceresolver-mock: Update Dependencies to 2023
Stefan Seifert created SLING-12208: -- Summary: sling/jcr/osgi/resourceresolver-mock: Update Dependencies to 2023 Key: SLING-12208 URL: https://issues.apache.org/jira/browse/SLING-12208 Project: Sling Issue Type: Improvement Components: Testing Reporter: Stefan Seifert Assignee: Stefan Seifert Fix For: Testing Sling Mock Oak 3.1.12-1.44.0, Testing ResourceResolver Mock 1.4.6, Testing OSGi Mock 3.4.2, Testing Sling Mock 3.4.18, Testing JCR Mock 1.6.14 every 1-2 years we update the dependencies of sling-mock and related mock modules to a new "baseline" of dependencies. as sling-mock is used in a lot of user projects with very different context (applications, deployment target) we try to be as backwards-compatible as possible but dropping out older versions from time to time. the baseline we target for this ticket is: [https://repo1.maven.org/maven2/io/wcm/maven/io.wcm.maven.aem-dependencies/6.5.17.0001/io.wcm.maven.aem-dependencies-6.5.17.0001.pom] several dependencies from this POM esp. from Sling and Oak are not the latest version from mid 2023, but it's a consistent baseline that is still used in a lot of projects. the goal is to stick to this baseline for the next 1-2 years and only deviate from it with a good reason. such a reason might be security warnings in artifact scanners - but only if it deviates not too much or in a potential risky way from this baseline. the goal is that all mock code that is written sticks to this baseline. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12192) caconfig-mock-plugin: Fix nested config path building when writing config with custom persistence strategies
[ https://issues.apache.org/jira/browse/SLING-12192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-12192. -- > caconfig-mock-plugin: Fix nested config path building when writing config > with custom persistence strategies > > > Key: SLING-12192 > URL: https://issues.apache.org/jira/browse/SLING-12192 > Project: Sling > Issue Type: Bug > Components: Testing >Affects Versions: Context-Aware Configuration Mock Plugin 1.5.2 >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: Context-Aware Configuration Mock Plugin 1.5.4 > > > as reported in https://github.com/wcm-io/io.wcm.testing.aem-mock/issues/25 > there is currently an issue when custom persistence strategies are in place: > nested configurations may be written in invalid paths, resulting in not found > when reading the configuration again. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12191) caconfig-mock-plugin: Update to Parent 52
[ https://issues.apache.org/jira/browse/SLING-12191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-12191. -- > caconfig-mock-plugin: Update to Parent 52 > - > > Key: SLING-12191 > URL: https://issues.apache.org/jira/browse/SLING-12191 > Project: Sling > Issue Type: Improvement > Components: Testing >Affects Versions: Context-Aware Configuration Mock Plugin 1.5.2 >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Minor > Fix For: Context-Aware Configuration Mock Plugin 1.5.4 > > > update to latest parent -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12187) sling-mock: Make compatbile with Sling XSS 2.4.0
[ https://issues.apache.org/jira/browse/SLING-12187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-12187. -- > sling-mock: Make compatbile with Sling XSS 2.4.0 > > > Key: SLING-12187 > URL: https://issues.apache.org/jira/browse/SLING-12187 > Project: Sling > Issue Type: Improvement > Components: Testing >Affects Versions: Testing Sling Mock 3.4.14 >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: Testing Sling Mock 3.4.16 > > > we need to update the managed dependencies to be compatible with the changes > from Sling XSS 2.4.0. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[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=17795389#comment-17795389
]
Stefan Seifert commented on SLING-12197:
following my example from above, after deployment of
[^io.wcm.handler.link-apps-1.10.2-cp2fm-converted.zip], the following folders
and node types exist:
* {{/apps}}: {{sling:Folder}} (already existed)
* {{/apps/wcm-io}}: {{sling:Folder}} (automatically created, outside path in
filter.xml)
* {{/apps/wcm-io/handler}}: {{sling:Folder}} (automatically created, outside
path in filter.xml)
* {{/apps/wcm-io/handler/link}}: {{nt:folder}} (automatically created, toplevel
path defined in filter.xml, no {{.content.xml}} exists)
* all folders below {{/apps/wcm-io/handler/link}} are using {{nt:folder}} as
well
i do not understand why {{sling:Folder}} is used for the first two created
hierarchy nodes (following the parent folder), and then it switches to
{{nt:folder}} further down in the hierarchy. should not be the case according
to
[https://jackrabbit.apache.org/filevault/filter.html#Uncovered_ancestor_nodes]?
> 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.6
>
> 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] [Comment Edited] (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=17795349#comment-17795349
]
Stefan Seifert edited comment on SLING-12197 at 12/11/23 1:13 PM:
--
scenario to reproduce the problem:
* the bundle
https://repo1.maven.org/maven2/io/wcm/io.wcm.handler.link/1.10.2/io.wcm.handler.link-1.10.2.jar
contains Sling-Initial-Content, and a folder
{{/apps/wcm-io/handler/link/components/global/include}} with three sub nodes
with {{nt:unstructured}} node type, represented as three separate JSON files
* the sample project https://github.com/wcm-io/aem-guides-wknd-wcmio builds an
"all" content package including (amongst others) this bundle
* if the "all" content package is transformed using cpconverter 1.3.4, the
resulting content package is
[^io.wcm.handler.link-apps-1.10.2-cp2fm-converted.zip]
* if the resulting content package is deployed, the folder
{{/apps/wcm-io/handler/link/components/global/include}} remains empty because
the three nodes could not be extracted, error message:
{noformat}
11.12.2023 13:57:58.295 *WARN* [qtp22494311-117]
org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter Error during processing
of /apps/wcm-io/handler/link/components/global/include/redirectStatus:
javax.jcr.nodetype.ConstraintViolationException: No matching node definition
found for redirectStatus, skip node due to import mode UPDATE
11.12.2023 13:57:58.296 *WARN* [qtp22494311-117]
org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter Error during processing
of /apps/wcm-io/handler/link/components/global/include/linkRefTab:
javax.jcr.nodetype.ConstraintViolationException: No matching node definition
found for linkRefTab, skip node due to import mode UPDATE
11.12.2023 13:57:58.296 *WARN* [qtp22494311-117]
org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter Error during processing
of /apps/wcm-io/handler/link/components/global/include/linkRefNoTitleTab:
javax.jcr.nodetype.ConstraintViolationException: No matching node definition
found for linkRefNoTitleTab, skip node due to import mode UPDATE
{noformat}
was (Author: sseif...@pro-vision.de):
scenario to reproduce the problem:
* the bundle
https://repo1.maven.org/maven2/io/wcm/io.wcm.handler.link/1.10.2/io.wcm.handler.link-1.10.2.jar
contains Sling-Initial-Content, and a folder
{{/apps/wcm-io/handler/link/components/global/include}} with three sub nodes
with {{nt:unstructured}} node type, represented as three separate JSON files
* the sample project https://github.com/wcm-io/aem-guides-wknd-wcmio builds an
"all" content package including (amongst others) this bundle
* fit the "all" content package is transformed using cpconverter 1.3.4, the
resulting content package is
[^io.wcm.handler.link-apps-1.10.2-cp2fm-converted.zip]
* if the resulting content package is deployed, the folder
{{/apps/wcm-io/handler/link/components/global/include}} remains empty because
the three nodes could not be extracted, error message:
{noformat}
11.12.2023 13:57:58.295 *WARN* [qtp22494311-117]
org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter Error during processing
of /apps/wcm-io/handler/link/components/global/include/redirectStatus:
javax.jcr.nodetype.ConstraintViolationException: No matching node definition
found for redirectStatus, skip node due to import mode UPDATE
11.12.2023 13:57:58.296 *WARN* [qtp22494311-117]
org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter Error during processing
of /apps/wcm-io/handler/link/components/global/include/linkRefTab:
javax.jcr.nodetype.ConstraintViolationException: No matching node definition
found for linkRefTab, skip node due to import mode UPDATE
11.12.2023 13:57:58.296 *WARN* [qtp22494311-117]
org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter Error during processing
of /apps/wcm-io/handler/link/components/global/include/linkRefNoTitleTab:
javax.jcr.nodetype.ConstraintViolationException: No matching node definition
found for linkRefNoTitleTab, skip node due to import mode UPDATE
{noformat}
> 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.6
>
> 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
[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=17795351#comment-17795351
]
Stefan Seifert commented on SLING-12197:
at wcm.io, we implemented a similar tooling to transform Sling-Initial-Content
to content packages:
[https://github.com/wcm-io/io.wcm.maven.plugins.sling-initial-content-transform-maven-plugin]
the content package produced by this tool is not affected by the problem,
because it creates a dedicated {{.content.xml}} for each folder as well,
defining the {{sling:Folder}} node type. should we follow the same approach for
cpconverter as well?
[~kwin] [~rombert] WDYT?
> 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.6
>
> 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] [Updated] (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:all-tabpanel
]
Stefan Seifert updated SLING-12197:
---
Attachment: io.wcm.handler.link-apps-1.10.2-cp2fm-converted.zip
> 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.6
>
> 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-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=17795349#comment-17795349
]
Stefan Seifert commented on SLING-12197:
scenario to reproduce the problem:
* the bundle
https://repo1.maven.org/maven2/io/wcm/io.wcm.handler.link/1.10.2/io.wcm.handler.link-1.10.2.jar
contains Sling-Initial-Content, and a folder
{{/apps/wcm-io/handler/link/components/global/include}} with three sub nodes
with {{nt:unstructured}} node type, represented as three separate JSON files
* the sample project https://github.com/wcm-io/aem-guides-wknd-wcmio builds an
"all" content package including (amongst others) this bundle
* fit the "all" content package is transformed using cpconverter 1.3.4, the
resulting content package is
[^io.wcm.handler.link-apps-1.10.2-cp2fm-converted.zip]
* if the resulting content package is deployed, the folder
{{/apps/wcm-io/handler/link/components/global/include}} remains empty because
the three nodes could not be extracted, error message:
{noformat}
11.12.2023 13:57:58.295 *WARN* [qtp22494311-117]
org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter Error during processing
of /apps/wcm-io/handler/link/components/global/include/redirectStatus:
javax.jcr.nodetype.ConstraintViolationException: No matching node definition
found for redirectStatus, skip node due to import mode UPDATE
11.12.2023 13:57:58.296 *WARN* [qtp22494311-117]
org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter Error during processing
of /apps/wcm-io/handler/link/components/global/include/linkRefTab:
javax.jcr.nodetype.ConstraintViolationException: No matching node definition
found for linkRefTab, skip node due to import mode UPDATE
11.12.2023 13:57:58.296 *WARN* [qtp22494311-117]
org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter Error during processing
of /apps/wcm-io/handler/link/components/global/include/linkRefNoTitleTab:
javax.jcr.nodetype.ConstraintViolationException: No matching node definition
found for linkRefNoTitleTab, skip node due to import mode UPDATE
{noformat}
> 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.6
>
>
> 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] [Created] (SLING-12197) cpconverter: Sling-Initial-Content directories created as nt:folder instead of sling:Folder
Stefan Seifert created SLING-12197:
--
Summary: 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
Fix For: Content-Package to Feature Model Converter 1.3.6
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] [Resolved] (SLING-12192) caconfig-mock-plugin: Fix nested config path building when writing config with custom persistence strategies
[ https://issues.apache.org/jira/browse/SLING-12192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert resolved SLING-12192. Resolution: Fixed https://github.com/apache/sling-org-apache-sling-testing-caconfig-mock-plugin/commit/ee86a7f1c858af337b06b086473462ea9b283b7d > caconfig-mock-plugin: Fix nested config path building when writing config > with custom persistence strategies > > > Key: SLING-12192 > URL: https://issues.apache.org/jira/browse/SLING-12192 > Project: Sling > Issue Type: Bug > Components: Testing >Affects Versions: Context-Aware Configuration Mock Plugin 1.5.2 >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: Context-Aware Configuration Mock Plugin 1.5.4 > > > as reported in https://github.com/wcm-io/io.wcm.testing.aem-mock/issues/25 > there is currently an issue when custom persistence strategies are in place: > nested configurations may be written in invalid paths, resulting in not found > when reading the configuration again. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12192) caconfig-mock-plugin: Fix nested config path building when writing config with custom persistence strategies
Stefan Seifert created SLING-12192: -- Summary: caconfig-mock-plugin: Fix nested config path building when writing config with custom persistence strategies Key: SLING-12192 URL: https://issues.apache.org/jira/browse/SLING-12192 Project: Sling Issue Type: Bug Components: Testing Affects Versions: Context-Aware Configuration Mock Plugin 1.5.2 Reporter: Stefan Seifert Assignee: Stefan Seifert Fix For: Context-Aware Configuration Mock Plugin 1.5.4 as reported in https://github.com/wcm-io/io.wcm.testing.aem-mock/issues/25 there is currently an issue when custom persistence strategies are in place: nested configurations may be written in invalid paths, resulting in not found when reading the configuration again. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-12191) caconfig-mock-plugin: Update to Parent 52
[ https://issues.apache.org/jira/browse/SLING-12191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert resolved SLING-12191. Resolution: Fixed https://github.com/apache/sling-org-apache-sling-testing-caconfig-mock-plugin/commit/5d9af75ba47cb35c9e201ebcf1575df9e3de8116 > caconfig-mock-plugin: Update to Parent 52 > - > > Key: SLING-12191 > URL: https://issues.apache.org/jira/browse/SLING-12191 > Project: Sling > Issue Type: Improvement > Components: Testing >Affects Versions: Context-Aware Configuration Mock Plugin 1.5.2 >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Minor > Fix For: Context-Aware Configuration Mock Plugin 1.5.4 > > > update to latest parent -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12191) caconfig-mock-plugin: Update to Parent 52
Stefan Seifert created SLING-12191: -- Summary: caconfig-mock-plugin: Update to Parent 52 Key: SLING-12191 URL: https://issues.apache.org/jira/browse/SLING-12191 Project: Sling Issue Type: Improvement Components: Testing Affects Versions: Context-Aware Configuration Mock Plugin 1.5.2 Reporter: Stefan Seifert Assignee: Stefan Seifert Fix For: Context-Aware Configuration Mock Plugin 1.5.4 update to latest parent -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-12187) sling-mock: Make compatbile with Sling XSS 2.4.0
[ https://issues.apache.org/jira/browse/SLING-12187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert resolved SLING-12187. Resolution: Fixed https://github.com/apache/sling-org-apache-sling-testing-sling-mock/commit/de627616b605c2a41d5f28ec1c7c348f846dcd4b > sling-mock: Make compatbile with Sling XSS 2.4.0 > > > Key: SLING-12187 > URL: https://issues.apache.org/jira/browse/SLING-12187 > Project: Sling > Issue Type: Improvement > Components: Testing >Affects Versions: Testing Sling Mock 3.4.14 >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: Testing Sling Mock 3.4.16 > > > we need to update the managed dependencies to be compatible with the changes > from Sling XSS 2.4.0. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12187) sling-mock: Make compatbile with Sling XSS 2.4.0
Stefan Seifert created SLING-12187: -- Summary: sling-mock: Make compatbile with Sling XSS 2.4.0 Key: SLING-12187 URL: https://issues.apache.org/jira/browse/SLING-12187 Project: Sling Issue Type: Improvement Components: Testing Affects Versions: Testing Sling Mock 3.4.14 Reporter: Stefan Seifert Assignee: Stefan Seifert Fix For: Testing Sling Mock 3.4.16 we need to update the managed dependencies to be compatible with the changes from Sling XSS 2.4.0. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12161) sling-org-apache-sling-testing-sling-mock: update to latest Oak releases
[ https://issues.apache.org/jira/browse/SLING-12161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17788346#comment-17788346 ] Stefan Seifert commented on SLING-12161: by design we do not use the latest dependencies in sling-mock. sling-mock lives inside test classpath of the maven projects it is used, and mostly inherits the dependencies defined within those projects. so we keep the dependencies older (but in a consistent state, currently from ~2020) by design to be as compatible as possible with most projects. maybe we are doing a general update to ~2022 next year. > sling-org-apache-sling-testing-sling-mock: update to latest Oak releases > > > Key: SLING-12161 > URL: https://issues.apache.org/jira/browse/SLING-12161 > Project: Sling > Issue Type: Task > Components: Testing >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > > sling-org-apache-sling-testing-sling-mock currently uses Oak 1.22.5; it > should use the current maintenance release 1.22.17. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12144) Bump JUnit, Mockito, Commons Lang dependencies to latest in sling/osgi/jcr/resourceresolver-mock
[ https://issues.apache.org/jira/browse/SLING-12144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-12144. -- > Bump JUnit, Mockito, Commons Lang dependencies to latest in > sling/osgi/jcr/resourceresolver-mock > > > Key: SLING-12144 > URL: https://issues.apache.org/jira/browse/SLING-12144 > Project: Sling > Issue Type: Task > Components: Testing >Reporter: Rob McDougall >Assignee: Stefan Seifert >Priority: Major > Fix For: Testing JCR Mock 1.6.12, Testing Sling Mock Oak > 3.1.12-1.44.0, Testing ResourceResolver Mock 1.4.6, Testing OSGi Mock 3.4.0, > Testing Sling Mock 3.4.16 > > > Bump dependencies: > Mockito: 4.7.0 -> 5.7.0 > commons-lang 2.6 -> commons-lang3 3.13.0 > -commons-io 2.11.0 -> 2.13.0- > -commons-collectios4 4.2 -> 4.4- > JUnit5 5.2.0 -> 5.10.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-11916) osgi-mock: MockEventAdminTest.testPostEvents times out on Jenkins/Windows
[
https://issues.apache.org/jira/browse/SLING-11916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert closed SLING-11916.
--
> osgi-mock: MockEventAdminTest.testPostEvents times out on Jenkins/Windows
> -
>
> Key: SLING-11916
> URL: https://issues.apache.org/jira/browse/SLING-11916
> Project: Sling
> Issue Type: Bug
> Components: Testing
>Reporter: Robert Munteanu
>Assignee: Stefan Seifert
>Priority: Major
> Fix For: Testing OSGi Mock 3.4.0
>
>
> The error is
>
> {noformat}
> [ERROR] org.apache.sling.testing.mock.osgi.MockEventAdminTest.testPostEvents
> Time elapsed: 3.02 s <<< ERROR!
> org.junit.runners.model.TestTimedOutException: test timed out after 3000
> milliseconds
> {noformat}
> and seems to affect both Java 11 and 17.
> https://ci-builds.apache.org/blue/organizations/jenkins/Sling%2Fmodules%2Fsling-org-apache-sling-testing-osgi-mock/detail/PR-27/1/pipeline
> (Java 11, Windows)
> https://ci-builds.apache.org/blue/organizations/jenkins/Sling%2Fmodules%2Fsling-org-apache-sling-testing-osgi-mock/detail/master/229/pipeline
> (Java 17, Windows)
> https://ci-builds.apache.org/blue/organizations/jenkins/Sling%2Fmodules%2Fsling-org-apache-sling-testing-osgi-mock/detail/master/228/pipeline
> (Java 17, Windows)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SLING-12104) OSGi Mock - Service Registration Designate OCD default empty property is ignored, which leads to NPE
[
https://issues.apache.org/jira/browse/SLING-12104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert closed SLING-12104.
--
> OSGi Mock - Service Registration Designate OCD default empty property is
> ignored, which leads to NPE
>
>
> Key: SLING-12104
> URL: https://issues.apache.org/jira/browse/SLING-12104
> Project: Sling
> Issue Type: Bug
> Components: Testing
>Affects Versions: Testing OSGi Mock 3.3.10
>Reporter: Robin Brouns
>Assignee: Stefan Seifert
>Priority: Major
> Fix For: Testing OSGi Mock 3.4.0
>
>
> Considering the following sample Class:
> {code:java}
> package com.sample.website.job;
> import org.apache.commons.lang3.StringUtils;
> import org.apache.jackrabbit.oak.commons.PathUtils;
> import org.osgi.service.component.annotations.Activate;
> import org.osgi.service.component.annotations.Component;
> import org.osgi.service.component.annotations.Modified;
> import org.osgi.service.metatype.annotations.AttributeDefinition;
> import org.osgi.service.metatype.annotations.Designate;
> import org.osgi.service.metatype.annotations.ObjectClassDefinition;
> @Component(service = Runnable.class)
> @Designate(ocd = SampleJob.Config.class)
> public class SampleJob implements Runnable {
> private String sampleStringProperty;
> @Activate
> @Modified
> public void update(final Config configuration) {
> this.sampleStringProperty = configuration.sampleStringProperty();
> }
> @Override
> public void run() {
> if (PathUtils.isAbsolute(this.sampleStringProperty)) {
> // do something
> }
> }
> @ObjectClassDefinition(
> name = "Sample Configuration",
> description = "Sample Configuration Description"
> )
> @interface Config {
> @AttributeDefinition(
> name = "Sample String Property",
> description = "Sample String Property"
> )
> String sampleStringProperty() default StringUtils.EMPTY;
> }
> } {code}
> When I try to test this class with the default OSGi configuration via AEM
> Mocks:
> {code:java}
> final Runnable underTest =
> aemContext.registerInjectActivateService(SampleJob.class); {code}
> building this class leads to the following SCR definition:
> {code:java}
>
> http://www.osgi.org/xmlns/scr/v1.3.0;
> name="com.sample.website.job.SampleJob" activate="update" modified="update">
>
>
>
>
>
> {code}
> the *default* value of *updateImportPath* (an empty String) is *not* injected
> in the Configuration, but null is being used, which could lead to NPE.
> AEM Mocks uses OSGi Mocks and the following method is used to retrieve the
> *default* properties and values
> [https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/c55d97ba266e0630200fcbb378b3f102d2dfba90/core/src/main/java/org/apache/sling/testing/mock/osgi/OsgiMetadataUtil.java#L292C24-L292C46]
>
> But as you can see the XPath Query doesn't match with the SCR definition: the
> property exists with a *name* and there is a {*}value{*}, but it is empty, so:
> {code:java}
> String query = getComponentXPathQuery(clazz) + "/property[@name!='' and
> @value!='']"; {code}
> doesn't return the property and its default value and the result is a
> Configuration returning *null*
> The simple fix would be to check if the *value* attribute exists via the
> XPath Query in the SCR definition, instead of checking for a non empty value.
> A more robust fix would probably be to parse the OCD MetaType (if it is a OCD
> config) and use the *default* attribute which is present over there, see:
> {code:java}
>
> http://www.osgi.org/xmlns/metatype/v1.2.0;
> localization="OSGI-INF/l10n/com.sample.website.job.SampleJob$Config">
>
> description="Sample String Property" default=""/>
>
>
>
>
>
> {code}
> What do you think about this?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SLING-12038) [osgi-mock] add support for reified OSGi config annotations as test parameters
[ https://issues.apache.org/jira/browse/SLING-12038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-12038. -- > [osgi-mock] add support for reified OSGi config annotations as test parameters > -- > > Key: SLING-12038 > URL: https://issues.apache.org/jira/browse/SLING-12038 > Project: Sling > Issue Type: Improvement > Components: Testing >Affects Versions: Testing OSGi Mock 3.3.10 >Reporter: Mark Adamcin >Assignee: Stefan Seifert >Priority: Major > Labels: has-pr > Fix For: Testing OSGi Mock 3.4.0 > > > This PR adds a JUnit 5 extension and JUnit 4 rule for unit testing OSGi > components which leverage R7 spec configuration annotations and [Component > Property > Types|https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.component.html#service.component-component.property.types]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12157) [osgi-mock] late binding does not work for non-service DS components
[
https://issues.apache.org/jira/browse/SLING-12157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert closed SLING-12157.
--
> [osgi-mock] late binding does not work for non-service DS components
> -
>
> Key: SLING-12157
> URL: https://issues.apache.org/jira/browse/SLING-12157
> Project: Sling
> Issue Type: Improvement
> Components: Testing
>Affects Versions: Testing OSGi Mock 3.3.10
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Major
> Fix For: Testing OSGi Mock 3.4.0
>
>
> A DS component that is not a service can be "injected" and "activated", but
> if a service becomes available, that satisfies a dynamic reference, the
> "bind" method is not called. The same should be true for the "unbind"
> scenario.
> I observed this when I was registering a {{ResourceDecorator}} service in a
> test case, and it did not get bound by the
> {{ResourceResolverFactoryActivator}} that was already registered by the
> {{SlingContext}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-12157) [osgi-mock] late binding does not work for non-service DS components
[
https://issues.apache.org/jira/browse/SLING-12157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert updated SLING-12157:
---
Issue Type: Improvement (was: Task)
> [osgi-mock] late binding does not work for non-service DS components
> -
>
> Key: SLING-12157
> URL: https://issues.apache.org/jira/browse/SLING-12157
> Project: Sling
> Issue Type: Improvement
> Components: Testing
>Affects Versions: Testing OSGi Mock 3.3.10
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Major
> Fix For: Testing OSGi Mock 3.4.0
>
>
> A DS component that is not a service can be "injected" and "activated", but
> if a service becomes available, that satisfies a dynamic reference, the
> "bind" method is not called. The same should be true for the "unbind"
> scenario.
> I observed this when I was registering a {{ResourceDecorator}} service in a
> test case, and it did not get bound by the
> {{ResourceResolverFactoryActivator}} that was already registered by the
> {{SlingContext}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SLING-12144) Bump JUnit, Mockito, Commons Lang dependencies to latest in sling/osgi/jcr/resourceresolver-mock
[ https://issues.apache.org/jira/browse/SLING-12144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert resolved SLING-12144. Resolution: Fixed thanks! - it's all merged > Bump JUnit, Mockito, Commons Lang dependencies to latest in > sling/osgi/jcr/resourceresolver-mock > > > Key: SLING-12144 > URL: https://issues.apache.org/jira/browse/SLING-12144 > Project: Sling > Issue Type: Task > Components: Testing >Reporter: Rob McDougall >Assignee: Stefan Seifert >Priority: Major > Fix For: Testing JCR Mock 1.6.12, Testing Sling Mock Oak > 3.1.12-1.44.0, Testing ResourceResolver Mock 1.4.6, Testing OSGi Mock 3.4.0, > Testing Sling Mock 3.4.16 > > > Bump dependencies: > Mockito: 4.7.0 -> 5.7.0 > commons-lang 2.6 -> commons-lang3 3.13.0 > -commons-io 2.11.0 -> 2.13.0- > -commons-collectios4 4.2 -> 4.4- > JUnit5 5.2.0 -> 5.10.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12144) Bump JUnit, Mockito, Commons Lang dependencies to latest in sling/osgi/jcr/resourceresolver-mock
[ https://issues.apache.org/jira/browse/SLING-12144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert updated SLING-12144: --- Fix Version/s: Testing Sling Mock Oak 3.1.12-1.44.0 sling-mock-oak: * https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/commit/21edf41988f4e83bd4e07eb07e88846cbd97e319 > Bump JUnit, Mockito, Commons Lang dependencies to latest in > sling/osgi/jcr/resourceresolver-mock > > > Key: SLING-12144 > URL: https://issues.apache.org/jira/browse/SLING-12144 > Project: Sling > Issue Type: Task > Components: Testing >Reporter: Rob McDougall >Assignee: Stefan Seifert >Priority: Major > Fix For: Testing JCR Mock 1.6.12, Testing Sling Mock Oak > 3.1.12-1.44.0, Testing ResourceResolver Mock 1.4.6, Testing OSGi Mock 3.4.0, > Testing Sling Mock 3.4.16 > > > Bump dependencies: > Mockito: 4.7.0 -> 5.7.0 > commons-lang 2.6 -> commons-lang3 3.13.0 > -commons-io 2.11.0 -> 2.13.0- > -commons-collectios4 4.2 -> 4.4- > JUnit5 5.2.0 -> 5.10.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12144) Bump JUnit, Mockito, Commons Lang dependencies to latest in sling/osgi/jcr/resourceresolver-mock
[ https://issues.apache.org/jira/browse/SLING-12144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert updated SLING-12144: --- Summary: Bump JUnit, Mockito, Commons Lang dependencies to latest in sling/osgi/jcr/resourceresolver-mock (was: Bump non-sling dependencies to latest in org.apache.sling.testing.sling-mock) > Bump JUnit, Mockito, Commons Lang dependencies to latest in > sling/osgi/jcr/resourceresolver-mock > > > Key: SLING-12144 > URL: https://issues.apache.org/jira/browse/SLING-12144 > Project: Sling > Issue Type: Task > Components: Testing >Reporter: Rob McDougall >Assignee: Stefan Seifert >Priority: Major > Fix For: Testing JCR Mock 1.6.12, Testing ResourceResolver Mock > 1.4.6, Testing OSGi Mock 3.4.0, Testing Sling Mock 3.4.16 > > > Bump dependencies: > Mockito: 4.7.0 -> 5.7.0 > commons-lang 2.6 -> commons-lang3 3.13.0 > -commons-io 2.11.0 -> 2.13.0- > -commons-collectios4 4.2 -> 4.4- > JUnit5 5.2.0 -> 5.10.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12144) Bump non-sling dependencies to latest in org.apache.sling.testing.sling-mock
[ https://issues.apache.org/jira/browse/SLING-12144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17786815#comment-17786815 ] Stefan Seifert commented on SLING-12144: sling-mock: * https://github.com/apache/sling-org-apache-sling-testing-sling-mock/commit/ce3cd1deef88ec4f1688d216a6facce3a454485a * https://github.com/apache/sling-org-apache-sling-testing-sling-mock/commit/684042ede32e343c49b4e53d160edfac9b26610a > Bump non-sling dependencies to latest in org.apache.sling.testing.sling-mock > > > Key: SLING-12144 > URL: https://issues.apache.org/jira/browse/SLING-12144 > Project: Sling > Issue Type: Task > Components: Testing >Reporter: Rob McDougall >Assignee: Stefan Seifert >Priority: Major > Fix For: Testing JCR Mock 1.6.12, Testing ResourceResolver Mock > 1.4.6, Testing OSGi Mock 3.4.0, Testing Sling Mock 3.4.16 > > > Bump dependencies: > Mockito: 4.7.0 -> 5.7.0 > commons-lang 2.6 -> commons-lang3 3.13.0 > -commons-io 2.11.0 -> 2.13.0- > -commons-collectios4 4.2 -> 4.4- > JUnit5 5.2.0 -> 5.10.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12144) Bump non-sling dependencies to latest in org.apache.sling.testing.sling-mock
[ https://issues.apache.org/jira/browse/SLING-12144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17786809#comment-17786809 ] Stefan Seifert commented on SLING-12144: jcr-mock: * https://github.com/apache/sling-org-apache-sling-testing-jcr-mock/commit/9732bec7731fc928b8eae77a82237fe7438f4c3b * https://github.com/apache/sling-org-apache-sling-testing-jcr-mock/commit/2f55f9eadac4578bc2b47545df40ffca46d6243f resourceresolver-mock: * https://github.com/apache/sling-org-apache-sling-testing-resourceresolver-mock/commit/bddf46e2cfea6c8fd590824161a9e8efd4b46ae2 * https://github.com/apache/sling-org-apache-sling-testing-resourceresolver-mock/commit/0da2745c50860d387eb2f133b2fe29fb3a9c3b45 > Bump non-sling dependencies to latest in org.apache.sling.testing.sling-mock > > > Key: SLING-12144 > URL: https://issues.apache.org/jira/browse/SLING-12144 > Project: Sling > Issue Type: Task > Components: Testing >Reporter: Rob McDougall >Assignee: Stefan Seifert >Priority: Major > Fix For: Testing JCR Mock 1.6.12, Testing ResourceResolver Mock > 1.4.6, Testing OSGi Mock 3.4.0, Testing Sling Mock 3.4.16 > > > Bump dependencies: > Mockito: 4.7.0 -> 5.7.0 > commons-lang 2.6 -> commons-lang3 3.13.0 > -commons-io 2.11.0 -> 2.13.0- > -commons-collectios4 4.2 -> 4.4- > JUnit5 5.2.0 -> 5.10.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12144) Bump non-sling dependencies to latest in org.apache.sling.testing.sling-mock
[ https://issues.apache.org/jira/browse/SLING-12144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert updated SLING-12144: --- Description: Bump dependencies: Mockito: 4.7.0 -> 5.7.0 commons-lang 2.6 -> commons-lang3 3.13.0 -commons-io 2.11.0 -> 2.13.0- -commons-collectios4 4.2 -> 4.4- JUnit5 5.2.0 -> 5.10.1 was: Bump dependencies: Mockito: 4.7.0 -> 5.7.0 commons-lang 2.6 -> commons-lang3 3.13.0 commons-io 2.11.0 -> 2.13.0 commons-collectios4 4.2 -> 4.4 JUnit5 5.2.0 -> 5.10.1 > Bump non-sling dependencies to latest in org.apache.sling.testing.sling-mock > > > Key: SLING-12144 > URL: https://issues.apache.org/jira/browse/SLING-12144 > Project: Sling > Issue Type: Task > Components: Testing >Reporter: Rob McDougall >Assignee: Stefan Seifert >Priority: Major > Fix For: Testing JCR Mock 1.6.12, Testing ResourceResolver Mock > 1.4.6, Testing OSGi Mock 3.4.0, Testing Sling Mock 3.4.16 > > > Bump dependencies: > Mockito: 4.7.0 -> 5.7.0 > commons-lang 2.6 -> commons-lang3 3.13.0 > -commons-io 2.11.0 -> 2.13.0- > -commons-collectios4 4.2 -> 4.4- > JUnit5 5.2.0 -> 5.10.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12144) Bump non-sling dependencies to latest in org.apache.sling.testing.sling-mock
[ https://issues.apache.org/jira/browse/SLING-12144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert updated SLING-12144: --- Fix Version/s: Testing JCR Mock 1.6.12 Testing ResourceResolver Mock 1.4.6 Testing OSGi Mock 3.4.0 > Bump non-sling dependencies to latest in org.apache.sling.testing.sling-mock > > > Key: SLING-12144 > URL: https://issues.apache.org/jira/browse/SLING-12144 > Project: Sling > Issue Type: Task > Components: Testing >Reporter: Rob McDougall >Assignee: Stefan Seifert >Priority: Major > Fix For: Testing JCR Mock 1.6.12, Testing ResourceResolver Mock > 1.4.6, Testing OSGi Mock 3.4.0, Testing Sling Mock 3.4.16 > > > Bump dependencies: > Mockito: 4.7.0 -> 5.7.0 > commons-lang 2.6 -> commons-lang3 3.13.0 > commons-io 2.11.0 -> 2.13.0 > commons-collectios4 4.2 -> 4.4 > JUnit5 5.2.0 -> 5.10.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12144) Bump non-sling dependencies to latest in org.apache.sling.testing.sling-mock
[ https://issues.apache.org/jira/browse/SLING-12144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17786791#comment-17786791 ] Stefan Seifert commented on SLING-12144: osgi-mock: * https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/commit/72215949632c603fd4325af0712997646721e217 * https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/commit/9f7f1ce8b50dfb1bdeb1e001119c6035378a3a3a > Bump non-sling dependencies to latest in org.apache.sling.testing.sling-mock > > > Key: SLING-12144 > URL: https://issues.apache.org/jira/browse/SLING-12144 > Project: Sling > Issue Type: Task > Components: Testing >Reporter: Rob McDougall >Assignee: Stefan Seifert >Priority: Major > Fix For: Testing Sling Mock 3.4.16 > > > Bump dependencies: > Mockito: 4.7.0 -> 5.7.0 > commons-lang 2.6 -> commons-lang3 3.13.0 > commons-io 2.11.0 -> 2.13.0 > commons-collectios4 4.2 -> 4.4 > JUnit5 5.2.0 -> 5.10.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12157) [osgi-mock] late binding does not work for non-service DS components
[
https://issues.apache.org/jira/browse/SLING-12157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert updated SLING-12157:
---
Fix Version/s: Testing OSGi Mock 3.4.0
> [osgi-mock] late binding does not work for non-service DS components
> -
>
> Key: SLING-12157
> URL: https://issues.apache.org/jira/browse/SLING-12157
> Project: Sling
> Issue Type: Task
> Components: Testing
>Affects Versions: Testing OSGi Mock 3.3.10
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Major
> Fix For: Testing OSGi Mock 3.4.0
>
>
> A DS component that is not a service can be "injected" and "activated", but
> if a service becomes available, that satisfies a dynamic reference, the
> "bind" method is not called. The same should be true for the "unbind"
> scenario.
> I observed this when I was registering a {{ResourceDecorator}} service in a
> test case, and it did not get bound by the
> {{ResourceResolverFactoryActivator}} that was already registered by the
> {{SlingContext}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SLING-12157) [osgi-mock] late binding does not work for non-service DS components
[
https://issues.apache.org/jira/browse/SLING-12157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert resolved SLING-12157.
Resolution: Fixed
https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/commit/043ef6c471601944997a39019c432115952484f0
> [osgi-mock] late binding does not work for non-service DS components
> -
>
> Key: SLING-12157
> URL: https://issues.apache.org/jira/browse/SLING-12157
> Project: Sling
> Issue Type: Task
> Components: Testing
>Affects Versions: Testing OSGi Mock 3.3.10
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Major
>
> A DS component that is not a service can be "injected" and "activated", but
> if a service becomes available, that satisfies a dynamic reference, the
> "bind" method is not called. The same should be true for the "unbind"
> scenario.
> I observed this when I was registering a {{ResourceDecorator}} service in a
> test case, and it did not get bound by the
> {{ResourceResolverFactoryActivator}} that was already registered by the
> {{SlingContext}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (SLING-12144) Bump non-sling dependencies to latest in org.apache.sling.testing.sling-mock
[ https://issues.apache.org/jira/browse/SLING-12144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert reassigned SLING-12144: -- Component/s: Testing Fix Version/s: Testing Sling Mock 3.4.16 Assignee: Stefan Seifert > Bump non-sling dependencies to latest in org.apache.sling.testing.sling-mock > > > Key: SLING-12144 > URL: https://issues.apache.org/jira/browse/SLING-12144 > Project: Sling > Issue Type: Task > Components: Testing >Reporter: Rob McDougall >Assignee: Stefan Seifert >Priority: Major > Fix For: Testing Sling Mock 3.4.16 > > > Bump dependencies: > Mockito: 4.7.0 -> 5.7.0 > commons-lang 2.6 -> commons-lang3 3.13.0 > commons-io 2.11.0 -> 2.13.0 > commons-collectios4 4.2 -> 4.4 > JUnit5 5.2.0 -> 5.10.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-12147) caconfig-impl: Replace Sling XSS with OWASP Encoder
[ https://issues.apache.org/jira/browse/SLING-12147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert resolved SLING-12147. Resolution: Fixed https://github.com/apache/sling-org-apache-sling-caconfig-impl/commit/6d87c0abb5f791b72289ed57be63755372330fb9 > caconfig-impl: Replace Sling XSS with OWASP Encoder > --- > > Key: SLING-12147 > URL: https://issues.apache.org/jira/browse/SLING-12147 > Project: Sling > Issue Type: Improvement > Components: Extensions >Affects Versions: Context-Aware Configuration Impl 1.6.0 >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: Context-Aware Configuration Impl 1.6.2 > > > we do no longer want to use Sling XSS in our webconsole plugins to reduce > dependencies, so replace usage of it with OWASP encoder, similar to other > webconsole plugins e.g. SLING-12055 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12147) caconfig-impl: Replace Sling XSS with OWASP Encoder
Stefan Seifert created SLING-12147: -- Summary: caconfig-impl: Replace Sling XSS with OWASP Encoder Key: SLING-12147 URL: https://issues.apache.org/jira/browse/SLING-12147 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Context-Aware Configuration Impl 1.6.0 Reporter: Stefan Seifert Assignee: Stefan Seifert Fix For: Context-Aware Configuration Impl 1.6.2 we do no longer want to use Sling XSS in our webconsole plugins to reduce dependencies, so replace usage of it with OWASP encoder, similar to other webconsole plugins e.g. SLING-12055 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-12113) CPConverter: Improve error message "File being unzipped is too big" for Sling-Initial-Content
[
https://issues.apache.org/jira/browse/SLING-12113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert resolved SLING-12113.
Resolution: Fixed
https://github.com/apache/sling-org-apache-sling-feature-cpconverter/commit/7d64cf3ff804cb0ba3d71a55dcd953fa893d9512
> CPConverter: Improve error message "File being unzipped is too big" for
> Sling-Initial-Content
> -
>
> Key: SLING-12113
> URL: https://issues.apache.org/jira/browse/SLING-12113
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model
>Affects Versions: Content-Package to Feature Model Converter 1.3.4
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Major
> Fix For: Content-Package to Feature Model Converter 1.3.6
>
>
> if you use an OSGi bundle with Sling-Initial-Content, and the size of the
> unzipped content exceeds 100MB, currently an error messages without any
> context (out of a complex build) is issued:
> {noformat}
> Caused by: java.lang.IllegalStateException: File being unzipped is too big.
> at
> org.apache.sling.feature.cpconverter.handlers.slinginitialcontent.SlingInitialContentBundleEntryMetaDataCollector.collectFromContextAndWriteTmpFiles
> (SlingInitialContentBundleEntryMetaDataCollector.java:105)
> at
> org.apache.sling.feature.cpconverter.handlers.slinginitialcontent.BundleSlingInitialContentExtractor.extract
> (BundleSlingInitialContentExtractor.java:80)
> at
> org.apache.sling.feature.cpconverter.handlers.SlingInitialContentBundleHandler.processBundleInputStream
> (SlingInitialContentBundleHandler.java:53)
> at
> org.apache.sling.feature.cpconverter.handlers.BundleEntryHandler.handle
> (BundleEntryHandler.java:141)
> ...
> {noformat}
> this error messages should be improved to include the actual file name, and
> the actual limit that was hit (it's hard-coded 100MB in this case).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (SLING-12113) CPConverter: Improve error message "File being unzipped is too big" for Sling-Initial-Content
[
https://issues.apache.org/jira/browse/SLING-12113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1624#comment-1624
]
Stefan Seifert edited comment on SLING-12113 at 10/20/23 8:09 AM:
--
with the improvement from
https://github.com/apache/sling-org-apache-sling-feature-cpconverter/pull/172
the new message will look like:
{noformat}
Sling-Initial-Content: File content being unzipped is too big (>100 MB):
/jcr_root/apps/myapp/install/mybundle-1.0.0-SNAPSHOT.jar
{noformat}
was (Author: sseif...@pro-vision.de):
with the improvement from
https://github.com/apache/sling-org-apache-sling-feature-cpconverter/pull/172
the new message will look like:
{noformat}
File content being unzipped is too big (>100 MB):
/jcr_root/apps/myapp/install/mybundle-1.0.0-SNAPSHOT.jar
{noformat}
> CPConverter: Improve error message "File being unzipped is too big" for
> Sling-Initial-Content
> -
>
> Key: SLING-12113
> URL: https://issues.apache.org/jira/browse/SLING-12113
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model
>Affects Versions: Content-Package to Feature Model Converter 1.3.4
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Major
> Fix For: Content-Package to Feature Model Converter 1.3.6
>
>
> if you use an OSGi bundle with Sling-Initial-Content, and the size of the
> unzipped content exceeds 100MB, currently an error messages without any
> context (out of a complex build) is issued:
> {noformat}
> Caused by: java.lang.IllegalStateException: File being unzipped is too big.
> at
> org.apache.sling.feature.cpconverter.handlers.slinginitialcontent.SlingInitialContentBundleEntryMetaDataCollector.collectFromContextAndWriteTmpFiles
> (SlingInitialContentBundleEntryMetaDataCollector.java:105)
> at
> org.apache.sling.feature.cpconverter.handlers.slinginitialcontent.BundleSlingInitialContentExtractor.extract
> (BundleSlingInitialContentExtractor.java:80)
> at
> org.apache.sling.feature.cpconverter.handlers.SlingInitialContentBundleHandler.processBundleInputStream
> (SlingInitialContentBundleHandler.java:53)
> at
> org.apache.sling.feature.cpconverter.handlers.BundleEntryHandler.handle
> (BundleEntryHandler.java:141)
> ...
> {noformat}
> this error messages should be improved to include the actual file name, and
> the actual limit that was hit (it's hard-coded 100MB in this case).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12113) CPConverter: Improve error message "File being unzipped is too big" for Sling-Initial-Content
[
https://issues.apache.org/jira/browse/SLING-12113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1624#comment-1624
]
Stefan Seifert commented on SLING-12113:
with the improvement from
https://github.com/apache/sling-org-apache-sling-feature-cpconverter/pull/172
the new message will look like:
{noformat}
File content being unzipped is too big (>100 MB):
/jcr_root/apps/myapp/install/mybundle-1.0.0-SNAPSHOT.jar
{noformat}
> CPConverter: Improve error message "File being unzipped is too big" for
> Sling-Initial-Content
> -
>
> Key: SLING-12113
> URL: https://issues.apache.org/jira/browse/SLING-12113
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model
>Affects Versions: Content-Package to Feature Model Converter 1.3.4
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Major
> Fix For: Content-Package to Feature Model Converter 1.3.6
>
>
> if you use an OSGi bundle with Sling-Initial-Content, and the size of the
> unzipped content exceeds 100MB, currently an error messages without any
> context (out of a complex build) is issued:
> {noformat}
> Caused by: java.lang.IllegalStateException: File being unzipped is too big.
> at
> org.apache.sling.feature.cpconverter.handlers.slinginitialcontent.SlingInitialContentBundleEntryMetaDataCollector.collectFromContextAndWriteTmpFiles
> (SlingInitialContentBundleEntryMetaDataCollector.java:105)
> at
> org.apache.sling.feature.cpconverter.handlers.slinginitialcontent.BundleSlingInitialContentExtractor.extract
> (BundleSlingInitialContentExtractor.java:80)
> at
> org.apache.sling.feature.cpconverter.handlers.SlingInitialContentBundleHandler.processBundleInputStream
> (SlingInitialContentBundleHandler.java:53)
> at
> org.apache.sling.feature.cpconverter.handlers.BundleEntryHandler.handle
> (BundleEntryHandler.java:141)
> ...
> {noformat}
> this error messages should be improved to include the actual file name, and
> the actual limit that was hit (it's hard-coded 100MB in this case).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SLING-12113) CPConverter: Improve error message "File being unzipped is too big" for Sling-Initial-Content
Stefan Seifert created SLING-12113:
--
Summary: CPConverter: Improve error message "File being unzipped
is too big" for Sling-Initial-Content
Key: SLING-12113
URL: https://issues.apache.org/jira/browse/SLING-12113
Project: Sling
Issue Type: Improvement
Components: Feature Model
Affects Versions: Content-Package to Feature Model Converter 1.3.4
Reporter: Stefan Seifert
Assignee: Stefan Seifert
Fix For: Content-Package to Feature Model Converter 1.3.6
if you use an OSGi bundle with Sling-Initial-Content, and the size of the
unzipped content exceeds 100MB, currently an error messages without any context
(out of a complex build) is issued:
{noformat}
Caused by: java.lang.IllegalStateException: File being unzipped is too big.
at
org.apache.sling.feature.cpconverter.handlers.slinginitialcontent.SlingInitialContentBundleEntryMetaDataCollector.collectFromContextAndWriteTmpFiles
(SlingInitialContentBundleEntryMetaDataCollector.java:105)
at
org.apache.sling.feature.cpconverter.handlers.slinginitialcontent.BundleSlingInitialContentExtractor.extract
(BundleSlingInitialContentExtractor.java:80)
at
org.apache.sling.feature.cpconverter.handlers.SlingInitialContentBundleHandler.processBundleInputStream
(SlingInitialContentBundleHandler.java:53)
at org.apache.sling.feature.cpconverter.handlers.BundleEntryHandler.handle
(BundleEntryHandler.java:141)
...
{noformat}
this error messages should be improved to include the actual file name, and the
actual limit that was hit (it's hard-coded 100MB in this case).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SLING-11916) osgi-mock: MockEventAdminTest.testPostEvents times out on Jenkins/Windows
[
https://issues.apache.org/jira/browse/SLING-11916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert resolved SLING-11916.
Resolution: Fixed
great [~madamcin], thanks for finding the root cause!
for fixing i've gone the simple way and switched to a single threaded executor
which should be sufficient and easier to manage for the unit test scenario.
i've run the full CI tests on jenkins five times and they always did pass.
https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/commit/52d25d277251676acd322892aeb418107d930660
> osgi-mock: MockEventAdminTest.testPostEvents times out on Jenkins/Windows
> -
>
> Key: SLING-11916
> URL: https://issues.apache.org/jira/browse/SLING-11916
> Project: Sling
> Issue Type: Bug
> Components: Testing
>Reporter: Robert Munteanu
>Assignee: Stefan Seifert
>Priority: Major
> Fix For: Testing OSGi Mock 3.4.0
>
>
> The error is
>
> {noformat}
> [ERROR] org.apache.sling.testing.mock.osgi.MockEventAdminTest.testPostEvents
> Time elapsed: 3.02 s <<< ERROR!
> org.junit.runners.model.TestTimedOutException: test timed out after 3000
> milliseconds
> {noformat}
> and seems to affect both Java 11 and 17.
> https://ci-builds.apache.org/blue/organizations/jenkins/Sling%2Fmodules%2Fsling-org-apache-sling-testing-osgi-mock/detail/PR-27/1/pipeline
> (Java 11, Windows)
> https://ci-builds.apache.org/blue/organizations/jenkins/Sling%2Fmodules%2Fsling-org-apache-sling-testing-osgi-mock/detail/master/229/pipeline
> (Java 17, Windows)
> https://ci-builds.apache.org/blue/organizations/jenkins/Sling%2Fmodules%2Fsling-org-apache-sling-testing-osgi-mock/detail/master/228/pipeline
> (Java 17, Windows)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (SLING-11916) osgi-mock: MockEventAdminTest.testPostEvents times out on Jenkins/Windows
[
https://issues.apache.org/jira/browse/SLING-11916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert reassigned SLING-11916:
--
Assignee: Stefan Seifert
> osgi-mock: MockEventAdminTest.testPostEvents times out on Jenkins/Windows
> -
>
> Key: SLING-11916
> URL: https://issues.apache.org/jira/browse/SLING-11916
> Project: Sling
> Issue Type: Bug
> Components: Testing
>Reporter: Robert Munteanu
>Assignee: Stefan Seifert
>Priority: Major
> Fix For: Testing OSGi Mock 3.4.0
>
>
> The error is
>
> {noformat}
> [ERROR] org.apache.sling.testing.mock.osgi.MockEventAdminTest.testPostEvents
> Time elapsed: 3.02 s <<< ERROR!
> org.junit.runners.model.TestTimedOutException: test timed out after 3000
> milliseconds
> {noformat}
> and seems to affect both Java 11 and 17.
> https://ci-builds.apache.org/blue/organizations/jenkins/Sling%2Fmodules%2Fsling-org-apache-sling-testing-osgi-mock/detail/PR-27/1/pipeline
> (Java 11, Windows)
> https://ci-builds.apache.org/blue/organizations/jenkins/Sling%2Fmodules%2Fsling-org-apache-sling-testing-osgi-mock/detail/master/229/pipeline
> (Java 17, Windows)
> https://ci-builds.apache.org/blue/organizations/jenkins/Sling%2Fmodules%2Fsling-org-apache-sling-testing-osgi-mock/detail/master/228/pipeline
> (Java 17, Windows)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
