+1 for b) Stefan, I reviewed your feedback to PR #13 and have applied an improvement that should reduce the log message noise to one WARN message per affected bundle and no stack trace to fill up the log file. Hopefully that addresses your concerns.
I'd like to hear more about 'c)', it seems like you may be saying that you want to defer all Content-Loading until all of the configured 'defaultRequireImportProviders' are satisfied? I'm not sure that is better than 'b)' since you may encounter a situation where you are waiting for something that never arrives and is never used. Regards, -Eric On Thu, Mar 10, 2022 at 8:33 AM Stefan Seifert <[email protected]> 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: > > 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 >
