[
https://issues.apache.org/jira/browse/SLING-5337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031743#comment-15031743
]
Oliver Lietz commented on SLING-5337:
-------------------------------------
So this is becoming more or less a _lifecycle_ API for Sling.
In Launchpad (and probably in Crankstart) the lifecycle (startup) handling of
Sling is tightly coupled to the OSGi framework on the assumption that Sling is
the only application running in the OSGi container. Both assume there is a
fixed set of bundles.
Current startup handling does not consider stopping and (re)starting or
updating bundles in a running Launchpad. I would call this (manually) executed
procedures _unmanaged_.
On the other hand I would call installation or updates with restart in
Launchpad (and Crankstart) or by _Features_ in Karaf or OSGi Subsystems
_managed_.
In Karaf - when using Karaf Features - you usually have a running container and
install applications to it. Sling will run besides other applications in that
container probably.
When using Karaf Features you also don't need start levels\[1\] (and no start
level managing by Sling) because the installation of bundles runs much more
controlled due to options for expressing dependencies of Features.
The behavior of an application (Sling) when installed as Karaf Feature or OSGi
Subsystem should be similar ([~bosschaert]?).
Do we want to support _unmanaged_ restarts and updates of bundles and
installing additional bundles (or Features) within implementations of the
_lifecycle_ API?
What forms a startup and shutdown of Sling? What is an update? It cannot be the
startup and shutdown of the OSGi framework when making this API general. And it
cannot be the date modified of _all_ bundles to compute an update of Sling.
Is a startup finished when essential services are up and running? e.g.
{{org.apache.sling.engine.SlingRequestProcessor}} and
{{org.apache.sling.api.resource.ResourceResolverFactory}}, SLING-5337
\[1\] at least with Jackrabbit, has to be verified with Oak but looks good so
far
> 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)
