sling-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dav...@apache.org
Subject [sling-org-apache-sling-feature] 03/22: Adjust sections about start levels
Date Fri, 27 Apr 2018 09:51:23 GMT
This is an automated email from the ASF dual-hosted git repository.

davidb pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/sling-org-apache-sling-feature.git

commit a5091906bdf9ec63b159251410b50c6e1b2d26eb
Author: Carsten Ziegeler <cziegeler@apache.org>
AuthorDate: Mon Nov 6 12:59:33 2017 +0100

    Adjust sections about start levels
---
 readme.md | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/readme.md b/readme.md
index facc995..6dbfc07 100644
--- a/readme.md
+++ b/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
davidb@apache.org.

Mime
View raw message