This is an automated email from the ASF dual-hosted git repository.
cziegeler pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/sling-whiteboard.git
The following commit(s) were added to refs/heads/master by this push:
new d38b921 Adjust sections about start levels
d38b921 is described below
commit d38b921139f88c0b72aa9559bbd2e6ae7ff5bce6
Author: Carsten Ziegeler <cziege...@apache.org>
AuthorDate: Mon Nov 6 12:59:33 2017 +0100
Adjust sections about start levels
---
featuremodel/feature/readme.md | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/featuremodel/feature/readme.md b/featuremodel/feature/readme.md
index facc995..6dbfc07 100644
--- a/featuremodel/feature/readme.md
+++ b/featuremodel/feature/readme.md
@@ -1,4 +1,4 @@
-# Prototype for a new Provisioning Model - Configuration Model for OSGi based
applications
+# Prototype for a new Provisioning / Configuration Model for OSGi based
applications
The current model to describe OSGi applications is based on Apache Sling's
provisioning model (see
https://sling.apache.org/documentation/development/slingstart.html)
@@ -116,11 +116,9 @@ A feature itself has no special support for environments
(prod, test, dev). In p
# Bundles and start levels
-For bundles there is no default start level - a default start level is not
defined in the OSGi spec. And in addition, it is a little bit confusing when
looking at the model when there is a list of artifacts without a start level.
Which start level do these have? Its better to be explicit.
+Each bundle needs to be explicitly assigned to a start level. There is no
default start level as a default start level is not defined in the OSGi spec.
In addition, it is a little bit confusing when looking at the model when there
is a list of bundles without a start level. Which start level do these have? It
is better to be explicit.
-In the current PoC, a bundle needs to be explicitely assigned to a start
level. This seems to be only working if you know all the features in advance
and how they are structured. On the other hand there needs to be a way to
define the start order of bundles within a feature. Therefore we can use the
start level information as an ordering information for the bundles within a
feature. Bundles within the same start level are started in any order.
-
-Proposal: We use the format as it is today, but interpret the start level
value different: instead of directly mapping it to a start level in the OSGi
framework, it defines just the startup order of bundles within a feature.
Features are then started in respect of their dependency information. Even if a
feature has no requirement with respect to start ordering of their bundles, it
has to define a start level (to act as a container for the bundles). It can use
any positive number, suggest [...]
+However as soon as you have more than one feature and especially if these are
authored by different authors, start level handling becomes more tricky.
Assigning correct OSGi start levels in such scenarios would require to know all
features upfront. Therefore this start level information is interpret as
follows: instead of directly mapping it to a start level in the OSGi framework,
it defines just the startup order of bundles within a feature. Features are
then started in respect of their [...]
# Configurations belonging to Bundles
--
To stop receiving notification emails like this one, please contact
['"commits@sling.apache.org" <commits@sling.apache.org>'].
