[
https://issues.apache.org/jira/browse/SLING-3529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13987646#comment-13987646
]
Carsten Ziegeler commented on SLING-3529:
-----------------------------------------
I totally agree that depending on start levels is not a good idea - and
actually the startup handling we have here is intended to improve the
install/update scenario by having a more sophisticated startup behaviour. While
the instance would start up without this special handler, it starts up more
smoothly with it. Especially if things happen asynchronously the framework
moves to the next start level, starting new bundles while the once from the
previous level are not finished with startup. With this startup handler, the
framework waits before entering the next start level. We have seen that initial
startups and updates are way smoother with this control in place than without -
but again, the initial startup would work without it. On a restart, the handler
does nothing.
And this is an optional bundle - so it's up to the app assembler to add it or
not.
Therefore this is different from capability checking
> Move startup handling to a separate bundle
> ------------------------------------------
>
> Key: SLING-3529
> URL: https://issues.apache.org/jira/browse/SLING-3529
> Project: Sling
> Issue Type: New Feature
> Components: Launchpad
> Reporter: Carsten Ziegeler
> Assignee: Carsten Ziegeler
> Fix For: Launchpad Base 2.5.2, Launchpad Impl 1.0.0
>
>
> The startup handler is currently embedded in the Sling launchpad base - which
> makes it impossible to use when Sling is installed in another container like
> e.g. Apache Karaf.
> We should move this to a separate bundle to make it more reusable
--
This message was sent by Atlassian JIRA
(v6.2#6252)
