Hi JB, The start level is being used by the karaf-maven-plugin to group and sort the bundles that appear in the startup.properties. We are simply adding the karaf framework feature and our boot feature as compile level dependencies to the maven project. This has the effect of adding all bundles listed in the features to the startup.properties file. Defining the features as "boot" or "startup" in the configuration of the maven plugin has no effect for these services.
The idea of using this method is to ensure that we get a fast and repeatable boot process for the karaf platform. Typically we have 180 bundles listed in the startup file that includes the jetty platform as defined in the pax-web features. Once this is complete then our application deployer will use the normal OSGI behaviour to deploy our service bundles, typically this is around 600 bundles for each server. Regards Paul From: "Jean-Baptiste Onofre" <j...@nanthrax.net> To: dev@karaf.apache.org Date: 11/05/2021 16:10 Subject: Re: Non-Deterministic startup order Hi Paul, You are mixing two things: the generation of the startup.properties at build time, and the actual order at runtime. My point was about the start level at runtime, not build/startup.properties generation. We use start-level in Karaf to define the order, and it’s cleanly sorted. What we do is to pass the start level in the features definition: https://github.com/apache/karaf/blob/main/assemblies/features/framework/src/main/feature/feature.xml <https://github.com/apache/karaf/blob/main/assemblies/features/framework/src/main/feature/feature.xml> Then, we define the feature as startupFeature and the startup.properties is generated using the start-level defined in the feature definition. Do you use the same approach or directly startupBundles ? Regards JB > Le 11 mai 2021 à 16:38, Paul Stanley <pj.stan...@live.co.uk> a écrit : > > Hello. > > I have tested the proposed 4.3.2 release and the startup.properties file is > still being generated in a non- deterministic order. They are grouped in > their start level, but within that they are listed in a random order. > > The issue we have been seeing relates to the jetty distribution which listed > in the startup.properties file as part of our custom installation, given the > unpredictable order has led to the web server restarting a number of times > during the boot cycle, this in turn can prevent karaf from starting. > > It appears that the problem is in the builder class in the profile project. > This does attempt to sort the bundles, but the startupEffective.getBundles() > list is empty and as such the sort operation has no effect. Would it be > possible to updated the resolve() method and the MapUtils class to use > LinkedHashMaps when using the Collectors.toMap() stream operations. > > Thanks > Paul > > ________________________________ > From: Romain Manni-Bucau <rmannibu...@gmail.com> > Sent: 05 May 2021 16:10 > To: dev <dev@karaf.apache.org> > Subject: Re: Non-Deterministic startup order > > Hi Paul, > > Did you use the last 4.3 release? Startup bundles shouldn't be randomized > anymore. For features it is a bit more complicated since it is a tree so > guess order can't really be assumed without side effects (whereas it can > for a flat list of bundles). > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/application-development/java-ee-8-high-performance> > > > Le mer. 5 mai 2021 à 17:07, Paul Stanley <pj.stan...@live.co.uk> a écrit : > >> Hi. >> >> When building and running karaf the boot order for the initial set of >> startup bundles is being randomised, within their start levels. As result >> we are seeing non-deterministic behaviour between development and release >> builds of custom karaf platforms. >> >> Please can you change the karaf.features.core and the karaf.profile.core >> to use LinkedHashMaps and Sets, to preserve the order of bundles as >> discovered in the feature.xml files. >> >> Thanks >> Paul >> >>
