hello robert. as intermediate solution i've merged a) and closed SLING-11189, so from my point of view we can continue sling 12 release together with a release of JCR ContentLoader 2.5.2 with the two fixed issues [6]. the remaining issues from 2.5.2 can be moved to a next version imho.
stefan [6] https://issues.apache.org/jira/issues/?jql=project%20%3D%20SLING%20AND%20fixVersion%20%3D%20%22JCR%20ContentLoader%202.5.2%22 >-----Original Message----- >From: Robert Munteanu <[email protected]> >Sent: Thursday, March 10, 2022 6:08 PM >To: [email protected] >Subject: Re: [Content Loader] Decide on approach to unblock Sling 12 > >Hi Stefan, > >Thanks for setting this up, very helpful. > >On Thu, 2022-03-10 at 16:33 +0000, Stefan Seifert wrote: >> during release process of Sling 12 we discovered SLING-11189 [1] >> which happens only on certain windows environments, but is there a >> blocker as Sling-Initial-Content from bundles like composum (may >> affect other apps as well) are corrupted during extraction, actually >> breaking the application. the root cause is a race condition on sling >> startup where the content reader implementations are registered after >> the whiteboard for handling them is registered, and after the first >> bundles are actually processed. >> >> to solve this we have multiple approaches, i want to do a quick vote >> on these options to unblock the release: > >Any of a-z would actually work for me. I would prefer we don't lose the >benefit of declarative services, if at all possible. > >One constraint I would like us to keep is to not log additional >WARN/ERROR entries, so b) would likely need to be combined with a) into >c), or be adjusted. > >FWIW, this is how this is how a similar problem is approached in Oak >[5]. > >Thanks, >Robert >> >> a) apply only PR #12 [2] which simply defines a mandatory dependency >> between the whiteboard and the 4 built-in readers via DS. the list of >> mandatory readers is hardcoded in the code. >> >> b) apply only PR #13 [3] which introduces a new directive >> "requireImportProviders" allowing bundles to actually define which >> import providers they depend on, and if those are not there the >> importing of the initial content is delayed until they become >> available. if the directive is missing a default list is assumed >> which is configurable via OSGi (and defaults to the 4 built-in >> readers). the current implementation has the small drawback that it >> prints out some error messages in case the bundle processing is >> delayed, even if it's only for a few milliseconds due to sling >> startup. >> >> c) combine PR #12 [2] and PR #13 [3] to avoid the error messages for >> the built-in readers. >> >> d) look for other solutions, e.g. implementing a) "the other way >> around" by having the whiteboard register the reader implementations >> itself, which probably means moving away from DS for those reader >> service implementations. >> >> z) take more time for discussing the options a)-d) and go with >> workaround from [4] for Sling 12 which fixes this issue via >> configuration only for Sling Starter, not in the content loader >> bundle itself. >> >> please cast your votes on this options. >> >> stefan >> >> [1] https://issues.apache.org/jira/browse/SLING-11189 >> [2] >> https://github.com/apache/sling-org-apache-sling-jcr- >contentloader/pull/12 >> [3] >> https://github.com/apache/sling-org-apache-sling-jcr- >contentloader/pull/13 >> [4] https://github.com/apache/sling-org-apache-sling-starter/pull/59 > >[5]: >https://github.com/apache/jackrabbit-oak/blob/trunk/oak- >core/src/main/java/org/apache/jackrabbit/oak/security/internal/SecurityProv >iderRegistration.java
