[
https://issues.apache.org/jira/browse/SLING-8843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16973160#comment-16973160
]
Carsten Ziegeler commented on SLING-8843:
-----------------------------------------
Repoinit provides a strong contract: if the repository is available repoinit is
successfully processed - switching to a best effort approach is asking for
trouble. No one checks the log and will notice that some repoinit instruction
is not successfully processed. Or in automated setups this will not be noticed
at all.
So I rather would stay away for this - I'm fine with having like a developer
mode switch which can be enabled to allow for best effort - but the default
must be to fail the setup
> exceptions on repoinit break construction of the SlingRepository service
> ------------------------------------------------------------------------
>
> Key: SLING-8843
> URL: https://issues.apache.org/jira/browse/SLING-8843
> Project: Sling
> Issue Type: Improvement
> Components: Repoinit
> Affects Versions: Repoinit JCR 1.1.14
> Reporter: Jörg Hoh
> Priority: Major
>
> The repoinit statements are executed during the construction of the
> SlingRepository instance; and if currently an exception is thrown at that
> level (for whatever reason), this exception is propagated up to the
> construction of the SlingRepository service, which is then terminated. As a
> consequence the SlingRepository is not available which makes the application
> unusable.
> While this should never happen, any occurrence of it makes fixing it harder,
> especially if the analysis requires to have a look at the content within the
> repository.
> Thus i would request, that all type of exceptions thrown within repoinit are
> caught and logged, but do not propagated.
> (Especially if you play with repoinit statements you have a high chance, that
> you boostrap your instance multiple times if you don't get it right the first
> time.)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
