[jira] [Commented] (SLING-12415) Intermittent build failures on Sling Test envs - ResourceResolverFactoryActivator 250 ms
[
https://issues.apache.org/jira/browse/SLING-12415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17882346#comment-17882346
]
Stefan Seifert commented on SLING-12415:
here is a way to experiment with different timeout values using the new
configuration option introduced with SLING-12435:
to increase the timeout, set the system property
{{sling.mock.resourceresolverfactoryactivator.timeout.ms}} to a value higher
than 250 (the default value of 250ms).
to apply it to any build regardless of the CI in your project, create a file
{{.mvn/maven.config}} in the toplevel directory of your project with the
content:
{noformat}
-Dsling.mock.resourceresolverfactoryactivator.timeout.ms=100
{noformat}
then include in the dependencyManagement section of the project temporarily:
{code:xml}
org.apache.sling
org.apache.sling.testing.sling-mock.core
3.5.3-SNAPSHOT
{code}
and to make sure this snapshot can be loaded include temporarily:
{code:xml}
apache-snapshots
https://repository.apache.org/snapshots
default
false
true
always
{code}
> Intermittent build failures on Sling Test envs -
> ResourceResolverFactoryActivator 250 ms
>
>
> Key: SLING-12415
> URL: https://issues.apache.org/jira/browse/SLING-12415
> Project: Sling
> Issue Type: Bug
> Components: Testing
>Reporter: Niek Raaijmakers
>Priority: Major
>
> SLING-12090 introduced some cases where unit tests failed intermittently:
> We see:
>
> {code:java}
> 09:01:47,710 [ThreadedStreamConsumer] [ERROR] Tests run: 2, Failures: 0,
> Errors: 1, Skipped: 0, Time elapsed: 2.016 s <<< FAILURE! - in
> com.x.y.z.MoreLandingPagesServletTest 09:01:47,710 [ThreadedStreamConsumer]
> [ERROR] testDoGetLandingPagesServlet Time elapsed: 0.012 s <<< ERROR!
> java.lang.RuntimeException: Unable to initialize JCR_MOCK resource resolver
> factory: ResourceResolverFactoryActivator did not register a
> ResourceResolverFactory after 250ms. Caused by:
> java.lang.IllegalStateException: ResourceResolverFactoryActivator did not
> register a ResourceResolverFactory after 250ms.{code}
>
> Perhaps we could increase the timeout?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SLING-12435) sling-mock: Make timeout to wait for ResourceResolverFactoryActivator configurable via system property
[
https://issues.apache.org/jira/browse/SLING-12435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert resolved SLING-12435.
Resolution: Fixed
https://github.com/apache/sling-org-apache-sling-testing-sling-mock/commit/73e3bec4ade92b42202303ef99b516ab93e72ac2
introduced a new system property - usage example to reconfigure the timeout to
100ms:
{noformat}
-Dsling.mock.resourceresolverfactoryactivator.timeout.ms=100
{noformat}
> sling-mock: Make timeout to wait for ResourceResolverFactoryActivator
> configurable via system property
> --
>
> Key: SLING-12435
> URL: https://issues.apache.org/jira/browse/SLING-12435
> Project: Sling
> Issue Type: Improvement
> Components: Testing
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Minor
> Fix For: Testing Sling Mock 3.5.4
>
>
> to be able to mitigate timeout issues or to evaluate if the actual timeout
> value is really a problem, we should make the current timeout value (250ms)
> configurable, but keep the default value of 250ms.
> this timeout was introduced with SLING-12090, as newer resource resolver
> implementation register resource resolver factories in an async way.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-12435) sling-mock: Make timeout to wait for ResourceResolverFactoryActivator configurable via system property
[ https://issues.apache.org/jira/browse/SLING-12435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert updated SLING-12435: --- Description: to be able to mitigate timeout issues or to evaluate if the actual timeout value is really a problem, we should make the current timeout value (250ms) configurable, but keep the default value of 250ms. this timeout was introduced with SLING-12090, as newer resource resolver implementation register resource resolver factories in an async way. was:to be able to mitigate timeout issues or to evaluate if the actual timeout value is really a problem, we should make the current timeout value (250ms) configurable, but keep the default value of 250ms. > sling-mock: Make timeout to wait for ResourceResolverFactoryActivator > configurable via system property > -- > > Key: SLING-12435 > URL: https://issues.apache.org/jira/browse/SLING-12435 > Project: Sling > Issue Type: Improvement > Components: Testing >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Minor > Fix For: Testing Sling Mock 3.5.4 > > > to be able to mitigate timeout issues or to evaluate if the actual timeout > value is really a problem, we should make the current timeout value (250ms) > configurable, but keep the default value of 250ms. > this timeout was introduced with SLING-12090, as newer resource resolver > implementation register resource resolver factories in an async way. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12435) sling-mock: Make timeout to wait for ResourceResolverFactoryActivator configurable via system property
Stefan Seifert created SLING-12435: -- Summary: sling-mock: Make timeout to wait for ResourceResolverFactoryActivator configurable via system property Key: SLING-12435 URL: https://issues.apache.org/jira/browse/SLING-12435 Project: Sling Issue Type: Improvement Components: Testing Reporter: Stefan Seifert Assignee: Stefan Seifert Fix For: Testing Sling Mock 3.5.4 to be able to mitigate timeout issues or to evaluate if the actual timeout value is really a problem, we should make the current timeout value (250ms) configurable, but keep the default value of 250ms. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12418) Context Aware Config: latest caconfig-mock-plugin not updated
[
https://issues.apache.org/jira/browse/SLING-12418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879026#comment-17879026
]
Stefan Seifert commented on SLING-12418:
this is by design, as the version of the caconfig api/spi/impl bundles should
be controlled by your maven project, not by this mock plugin. the versions used
in your maven project should match the actual version deployed to your
application runtime container - this is not necessarily always the latest
version.
in case you are using AEM and AEM Mocks i recommend this approach:
https://wcm.io/testing/aem-mock/usage-maven-dependencies.html
> Context Aware Config: latest caconfig-mock-plugin not updated
> -
>
> Key: SLING-12418
> URL: https://issues.apache.org/jira/browse/SLING-12418
> Project: Sling
> Issue Type: Improvement
>Affects Versions: Context-Aware Configuration Mock Plugin 1.5.4
>Reporter: Pablo Castelo
>Priority: Major
>
> In the last caconfig-mock-plugin dependency the versions are not up to date.
> * org.apache.sling.caconfig.api --> 1.1.2 (new 1.3.0)
> * org.apache.sling.caconfig.spi --> 1.3.4 (new 1.4.0)
> * org.apache.sling.caconfig.impl --> 1.4.14 (new 1.6.0)
> This is causing an issue when the annotation @ContextAwareConfigurarion is
> used on the code, since it needs at least impl 1.6.0 and spi 1.4.0.
> [https://github.com/apache/sling-org-apache-sling-testing-caconfig-mock-plugin/blob/master/src/main/java/org/apache/sling/testing/mock/caconfig/ContextPlugins.java#L183C75-L183C108]
> (based on the comment)
> Causing:
> {code:java}
> [ERROR] Errors:
> [ERROR] TitleTest.testPageTitleLTR » Runtime Before setup failed
> (org.apache.sling.testing.mock.caconfig.ContextPlugins$1@5d5ae6aa): Service
> reference type not found:
> org.apache.sling.caconfig.management.multiplexer.ConfigurationInjectResourceDetectionStrategyMultiplexer
> [ERROR] TitleTest.testPageTitleRTL » Runtime Before setup failed
> (org.apache.sling.testing.mock.caconfig.ContextPlugins$1@5d5ae6aa): Service
> reference type not found:
> org.apache.sling.caconfig.management.multiplexer.ConfigurationInjectResourceDetectionStrategyMultiplexer{code}
> My suggestion will be to release a new version with the latest versions to
> solve the issue
> As workaround, these two dependencies can be added to the pom
> {code:java}
>
> org.apache.sling
> org.apache.sling.caconfig.impl
> 1.6.0
> test
>
>
> org.apache.sling
> org.apache.sling.caconfig.spi
> 1.4.0
> test
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12413) OSGi mocks ranked service collections are not ordered consistently
[
https://issues.apache.org/jira/browse/SLING-12413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878576#comment-17878576
]
Stefan Seifert commented on SLING-12413:
thanks, merged
> OSGi mocks ranked service collections are not ordered consistently
> --
>
> Key: SLING-12413
> URL: https://issues.apache.org/jira/browse/SLING-12413
> Project: Sling
> Issue Type: Bug
> Components: Testing
>Affects Versions: Testing OSGi Mock 3.5.0
>Reporter: Bart Thierens
>Priority: Major
> Fix For: Testing OSGi Mock 3.5.2
>
>
> The OSGi mocks rank services by service.ranking to simulate Felix workings,
> see
> [here|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/2caaa14f5c38a54a0239f0f5550cd8a432307304/core/src/main/java/org/apache/sling/testing/mock/osgi/OsgiServiceUtil.java#L710]
>
> This works fine when you register the components before the calling/using
> component (=the one that holds the reference to the collection of other
> components) is registered itself.
> The OSGiServiceUtil finds all matching services, sorts the collection of
> references and then proceeds to inject the actual impl's in that order.
> However, if you register your calling component first - or you add more
> components after the calling component was already registered - they will
> just be added as-is to the collection. This is done
> [here|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/2caaa14f5c38a54a0239f0f5550cd8a432307304/core/src/main/java/org/apache/sling/testing/mock/osgi/OsgiServiceUtil.java#L863].
> In Felix this works correctly and the collection is always sorted correctly,
> even after late add's or remove's of references.
> This causes inconsistent behaviour while testing. See
> [this|https://github.com/senn/aemcontext-no-serviceranking-ordering/blob/incorrect-ordering-depending-on-injection-time/src/test/java/com/github/senn/services/InjectionTimeOrderingTest.java]
> test example I prepared. It has 3 tests:
> * 1 one where the references are registered first - OK
> * 1 one where the calling service is registered first -
> {color:#FF}NOK{color}
> * 1 combination test - {color:#FF}NOK{color}
> I know the OSGi spec does not really define the ordering but if you do it
> 'the Felix way' in once place, it should at least be consistent.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12413) OSGi mocks ranked service collections are not ordered consistently
[
https://issues.apache.org/jira/browse/SLING-12413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878008#comment-17878008
]
Stefan Seifert commented on SLING-12413:
the PR got merged a bit too quick, see my comments here:
https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/pull/41#issuecomment-2307162435
please cleanup the code, we cannot heal the commit messages easily but at least
we can put the ticket number in the cleanup commit/PR.
> OSGi mocks ranked service collections are not ordered consistently
> --
>
> Key: SLING-12413
> URL: https://issues.apache.org/jira/browse/SLING-12413
> Project: Sling
> Issue Type: Bug
> Components: Testing
>Affects Versions: Testing OSGi Mock 3.5.0
>Reporter: Bart Thierens
>Priority: Major
> Fix For: Testing OSGi Mock 3.5.2
>
>
> The OSGi mocks rank services by service.ranking to simulate Felix workings,
> see
> [here|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/2caaa14f5c38a54a0239f0f5550cd8a432307304/core/src/main/java/org/apache/sling/testing/mock/osgi/OsgiServiceUtil.java#L710]
>
> This works fine when you register the components before the calling/using
> component (=the one that holds the reference to the collection of other
> components) is registered itself.
> The OSGiServiceUtil finds all matching services, sorts the collection of
> references and then proceeds to inject the actual impl's in that order.
> However, if you register your calling component first - or you add more
> components after the calling component was already registered - they will
> just be added as-is to the collection. This is done
> [here|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/2caaa14f5c38a54a0239f0f5550cd8a432307304/core/src/main/java/org/apache/sling/testing/mock/osgi/OsgiServiceUtil.java#L863].
> In Felix this works correctly and the collection is always sorted correctly,
> even after late add's or remove's of references.
> This causes inconsistent behaviour while testing. See
> [this|https://github.com/senn/aemcontext-no-serviceranking-ordering/blob/incorrect-ordering-depending-on-injection-time/src/test/java/com/github/senn/services/InjectionTimeOrderingTest.java]
> test example I prepared. It has 3 tests:
> * 1 one where the references are registered first - OK
> * 1 one where the calling service is registered first -
> {color:#FF}NOK{color}
> * 1 combination test - {color:#FF}NOK{color}
> I know the OSGi spec does not really define the ordering but if you do it
> 'the Felix way' in once place, it should at least be consistent.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12415) Intermittent build failures on Sling Test envs - ResourceResolverFactoryActivator 250 ms
[
https://issues.apache.org/jira/browse/SLING-12415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877601#comment-17877601
]
Stefan Seifert commented on SLING-12415:
do you have a unit test case or test project to reproduce the failure? do you
get this error permanently and reproducible, or only sometimes from time to
time?
do you get any other errors in the log file that might be related?
it would also be intersting to see the actual versions of all other libraries
in the (test)classpath, esp. the sling module ones.
not sure if it really helps to increase the timeout. it's not unlikely that
there is a problem that is not cured by this. you could verify this on your
side by testing it with a patched version of sling-mock with a higher timeout.
> Intermittent build failures on Sling Test envs -
> ResourceResolverFactoryActivator 250 ms
>
>
> Key: SLING-12415
> URL: https://issues.apache.org/jira/browse/SLING-12415
> Project: Sling
> Issue Type: Bug
> Components: Testing
>Reporter: Niek Raaijmakers
>Priority: Major
>
> SLING-12090 introduced some cases where unit tests failed intermittently:
> We see:
>
> {code:java}
> 09:01:47,710 [ThreadedStreamConsumer] [ERROR] Tests run: 2, Failures: 0,
> Errors: 1, Skipped: 0, Time elapsed: 2.016 s <<< FAILURE! - in
> com.x.y.z.MoreLandingPagesServletTest 09:01:47,710 [ThreadedStreamConsumer]
> [ERROR] testDoGetLandingPagesServlet Time elapsed: 0.012 s <<< ERROR!
> java.lang.RuntimeException: Unable to initialize JCR_MOCK resource resolver
> factory: ResourceResolverFactoryActivator did not register a
> ResourceResolverFactory after 250ms. Caused by:
> java.lang.IllegalStateException: ResourceResolverFactoryActivator did not
> register a ResourceResolverFactory after 250ms.{code}
>
> Perhaps we could increase the timeout?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SLING-12352) ContentLoader XML / JSON initialisation should be done in a lazy way (when needed)
[ https://issues.apache.org/jira/browse/SLING-12352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-12352. -- > ContentLoader XML / JSON initialisation should be done in a lazy way (when > needed) > -- > > Key: SLING-12352 > URL: https://issues.apache.org/jira/browse/SLING-12352 > Project: Sling > Issue Type: Bug > Components: Testing >Affects Versions: Testing Sling Mock 3.5.0 >Reporter: Henry Kuijpers >Assignee: Henry Kuijpers >Priority: Major > Fix For: Testing Sling Mock 3.5.2 > > > When calling context.load(), a content loader is created in a lazy way (when > it's not there, it is instantiated and otherwise a cached instance is > returned). > However, when instantiating this content loader, everything needed for XML & > JSON is set up, regardless of calls to json() or xml() being made or not. > This should also be done in a lazy way. > > A specific issue that can be tackled this way is running parallel tests in > combination with XML parsers and their ugly statics, interfering with each > other. > This would tackle the "No page manager." / "No asset manager." errors that > can be seen when using AemContext. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12375) Maps used for Declarative Services must be comparable
[ https://issues.apache.org/jira/browse/SLING-12375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-12375. -- > Maps used for Declarative Services must be comparable > - > > Key: SLING-12375 > URL: https://issues.apache.org/jira/browse/SLING-12375 > Project: Sling > Issue Type: Improvement > Components: Testing >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Major > Fix For: Testing OSGi Mock 3.5.0 > > > According to 112.3.2 of the Declarative Service specification (see > https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.component.html#service.component-method.injection) > the maps passed into the bind methods (as well as field injection) must > implement Comparable. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12410) resourceresolver-mock: Implement ResourceResolver copy and move methods
[ https://issues.apache.org/jira/browse/SLING-12410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-12410. -- > resourceresolver-mock: Implement ResourceResolver copy and move methods > --- > > Key: SLING-12410 > URL: https://issues.apache.org/jira/browse/SLING-12410 > Project: Sling > Issue Type: Improvement > Components: Testing >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: Testing ResourceResolver Mock 1.5.0 > > > PR was provded by senn: > https://github.com/apache/sling-org-apache-sling-testing-resourceresolver-mock/pull/16 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-12410) resourceresolver-mock: Implement ResourceResolver copy and move methods
[ https://issues.apache.org/jira/browse/SLING-12410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert resolved SLING-12410. Resolution: Fixed https://github.com/apache/sling-org-apache-sling-testing-resourceresolver-mock/commit/dd68324dd96f1772e81249f38089d40627748748 > resourceresolver-mock: Implement ResourceResolver copy and move methods > --- > > Key: SLING-12410 > URL: https://issues.apache.org/jira/browse/SLING-12410 > Project: Sling > Issue Type: Improvement > Components: Testing >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: Testing ResourceResolver Mock 1.5.0 > > > PR was provded by senn: > https://github.com/apache/sling-org-apache-sling-testing-resourceresolver-mock/pull/16 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12410) resourceresolver-mock: Implement ResourceResolver copy and move methods
Stefan Seifert created SLING-12410: -- Summary: resourceresolver-mock: Implement ResourceResolver copy and move methods Key: SLING-12410 URL: https://issues.apache.org/jira/browse/SLING-12410 Project: Sling Issue Type: Improvement Components: Testing Reporter: Stefan Seifert Assignee: Stefan Seifert Fix For: Testing ResourceResolver Mock 1.5.0 PR was provded by senn: https://github.com/apache/sling-org-apache-sling-testing-resourceresolver-mock/pull/16 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-10062) Provide a way to allow mocking of findResources or query manager for resource resolvers / sessions obtained inside production code
[
https://issues.apache.org/jira/browse/SLING-10062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert resolved SLING-10062.
Resolution: Duplicate
should be fixed with SLING-12001
> Provide a way to allow mocking of findResources or query manager for resource
> resolvers / sessions obtained inside production code
> --
>
> Key: SLING-10062
> URL: https://issues.apache.org/jira/browse/SLING-10062
> Project: Sling
> Issue Type: Improvement
> Components: Testing
>Reporter: Roy Teeuwen
>Priority: Major
>
> At this moment it is not possible to do a mock for query results of resource
> resolvers / sessions that are obtained inside the code instead of passed as
> method parameter from the SlingContext / JcrContext.
> Example:
> {code:java}
> @Component
> public class MyClass {
>@Reference
>private ResourceResolverFactory resourceResolverFactory;
>public void methodToTest() {
> try(ResourceResolver resourceResolver:
> resourceResolverFactory.getServiceResourceResolver(AUTH_INFO)) {
> // something to test
> }
>}
> }{code}
> Currently I solve this by just making a second method that gets the resource
> resolver as parameter and making it public so that it can be tested, but that
> breaks my private / public stuff
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12306) Sling mock: JUnit 5 parallel execution results in unregistered adapter factories
[
https://issues.apache.org/jira/browse/SLING-12306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17874820#comment-17874820
]
Stefan Seifert commented on SLING-12306:
i've seen this problem from time to time, but rather rarely, pop up in the unit
test of wcm.io modules as well, but could not pin down the root cause.
in SLING-12352 you wrote that you see a direct relation to this issue. do you
think this is solved, or that the problem might be directly related to the code
that is now loaded lazily with SLING-12352?
i'm wondering if there is a way to write a unit test to reproduce this problem,
or somehow force it occurence by certain conditions.
> Sling mock: JUnit 5 parallel execution results in unregistered adapter
> factories
>
>
> Key: SLING-12306
> URL: https://issues.apache.org/jira/browse/SLING-12306
> Project: Sling
> Issue Type: Bug
> Components: Testing
>Reporter: Henry Kuijpers
>Priority: Major
>
> We have junit-jupiter.properties:
> {code:java}
> junit.jupiter.execution.parallel.enabled = true
> junit.jupiter.execution.parallel.mode.default = same_thread
> junit.jupiter.execution.parallel.mode.classes.default = concurrent {code}
> And this results, randomly everytime, in lots of tests failing because of
> missing adapter factories.
>
> We sometimes see that `boundAdapterFactories` is an empty list. Sometimes we
> see that `factoryCache` is a filled map, with all value lists empty.
>
> We usually see the expected `descriptors` having variable content. One time
> it has 4 entries for o.a.s.a.r.Resource, the other run it has 5 entries.
>
> I believe this is a concurrency issue somehow. I can reproduce it on older
> versions as well (previously we couldn't). So there could also be something
> with dependencies involved.
>
>
> More specifically, we seem to get a lot of these stack traces like this:
> {code:java}
> java.lang.RuntimeException: No page manager.
> at
> io.wcm.testing.mock.aem.context.AemContextImpl.pageManager(AemContextImpl.java:169)
> at
> io.wcm.testing.mock.aem.context.AemContextImpl.currentPage(AemContextImpl.java:229)
> {code}
> (also posting this for findability on search engines)
> And also a lot of cases where a Resource cannot be adapted to a ValueMap for
> example.
> Which boils down to the adapter factory that can adapt a ResourceResolver to
> a PageManager, missing or actually not registered yet.
> We do have the proper @ExtendWith etc setup.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SLING-12364) Supported source version 'RELEASE_6' from annotation processor 'org.apache.sling.models.annotations.apt.ValidatingAnnotationProcessor' less than -source '11'
[
https://issues.apache.org/jira/browse/SLING-12364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert closed SLING-12364.
--
> Supported source version 'RELEASE_6' from annotation processor
> 'org.apache.sling.models.annotations.apt.ValidatingAnnotationProcessor' less
> than -source '11'
> -
>
> Key: SLING-12364
> URL: https://issues.apache.org/jira/browse/SLING-12364
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Affects Versions: Models API 1.5.2
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Major
> Fix For: Models API 1.5.4
>
>
> the fix from SLING-12271 was not sufficient - we need to specify
> {{SourceVersion.latest()}} to get rid of any code warning here.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SLING-12364) Supported source version 'RELEASE_6' from annotation processor 'org.apache.sling.models.annotations.apt.ValidatingAnnotationProcessor' less than -source '11'
[
https://issues.apache.org/jira/browse/SLING-12364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert resolved SLING-12364.
Resolution: Fixed
https://github.com/apache/sling-org-apache-sling-models-api/commit/4ac935cfc0565d1acfadbd9e1c34849bfb2ddeae
> Supported source version 'RELEASE_6' from annotation processor
> 'org.apache.sling.models.annotations.apt.ValidatingAnnotationProcessor' less
> than -source '11'
> -
>
> Key: SLING-12364
> URL: https://issues.apache.org/jira/browse/SLING-12364
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Affects Versions: Models API 1.5.2
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Major
> Fix For: Models API 1.5.4
>
>
> the fix from SLING-12271 was not sufficient - we need to specify
> {{SourceVersion.latest()}} to get rid of any code warning here.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12271) Supported source version 'RELEASE_8' from annotation processor 'org.apache.sling.models.annotations.apt.ValidatingAnnotationProcessor' less than -source '11'
[
https://issues.apache.org/jira/browse/SLING-12271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17860864#comment-17860864
]
Stefan Seifert commented on SLING-12271:
unfortunately this fix did not actually fix the issue, but converted the
warning to
{noformat}
[WARNING] No SupportedSourceVersion annotation found on
org.apache.sling.models.annotations.apt.ValidatingAnnotationProcessor,
returning RELEASE_6.
[WARNING] Supported source version 'RELEASE_6' from annotation processor
'org.apache.sling.models.annotations.apt.ValidatingAnnotationProcessor' less
than -source '11'
{noformat}
i also missed to cross-check the result. created SLING-12364 for follow-up.
> Supported source version 'RELEASE_8' from annotation processor
> 'org.apache.sling.models.annotations.apt.ValidatingAnnotationProcessor' less
> than -source '11'
> -
>
> Key: SLING-12271
> URL: https://issues.apache.org/jira/browse/SLING-12271
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Affects Versions: Models API 1.5.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: Models API 1.5.2
>
>
> The annotation processor introduced with SLING-11507 only supports Java 8
> source code version according to the annotation
> https://github.com/apache/sling-org-apache-sling-models-api/blob/3a2bfd7882ef0ef453261aff4f58adeee171c4c7/src/main/java/org/apache/sling/models/annotations/apt/ValidatingAnnotationProcessor.java#L41.
> This leads to the following warning during compilation when using javac's
> {{source}} or {{release}} option with any other value than 1.8/8.
> {code}
> [WARNING] Supported source version 'RELEASE_8' from annotation processor
> 'org.apache.sling.models.annotations.apt.ValidatingAnnotationProcessor' less
> than -source '11'
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SLING-12364) Supported source version 'RELEASE_6' from annotation processor 'org.apache.sling.models.annotations.apt.ValidatingAnnotationProcessor' less than -source '11'
Stefan Seifert created SLING-12364:
--
Summary: Supported source version 'RELEASE_6' from annotation
processor
'org.apache.sling.models.annotations.apt.ValidatingAnnotationProcessor' less
than -source '11'
Key: SLING-12364
URL: https://issues.apache.org/jira/browse/SLING-12364
Project: Sling
Issue Type: Improvement
Components: Sling Models
Affects Versions: Models API 1.5.2
Reporter: Stefan Seifert
Assignee: Stefan Seifert
Fix For: Models API 1.5.4
the fix from SLING-12271 was not sufficient - we need to specify
{{SourceVersion.latest()}} to get rid of any code warning here.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SLING-12158) Log affected Sling Model class for messages emitted from AbstractInjectableElement
[ https://issues.apache.org/jira/browse/SLING-12158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-12158. -- > Log affected Sling Model class for messages emitted from > AbstractInjectableElement > -- > > Key: SLING-12158 > URL: https://issues.apache.org/jira/browse/SLING-12158 > Project: Sling > Issue Type: Improvement > Components: Sling Models >Affects Versions: Models Implementation 1.6.4 >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: Models Implementation 1.7.0 > > > Both > https://github.com/apache/sling-org-apache-sling-models-impl/blob/b0647a3419924c46e58b78aa6384e0f49491a0c6/src/main/java/org/apache/sling/models/impl/model/AbstractInjectableElement.java > and classes derived from it emit some log messages. Those log message miss > the context of the Sling Model class where that happens. > This is e.g. the case in > https://github.com/apache/sling-org-apache-sling-models-impl/blob/b701d76cd02fcbcbb5a9470400bdf3afc803cf2c/src/main/java/org/apache/sling/models/impl/model/AbstractInjectableElement.java#L182 > where only the type but neither the name nor the container model class is > emitted. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12359) Sling Models: Support constructor injection for Java Record classes
[
https://issues.apache.org/jira/browse/SLING-12359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert closed SLING-12359.
--
> Sling Models: Support constructor injection for Java Record classes
> ---
>
> Key: SLING-12359
> URL: https://issues.apache.org/jira/browse/SLING-12359
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Affects Versions: Models Implementation 1.6.4
>Reporter: Herman Ciechanowiec
>Assignee: Stefan Seifert
>Priority: Major
> Labels: Sling-13-Release-Notes
> Fix For: Models Implementation 1.7.0
>
>
> Java 14 introduced support for record classes, and Apache Sling 12 by default
> runs with Java 17, allowing the use of records.
> Although Apache Sling 12 supports record classes, the current latest version
> of Apache Sling Models Implementation does not fully support injection in
> relation to records. Specifically, for records, the Apache Sling Models
> Implementation *does* support constructor injection similarly to a usual
> class if there is an *explicit* constructor annotated with
> `javax.inject.Inject`:
> {code:java}
> @Model(
> adaptables = {Resource.class, SlingHttpServletRequest.class},
> defaultInjectionStrategy = DefaultInjectionStrategy.REQUIRED
> )
> public record StudentModel(String name, int age) {
> @Inject
> public StudentModel(
> @ValueMapValue(name = "name") @Default(values = "unknown")
> String name,
> @ValueMapValue(name = "age") @Default(intValues = 0)
> int age
> ) {
> this.name = name;
> this.age = age;
> }
> }
> {code}
> However, for records, Apache Sling Models Implementation *does not* support
> constructor injection if there is an *implicit* constructor. Such a
> constructor cannot be annotated with `javax.inject.Inject` and will not be
> picked up during injection. Therefore, such a Sling Model will not be
> instantiated at all:
> {code:java}
> @Model(
> adaptables = {Resource.class, SlingHttpServletRequest.class},
> defaultInjectionStrategy = DefaultInjectionStrategy.REQUIRED
> )
> public record StudentModel(
> @ValueMapValue(name = "name") @Default(values = "unknown")
> String name,
> @ValueMapValue(name = "age") @Default(intValues = 0)
> int age
> ) {}
> {code}
> The above issue should be addressed by introducing support for injection in
> records' implicit constructors.
> Note:
> 1. For records, only constructor injection is supported since records cannot
> have instance fields (code with such fields will not compile).
> 2. Apache Sling Models Implementation is currently based on Java 8 and may
> also be executed in a Java 8 environment. Therefore, the records check should
> be introduced via dynamic loading of the `java.lang.Record` class.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SLING-12360) Models: Update to Parent 60, Java 11 Minimum Version
[ https://issues.apache.org/jira/browse/SLING-12360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-12360. -- > Models: Update to Parent 60, Java 11 Minimum Version > > > Key: SLING-12360 > URL: https://issues.apache.org/jira/browse/SLING-12360 > Project: Sling > Issue Type: Improvement > Components: Sling Models >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: Models Context-Aware Configuration 1.0.4, Models > Implementation 1.7.0, Models Jackson Exporter 1.1.6, Sling Models bnd Plugin > 1.0.2 > > > 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] [Closed] (SLING-11917) Sling Models: Support parameter name evaluation in constructor injection
[
https://issues.apache.org/jira/browse/SLING-11917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert closed SLING-11917.
--
> Sling Models: Support parameter name evaluation in constructor injection
>
>
> Key: SLING-11917
> URL: https://issues.apache.org/jira/browse/SLING-11917
> Project: Sling
> Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: Models Implementation 1.7.0
>
>
> https://openjdk.org/jeps/118 introduced support of retrieving parameter names
> at run time through reflection. This should be leveraged in constructor
> injection in Sling Models to not be forced to use the {{@Named}} annotation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SLING-12271) Supported source version 'RELEASE_8' from annotation processor 'org.apache.sling.models.annotations.apt.ValidatingAnnotationProcessor' less than -source '11'
[
https://issues.apache.org/jira/browse/SLING-12271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert closed SLING-12271.
--
> Supported source version 'RELEASE_8' from annotation processor
> 'org.apache.sling.models.annotations.apt.ValidatingAnnotationProcessor' less
> than -source '11'
> -
>
> Key: SLING-12271
> URL: https://issues.apache.org/jira/browse/SLING-12271
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Affects Versions: Models API 1.5.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: Models API 1.5.2
>
>
> The annotation processor introduced with SLING-11507 only supports Java 8
> source code version according to the annotation
> https://github.com/apache/sling-org-apache-sling-models-api/blob/3a2bfd7882ef0ef453261aff4f58adeee171c4c7/src/main/java/org/apache/sling/models/annotations/apt/ValidatingAnnotationProcessor.java#L41.
> This leads to the following warning during compilation when using javac's
> {{source}} or {{release}} option with any other value than 1.8/8.
> {code}
> [WARNING] Supported source version 'RELEASE_8' from annotation processor
> 'org.apache.sling.models.annotations.apt.ValidatingAnnotationProcessor' less
> than -source '11'
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SLING-12273) Build breaks on Java 21, Update to Parent 60
[
https://issues.apache.org/jira/browse/SLING-12273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert closed SLING-12273.
--
> Build breaks on Java 21, Update to Parent 60
>
>
> Key: SLING-12273
> URL: https://issues.apache.org/jira/browse/SLING-12273
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Affects Versions: Models API 1.5.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: Models API 1.5.2
>
>
> The following error is emitted in during building with Maven
> (https://ci-builds.apache.org/blue/organizations/jenkins/Sling%2Fmodules%2Fsling-org-apache-sling-models-api/detail/master/212/pipeline/)
> {code}
> [INFO] --- invoker:3.3.0:run (integration-test) @ org.apache.sling.models.api
> ---
> [INFO] Building: validating-annotation-processor/pom.xml
> [INFO] run post-build script verify.groovy
> [INFO] BUG! exception in phase 'semantic analysis' in source unit
> 'Script1.groovy' Unsupported class file major version 65
> [INFO] validating-annotation-processor/pom.xml .. FAILED
> (15.5 s)
> [INFO] -
> [INFO] Build Summary:
> [INFO] Passed: 0, Failed: 1, Errors: 0, Skipped: 0
> [INFO] -
> [ERROR] The following builds failed:
> [ERROR] * validating-annotation-processor/pom.xml
> [INFO] -
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 51.891 s
> [INFO] Finished at: 2024-03-15T23:26:49Z
> [INFO]
>
> [INFO] [jenkins-event-spy] Generated
> /home/jenkins/workspace/g-apache-sling-models-api_master/jdk_21_latest@tmp/withMaven74374c80/maven-spy-20240315-232556-91012999432982760308630.log
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-invoker-plugin:3.3.0:run (integration-test) on
> project org.apache.sling.models.api: 1 build failed. See console output above
> for details. -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-invoker-plugin:3.3.0:run
> (integration-test) on project org.apache.sling.models.api: 1 build failed.
> See console output above for details.
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:333)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:316)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:212)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:174)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:75)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:162)
> at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:159)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
> at jdk.internal.reflect.DirectMethodHandleAccessor.invoke
> (DirectMethodHandleAccessor.java:103)
> at java.lang.reflect.Method.invoke (Method.java:580)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:283)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:226)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:407)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:348)
> Caused by: org.apache.maven.plugin.MojoFailureException: 1 build failed. See
> console output above for detail
[jira] [Assigned] (SLING-11917) Sling Models: Support parameter name evaluation in constructor injection
[
https://issues.apache.org/jira/browse/SLING-11917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert reassigned SLING-11917:
--
Assignee: Konrad Windszus
> Sling Models: Support parameter name evaluation in constructor injection
>
>
> Key: SLING-11917
> URL: https://issues.apache.org/jira/browse/SLING-11917
> Project: Sling
> Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: Models Implementation 1.7.0
>
>
> https://openjdk.org/jeps/118 introduced support of retrieving parameter names
> at run time through reflection. This should be leveraged in constructor
> injection in Sling Models to not be forced to use the {{@Named}} annotation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-12273) Build breaks on Java 21, Update to Parent 60
[
https://issues.apache.org/jira/browse/SLING-12273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert updated SLING-12273:
---
Summary: Build breaks on Java 21, Update to Parent 60 (was: Build breaks
on Java 21)
> Build breaks on Java 21, Update to Parent 60
>
>
> Key: SLING-12273
> URL: https://issues.apache.org/jira/browse/SLING-12273
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Affects Versions: Models API 1.5.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: Models API 1.5.2
>
>
> The following error is emitted in during building with Maven
> (https://ci-builds.apache.org/blue/organizations/jenkins/Sling%2Fmodules%2Fsling-org-apache-sling-models-api/detail/master/212/pipeline/)
> {code}
> [INFO] --- invoker:3.3.0:run (integration-test) @ org.apache.sling.models.api
> ---
> [INFO] Building: validating-annotation-processor/pom.xml
> [INFO] run post-build script verify.groovy
> [INFO] BUG! exception in phase 'semantic analysis' in source unit
> 'Script1.groovy' Unsupported class file major version 65
> [INFO] validating-annotation-processor/pom.xml .. FAILED
> (15.5 s)
> [INFO] -
> [INFO] Build Summary:
> [INFO] Passed: 0, Failed: 1, Errors: 0, Skipped: 0
> [INFO] -
> [ERROR] The following builds failed:
> [ERROR] * validating-annotation-processor/pom.xml
> [INFO] -
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 51.891 s
> [INFO] Finished at: 2024-03-15T23:26:49Z
> [INFO]
>
> [INFO] [jenkins-event-spy] Generated
> /home/jenkins/workspace/g-apache-sling-models-api_master/jdk_21_latest@tmp/withMaven74374c80/maven-spy-20240315-232556-91012999432982760308630.log
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-invoker-plugin:3.3.0:run (integration-test) on
> project org.apache.sling.models.api: 1 build failed. See console output above
> for details. -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-invoker-plugin:3.3.0:run
> (integration-test) on project org.apache.sling.models.api: 1 build failed.
> See console output above for details.
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:333)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:316)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:212)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:174)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:75)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:162)
> at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:159)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
> at jdk.internal.reflect.DirectMethodHandleAccessor.invoke
> (DirectMethodHandleAccessor.java:103)
> at java.lang.reflect.Method.invoke (Method.java:580)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:283)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:226)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:407)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:348)
> Caused by: org.apa
[jira] [Resolved] (SLING-12360) Models: Update to Parent 60, Java 11 Minimum Version
[ https://issues.apache.org/jira/browse/SLING-12360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert resolved SLING-12360. Resolution: Fixed impl * [https://github.com/apache/sling-org-apache-sling-models-impl/commit/cc4ac50b5be64ba7cb91dee511978a0fc592e370] * [https://github.com/apache/sling-org-apache-sling-models-impl/commit/fcb45ad9be1930e0ee5956e45a2dddf2387a4453] * [https://github.com/apache/sling-org-apache-sling-models-impl/commit/164b9f32401c088609a8abffc0d3eba7ec959ef5] jackson exporter * [https://github.com/apache/sling-org-apache-sling-models-jacksonexporter/commit/4fe850b4f3b6bf4d3d4908d32e10965575309942] * [https://github.com/apache/sling-org-apache-sling-models-jacksonexporter/commit/66a0c832c57e40b85a33b8a0463fc05383057d87] * [https://github.com/apache/sling-org-apache-sling-models-jacksonexporter/commit/777eaffa7851722bc5a2eceef7ffcc3701df266d] models caconfig * [https://github.com/apache/sling-org-apache-sling-models-caconfig/commit/098970bb8e0ad0da65348756a93be02071986d38] * [https://github.com/apache/sling-org-apache-sling-models-caconfig/commit/f043041308758eca9138fb42e04643fd612a1bd0] * [https://github.com/apache/sling-org-apache-sling-models-caconfig/commit/a63749c6608c9f2e737dfe5f6f00b217cb7afa42] models bnd plugin * [https://github.com/apache/sling-org-apache-sling-bnd-models/commit/4b7ee02af75cd1e4684064c28affd6981d227d39] * [https://github.com/apache/sling-org-apache-sling-bnd-models/commit/0e11beb1435229fc18310abf5e4a8719952e4d2d] * [https://github.com/apache/sling-org-apache-sling-bnd-models/commit/211d811d62dc1096f057209448792b6eb031bc2c] > Models: Update to Parent 60, Java 11 Minimum Version > > > Key: SLING-12360 > URL: https://issues.apache.org/jira/browse/SLING-12360 > Project: Sling > Issue Type: Improvement > Components: Sling Models >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: Models Context-Aware Configuration 1.0.4, Models > Implementation 1.7.0, Models Jackson Exporter 1.1.6, Sling Models bnd Plugin > 1.0.2 > > > 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-12361) caconfig: Update to Parent 60, Java 11 Minimum Version
[ https://issues.apache.org/jira/browse/SLING-12361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert resolved SLING-12361. Resolution: Fixed api * [https://github.com/apache/sling-org-apache-sling-caconfig-api/commit/e20383050d57bfd549c7afcd616873583c0cfaff] * [https://github.com/apache/sling-org-apache-sling-caconfig-api/commit/3278436d6b9a86702067c0b3812010f5fba3a3aa] * [https://github.com/apache/sling-org-apache-sling-caconfig-api/commit/f78856e56fb024f3191436d72706e7914f733b99] spi * [https://github.com/apache/sling-org-apache-sling-caconfig-spi/commit/794bf3387100902ec47c4a785803f2bc3473da15] * [https://github.com/apache/sling-org-apache-sling-caconfig-spi/commit/da624284af085acec003dfa96db5ff753b348d8d] * [https://github.com/apache/sling-org-apache-sling-caconfig-spi/commit/3a9399466b0af35d7c7f2e9110d1c2178574906e] impl * [https://github.com/apache/sling-org-apache-sling-caconfig-impl/commit/9c31071e482e3af758f166f3a332a561157d8611] * [https://github.com/apache/sling-org-apache-sling-caconfig-impl/commit/91dd7cb4fa07252beeac7ac2a8c6c2e80713a8fc] * [https://github.com/apache/sling-org-apache-sling-caconfig-impl/commit/9f5f501b0f8dc36e26889e693c1b82aed0c83088] bnd plugin * [https://github.com/apache/sling-org-apache-sling-caconfig-bnd-plugin/commit/80577e102c746ae8e8f66e1b709c1dfe2d3789d8] * [https://github.com/apache/sling-org-apache-sling-caconfig-bnd-plugin/commit/de19fab14fbf05e06d6897047688439fb721b46e] * [https://github.com/apache/sling-org-apache-sling-caconfig-bnd-plugin/commit/2d9039395e1676cb39317c2b0fb198bc7e9a0ba1] > caconfig: Update to Parent 60, Java 11 Minimum Version > -- > > Key: SLING-12361 > URL: https://issues.apache.org/jira/browse/SLING-12361 > Project: Sling > Issue Type: Improvement > Components: Extensions >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: Context-Aware Configuration bnd Plugin 1.0.4, > Context-Aware Configuration API 1.3.2, Context-Aware Configuration SPI 1.4.2, > Context-Aware Configuration Impl 1.6.2 > > > 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-12359) Sling Models: Support constructor injection for Java Record classes
[
https://issues.apache.org/jira/browse/SLING-12359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert resolved SLING-12359.
Resolution: Fixed
https://github.com/apache/sling-org-apache-sling-models-impl/commit/9d1c72501226d3dfdfb0644c5632f5e29be5370e
> Sling Models: Support constructor injection for Java Record classes
> ---
>
> Key: SLING-12359
> URL: https://issues.apache.org/jira/browse/SLING-12359
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Affects Versions: Models Implementation 1.6.4
>Reporter: Herman Ciechanowiec
>Assignee: Stefan Seifert
>Priority: Major
> Fix For: Models Implementation 1.6.6
>
>
> Java 14 introduced support for record classes, and Apache Sling 12 by default
> runs with Java 17, allowing the use of records.
> Although Apache Sling 12 supports record classes, the current latest version
> of Apache Sling Models Implementation does not fully support injection in
> relation to records. Specifically, for records, the Apache Sling Models
> Implementation *does* support constructor injection similarly to a usual
> class if there is an *explicit* constructor annotated with
> `javax.inject.Inject`:
> {code:java}
> @Model(
> adaptables = {Resource.class, SlingHttpServletRequest.class},
> defaultInjectionStrategy = DefaultInjectionStrategy.REQUIRED
> )
> public record StudentModel(String name, int age) {
> @Inject
> public StudentModel(
> @ValueMapValue(name = "name") @Default(values = "unknown")
> String name,
> @ValueMapValue(name = "age") @Default(intValues = 0)
> int age
> ) {
> this.name = name;
> this.age = age;
> }
> }
> {code}
> However, for records, Apache Sling Models Implementation *does not* support
> constructor injection if there is an *implicit* constructor. Such a
> constructor cannot be annotated with `javax.inject.Inject` and will not be
> picked up during injection. Therefore, such a Sling Model will not be
> instantiated at all:
> {code:java}
> @Model(
> adaptables = {Resource.class, SlingHttpServletRequest.class},
> defaultInjectionStrategy = DefaultInjectionStrategy.REQUIRED
> )
> public record StudentModel(
> @ValueMapValue(name = "name") @Default(values = "unknown")
> String name,
> @ValueMapValue(name = "age") @Default(intValues = 0)
> int age
> ) {}
> {code}
> The above issue should be addressed by introducing support for injection in
> records' implicit constructors.
> Note:
> 1. For records, only constructor injection is supported since records cannot
> have instance fields (code with such fields will not compile).
> 2. Apache Sling Models Implementation is currently based on Java 8 and may
> also be executed in a Java 8 environment. Therefore, the records check should
> be introduced via dynamic loading of the `java.lang.Record` class.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-12359) Sling Models: Support constructor injection for Java Record classes
[
https://issues.apache.org/jira/browse/SLING-12359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert updated SLING-12359:
---
Summary: Sling Models: Support constructor injection for Java Record
classes (was: Extend records support)
> Sling Models: Support constructor injection for Java Record classes
> ---
>
> Key: SLING-12359
> URL: https://issues.apache.org/jira/browse/SLING-12359
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Affects Versions: Models Implementation 1.6.4
>Reporter: Herman Ciechanowiec
>Assignee: Stefan Seifert
>Priority: Major
> Fix For: Models Implementation 1.6.6
>
>
> Java 14 introduced support for record classes, and Apache Sling 12 by default
> runs with Java 17, allowing the use of records.
> Although Apache Sling 12 supports record classes, the current latest version
> of Apache Sling Models Implementation does not fully support injection in
> relation to records. Specifically, for records, the Apache Sling Models
> Implementation *does* support constructor injection similarly to a usual
> class if there is an *explicit* constructor annotated with
> `javax.inject.Inject`:
> {code:java}
> @Model(
> adaptables = {Resource.class, SlingHttpServletRequest.class},
> defaultInjectionStrategy = DefaultInjectionStrategy.REQUIRED
> )
> public record StudentModel(String name, int age) {
> @Inject
> public StudentModel(
> @ValueMapValue(name = "name") @Default(values = "unknown")
> String name,
> @ValueMapValue(name = "age") @Default(intValues = 0)
> int age
> ) {
> this.name = name;
> this.age = age;
> }
> }
> {code}
> However, for records, Apache Sling Models Implementation *does not* support
> constructor injection if there is an *implicit* constructor. Such a
> constructor cannot be annotated with `javax.inject.Inject` and will not be
> picked up during injection. Therefore, such a Sling Model will not be
> instantiated at all:
> {code:java}
> @Model(
> adaptables = {Resource.class, SlingHttpServletRequest.class},
> defaultInjectionStrategy = DefaultInjectionStrategy.REQUIRED
> )
> public record StudentModel(
> @ValueMapValue(name = "name") @Default(values = "unknown")
> String name,
> @ValueMapValue(name = "age") @Default(intValues = 0)
> int age
> ) {}
> {code}
> The above issue should be addressed by introducing support for injection in
> records' implicit constructors.
> Note:
> 1. For records, only constructor injection is supported since records cannot
> have instance fields (code with such fields will not compile).
> 2. Apache Sling Models Implementation is currently based on Java 8 and may
> also be executed in a Java 8 environment. Therefore, the records check should
> be introduced via dynamic loading of the `java.lang.Record` class.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12360) Models: Update to Parent 60, Java 11 Minimum Version
[ https://issues.apache.org/jira/browse/SLING-12360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17859666#comment-17859666 ] Stefan Seifert commented on SLING-12360: excluding [https://github.com/apache/sling-org-apache-sling-models-validation-impl] and [https://github.com/apache/sling-org-apache-sling-models-integration-tests] here as those rely on outdated integration test infrastructure with an old sling version not compatible with java 17+ - this has to be handled in a separate ticket. > Models: Update to Parent 60, Java 11 Minimum Version > > > Key: SLING-12360 > URL: https://issues.apache.org/jira/browse/SLING-12360 > Project: Sling > Issue Type: Improvement > Components: Sling Models >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: Models Context-Aware Configuration 1.0.4, Models > Implementation 1.6.6, Models Jackson Exporter 1.1.6, Sling Models bnd Plugin > 1.0.2 > > > 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] [Updated] (SLING-12360) Models: Update to Parent 60, Java 11 Minimum Version
[ https://issues.apache.org/jira/browse/SLING-12360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert updated SLING-12360: --- Fix Version/s: (was: Models Validation Impl 1.1.2) > Models: Update to Parent 60, Java 11 Minimum Version > > > Key: SLING-12360 > URL: https://issues.apache.org/jira/browse/SLING-12360 > Project: Sling > Issue Type: Improvement > Components: Sling Models >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: Models Context-Aware Configuration 1.0.4, Models > Implementation 1.6.6, Models Jackson Exporter 1.1.6, Sling Models bnd Plugin > 1.0.2 > > > 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-12360) Models: Update to Parent 60, Java 11 Minimum Version
[ https://issues.apache.org/jira/browse/SLING-12360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17859651#comment-17859651 ] Stefan Seifert commented on SLING-12360: models api already updated to parent 60 in SLING-12273 > Models: Update to Parent 60, Java 11 Minimum Version > > > Key: SLING-12360 > URL: https://issues.apache.org/jira/browse/SLING-12360 > Project: Sling > Issue Type: Improvement > Components: Sling Models >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: Models Validation Impl 1.1.2, Models Context-Aware > Configuration 1.0.4, Models Implementation 1.6.6, Models Jackson Exporter > 1.1.6, Sling Models bnd Plugin 1.0.2 > > > 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] [Updated] (SLING-12360) Models: Update to Parent 60, Java 11 Minimum Version
[ https://issues.apache.org/jira/browse/SLING-12360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert updated SLING-12360: --- Fix Version/s: (was: Models API 1.5.2) > Models: Update to Parent 60, Java 11 Minimum Version > > > Key: SLING-12360 > URL: https://issues.apache.org/jira/browse/SLING-12360 > Project: Sling > Issue Type: Improvement > Components: Sling Models >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: Models Validation Impl 1.1.2, Models Context-Aware > Configuration 1.0.4, Models Implementation 1.6.6, Models Jackson Exporter > 1.1.6, Sling Models bnd Plugin 1.0.2 > > > 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] [Updated] (SLING-12360) Models: Update to Parent 60, Java 11 Minimum Version
[ https://issues.apache.org/jira/browse/SLING-12360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert updated SLING-12360: --- Fix Version/s: Sling Models bnd Plugin 1.0.2 > Models: Update to Parent 60, Java 11 Minimum Version > > > Key: SLING-12360 > URL: https://issues.apache.org/jira/browse/SLING-12360 > Project: Sling > Issue Type: Improvement > Components: Sling Models >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: Models Validation Impl 1.1.2, Models Context-Aware > Configuration 1.0.4, Models API 1.5.2, Models Implementation 1.6.6, Models > Jackson Exporter 1.1.6, Sling Models bnd Plugin 1.0.2 > > > 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-12361) caconfig: Update to Parent 60, Java 11 Minimum Version
Stefan Seifert created SLING-12361: -- Summary: caconfig: Update to Parent 60, Java 11 Minimum Version Key: SLING-12361 URL: https://issues.apache.org/jira/browse/SLING-12361 Project: Sling Issue Type: Improvement Components: Extensions Reporter: Stefan Seifert Assignee: Stefan Seifert Fix For: Context-Aware Configuration bnd Plugin 1.0.4, Context-Aware Configuration API 1.3.2, Context-Aware Configuration SPI 1.4.2, Context-Aware Configuration Impl 1.6.2 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-12360) Models: Update to Parent 60, Java 11 Minimum Version
Stefan Seifert created SLING-12360: -- Summary: Models: Update to Parent 60, Java 11 Minimum Version Key: SLING-12360 URL: https://issues.apache.org/jira/browse/SLING-12360 Project: Sling Issue Type: Improvement Components: Sling Models Reporter: Stefan Seifert Assignee: Stefan Seifert Fix For: Models Validation Impl 1.1.2, Models Context-Aware Configuration 1.0.4, Models API 1.5.2, Models Implementation 1.6.6, Models Jackson Exporter 1.1.6 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] [Assigned] (SLING-12359) Extend records support
[
https://issues.apache.org/jira/browse/SLING-12359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert reassigned SLING-12359:
--
Assignee: Stefan Seifert
Priority: Major (was: Blocker)
> Extend records support
> --
>
> Key: SLING-12359
> URL: https://issues.apache.org/jira/browse/SLING-12359
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Affects Versions: Models Implementation 1.6.4
>Reporter: Herman Ciechanowiec
>Assignee: Stefan Seifert
>Priority: Major
> Fix For: Models Implementation 1.6.6
>
>
> Java 14 introduced support for record classes, and Apache Sling 12 by default
> runs with Java 17, allowing the use of records.
> Although Apache Sling 12 supports record classes, the current latest version
> of Apache Sling Models Implementation does not fully support injection in
> relation to records. Specifically, for records, the Apache Sling Models
> Implementation *does* support constructor injection similarly to a usual
> class if there is an *explicit* constructor annotated with
> `javax.inject.Inject`:
> {code:java}
> @Model(
> adaptables = {Resource.class, SlingHttpServletRequest.class},
> defaultInjectionStrategy = DefaultInjectionStrategy.REQUIRED
> )
> public record StudentModel(String name, int age) {
> @Inject
> public StudentModel(
> @ValueMapValue(name = "name") @Default(values = "unknown")
> String name,
> @ValueMapValue(name = "age") @Default(intValues = 0)
> int age
> ) {
> this.name = name;
> this.age = age;
> }
> }
> {code}
> However, for records, Apache Sling Models Implementation *does not* support
> constructor injection if there is an *implicit* constructor. Such a
> constructor cannot be annotated with `javax.inject.Inject` and will not be
> picked up during injection. Therefore, such a Sling Model will not be
> instantiated at all:
> {code:java}
> @Model(
> adaptables = {Resource.class, SlingHttpServletRequest.class},
> defaultInjectionStrategy = DefaultInjectionStrategy.REQUIRED
> )
> public record StudentModel(
> @ValueMapValue(name = "name") @Default(values = "unknown")
> String name,
> @ValueMapValue(name = "age") @Default(intValues = 0)
> int age
> ) {}
> {code}
> The above issue should be addressed by introducing support for injection in
> records' implicit constructors.
> Note:
> 1. For records, only constructor injection is supported since records cannot
> have instance fields (code with such fields will not compile).
> 2. Apache Sling Models Implementation is currently based on Java 8 and may
> also be executed in a Java 8 environment. Therefore, the records check should
> be introduced via dynamic loading of the `java.lang.Record` class.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12352) ContentLoader XML / JSON initialisation should be done in a lazy way (when needed)
[ https://issues.apache.org/jira/browse/SLING-12352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17856766#comment-17856766 ] Stefan Seifert commented on SLING-12352: [~Henry Kuijpers] as the PR is merged, please set this ticket to resolved as well, and assign it to yourself. > ContentLoader XML / JSON initialisation should be done in a lazy way (when > needed) > -- > > Key: SLING-12352 > URL: https://issues.apache.org/jira/browse/SLING-12352 > Project: Sling > Issue Type: Bug > Components: Testing >Affects Versions: Testing Sling Mock 3.5.0 >Reporter: Henry Kuijpers >Priority: Major > Fix For: Testing Sling Mock 3.5.2 > > > When calling context.load(), a content loader is created in a lazy way (when > it's not there, it is instantiated and otherwise a cached instance is > returned). > However, when instantiating this content loader, everything needed for XML & > JSON is set up, regardless of calls to json() or xml() being made or not. > This should also be done in a lazy way. > > A specific issue that can be tackled this way is running parallel tests in > combination with XML parsers and their ugly statics, interfering with each > other. > This would tackle the "No page manager." / "No asset manager." errors that > can be seen when using AemContext. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12352) ContentLoader XML / JSON initialisation should be done in a lazy way (when needed)
[ https://issues.apache.org/jira/browse/SLING-12352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17855832#comment-17855832 ] Stefan Seifert commented on SLING-12352: looks good to me > ContentLoader XML / JSON initialisation should be done in a lazy way (when > needed) > -- > > Key: SLING-12352 > URL: https://issues.apache.org/jira/browse/SLING-12352 > Project: Sling > Issue Type: Bug > Components: Testing >Affects Versions: Testing Sling Mock 3.5.0 >Reporter: Henry Kuijpers >Priority: Major > > When calling context.load(), a content loader is created in a lazy way (when > it's not there, it is instantiated and otherwise a cached instance is > returned). > However, when instantiating this content loader, everything needed for XML & > JSON is set up, regardless of calls to json() or xml() being made or not. > This should also be done in a lazy way. > > A specific issue that can be tackled this way is running parallel tests in > combination with XML parsers and their ugly statics, interfering with each > other. > This would tackle the "No page manager." / "No asset manager." errors that > can be seen when using AemContext. -- 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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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 par
[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&focusedCommentId=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
java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTr
[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&focusedCommentId=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)
