Re: [Content Loader] Decide on approach to unblock Sling 12
On Mon, 2022-03-14 at 10:46 +, Stefan Seifert wrote: > 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. > Sounds good, thanks Stefan! I kicked off a second release vote, hopefully this time it goes smoother :-) Thanks, Robert > 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 > > Sent: Thursday, March 10, 2022 6:08 PM > > To: dev@sling.apache.org > > 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 +, 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/Secu > > rityProv > > iderRegistration.java
RE: [Content Loader] Decide on approach to unblock Sling 12
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 >Sent: Thursday, March 10, 2022 6:08 PM >To: dev@sling.apache.org >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 +, 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
Re: [Content Loader] Decide on approach to unblock Sling 12
+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 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 >
Re: [Content Loader] Decide on approach to unblock Sling 12
+1 for a) for now. Afterwards we can take some time and probably do c) or improve b) by waiting for the service to become active (in case it is resolvable in the current system). Konrad > On 10. Mar 2022, at 17:33, 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: > > 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
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 +, 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/SecurityProviderRegistration.java
RE: [Content Loader] Decide on approach to unblock Sling 12
+1 for either a) or c) from my side stefan
