[
https://issues.apache.org/jira/browse/SLING-5337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15037677#comment-15037677
]
Oliver Lietz commented on SLING-5337:
-------------------------------------
bq. Just a side note: we don't need start levels in the Launchpad, it's just an
optimization for the startup
This is not entirely true. Tika needs to be activated before Jackrabbit. And
here is another one: OAK-2910.
bq. We don't have to define which conditions have to be met to register that
service
We have to define when startup is finished in a general way. In my opinion the
_conditions_ should be the availability of services and capabilities (taking
additional conditions like start level into account is ok).
The base conditions should be the same for every launcher otherwise you will
see strange effects. Suppose you have a bundle which expects JCR to be
available when startup is finished. This may be true on our Launchpad but not
necessarily on a custom Launchpad or Karaf because a minimal Sling works
without JCR.
bq. At least with subsystems you know that all bundles are installed and
started, so simply adding a service based check does the trick. Maybe it's
similar with Karaf?
Yes, we could exploit the Features/Resolver API. Though after playing for a
while with a configurable Startup Handler (SLING-5338) it seems that this
approach is versatile and general and _good enough_.
bq. I have started a Capability-based readiness detection?
I have thought about adding a Capability check later to configurable Startup
Handler.
Taking a step back, the Startup handling came after Sling 6:
* Do we really need it?
* What are the use cases?
* Should Sling modules (e.g. discovery) use it at all?
* Should it be removed from Sling Settings?
> Extract Startup API from Launchpad API
> --------------------------------------
>
> Key: SLING-5337
> URL: https://issues.apache.org/jira/browse/SLING-5337
> Project: Sling
> Issue Type: Improvement
> Components: Launchpad
> Affects Versions: Launchpad API 1.2.0
> Reporter: Oliver Lietz
> Assignee: Oliver Lietz
> Fix For: Launchpad API 1.3.0, Startup API 1.0.0
>
>
> {{StartupHandler}}, {{StartupListener}}, {{StartupMode}} and
> {{StartupService}} in {{org.apache.sling.launchpad.api}} should be moved to
> {{org.apache.sling.startup.api}} (keeping extending but deprecated classes
> there for backward compatibility) to decouple Startup from Launchpad.
> A Startup implementation in Sling needs to be provided by every launcher
> (Launchpad, Crankstart, Karaf)\[1\] whereas {{LaunchpadContentProvider}} is
> only useful in contexts of Sling's own launcher Launchpad for installation
> purpose.
> [~cziegeler], [~bdelacretaz]: anything from your POVs to consider?
> \[1\] We discussed to make Startup optional in {{Settings}} but that won't
> work as we have modules which rely already on it (e.g. {{discovery}}).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
