Honestly, we haven't been using K4 much. I'm going to try to bring up one of our more troubling scenarios in K3 (< 3.0.8) and see what happens in K4. Thanks for the explanation, Guillaume! Hopefully K4 "just works"! :)
On Fri, Aug 26, 2016 at 10:05 AM Guillaume Nodet <[email protected]> wrote: > Yeah, that's actually the only case where the bundle is is important afaik. > > However, when using Karaf 4 feature service, things are slightly different > : let's say you have 2 features, each feature containing a bundle which > export the same package but in different version. If a single bundle can > be used (that would mean they are flagged as dependencies), the feature > service will only install one bundle. At the end, if bundles flagged as > dependencies won't be used in the wiring, they won't be installed at all. > > 2016-08-26 15:21 GMT+02:00 James Carman <[email protected]>: > >> The bundle id is important, especially when trying to resolve the same >> packages from multiple bundles, because the lower bundle id is supposed to >> be chosen when there are multiple options for the same dependency range. >> That's what I'm trying to control mostly. >> >> >> On Fri, Aug 26, 2016 at 8:59 AM Guillaume Nodet <[email protected]> >> wrote: >> >>> The installation order is not really relevent, what is important is the >>> startup order. >>> Once the list of bundles has been computed, the features service does >>> the following: >>> #1: stop bundles that needs to be updated or uninstalled in order >>> #2: uninstall needed bundles >>> #3: update regions >>> #4: update bundles >>> #5: install bundles >>> #6: save state >>> #7: install configuration >>> #8: refresh bundles >>> #9: start bundles in order >>> #10: send events >>> >>> For point #9, bundles are split in multiple sets according to their >>> their order, and in each set, they are sorted in a way that will try to >>> ensure the bundles are correctly and fully resolved (see FELIX-2949, >>> because Felix resolver is not greedy). >>> >>> What's the problem you're trying to solve exactly ? >>> >>> 2016-08-26 13:56 GMT+02:00 James Carman <[email protected]>: >>> >>>> Wonderful. Something needs to be done about that, then. >>>> >>>> On Fri, Aug 26, 2016 at 7:55 AM Guillaume Nodet <[email protected]> >>>> wrote: >>>> >>>>> No, that's true for 2.x and 3.x. >>>>> 4.x converts the feature list to a list of requirements, builds >>>>> resources, launch the OSGi resolver, check the current state and apply the >>>>> difference. >>>>> >>>>> >>>>> 2016-08-26 13:52 GMT+02:00 James Carman <[email protected]>: >>>>> >>>>>> It iterates through what you hand it, doesn't it? >>>>>> >>>>>> On Fri, Aug 26, 2016 at 7:50 AM Guillaume Nodet <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Yeah, BootFeaturesInstaller keeps the order and pass a LinkedHashSet >>>>>>> to the FeaturesServiceImpl, but that one does not care about the order >>>>>>> by >>>>>>> design. >>>>>>> >>>>>>> >>>>>>> 2016-08-26 13:46 GMT+02:00 James Carman <[email protected]> >>>>>>> : >>>>>>> >>>>>>>> We change the code to use a list ordered set, so the order is >>>>>>>> preserved. It has been applied to all branches >>>>>>>> >>>>>>>> On Fri, Aug 26, 2016 at 7:45 AM Guillaume Nodet <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Afaik karaf-4642 only really applies to 3.x unless you use stages >>>>>>>>> with one feature per stage. >>>>>>>>> Features in a single stage are installed all at once, so the order >>>>>>>>> is lost. >>>>>>>>> A simple proof is to look at the list of bundles installed with a >>>>>>>>> bare karaf 4.x install : the order of the installed bundles is >>>>>>>>> unrelated to >>>>>>>>> the order of the features listed in the configuration, that's because >>>>>>>>> a >>>>>>>>> single stage is used. >>>>>>>>> >>>>>>>>> 2016-08-26 13:14 GMT+02:00 James Carman < >>>>>>>>> [email protected]>: >>>>>>>>> >>>>>>>>>> That's not entirely true. The featuresBoot ordering has been >>>>>>>>>> fixed by >>>>>>>>>> karaf-4642. >>>>>>>>>> >>>>>>>>>> On Fri, Aug 26, 2016 at 3:42 AM Guillaume Nodet < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> The only way to influence the start order of bundles is to >>>>>>>>>>> specify the start level on the feature or on the feature's bundles >>>>>>>>>>> using >>>>>>>>>>> the start-level attribute (see >>>>>>>>>>> https://github.com/apache/karaf/blob/karaf-4.0.x/assemblies/features/standard/src/main/feature/feature.xml >>>>>>>>>>> for some examples). >>>>>>>>>>> >>>>>>>>>>> In Karaf 4.x, the features are resolved and installed in a >>>>>>>>>>> single pass, so the order is lost. >>>>>>>>>>> >>>>>>>>>>> 2016-08-26 4:58 GMT+02:00 oski_bear <[email protected]>: >>>>>>>>>>> >>>>>>>>>>>> Hello, I'm a long-time user of Karaf 2.4.0 trying to migrate my >>>>>>>>>>>> application >>>>>>>>>>>> to Karaf 4.0.5. One thing I've noticed is that in this new >>>>>>>>>>>> version of Karaf >>>>>>>>>>>> there doesn't seem to be any way to specify the order in which >>>>>>>>>>>> bundles are >>>>>>>>>>>> ordered. >>>>>>>>>>>> >>>>>>>>>>>> For example, if I specify "bootFeatures" in the >>>>>>>>>>>> karaf-maven-plugin they >>>>>>>>>>>> don't start in the order that I list them. Additionally, when I >>>>>>>>>>>> create my >>>>>>>>>>>> own features they don't load in the order they are written and >>>>>>>>>>>> the container >>>>>>>>>>>> does not seem to respect the start levels. >>>>>>>>>>>> >>>>>>>>>>>> Am I missing something here? Is there a way to enforce a >>>>>>>>>>>> certain order in >>>>>>>>>>>> the boot features with the karaf-maven-plugin? Is there a way >>>>>>>>>>>> to force an >>>>>>>>>>>> order when defining a feature? >>>>>>>>>>>> >>>>>>>>>>>> Please help me understand. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> View this message in context: >>>>>>>>>>>> http://karaf.922171.n3.nabble.com/Karaf-4-0-5-bundle-startup-order-tp4047689.html >>>>>>>>>>>> Sent from the Karaf - User mailing list archive at Nabble.com. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> ------------------------ >>>>>>>>>>> Guillaume Nodet >>>>>>>>>>> ------------------------ >>>>>>>>>>> Red Hat, Open Source Integration >>>>>>>>>>> >>>>>>>>>>> Email: [email protected] >>>>>>>>>>> Web: http://fusesource.com >>>>>>>>>>> Blog: http://gnodet.blogspot.com/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> ------------------------ >>>>>>>>> Guillaume Nodet >>>>>>>>> ------------------------ >>>>>>>>> Red Hat, Open Source Integration >>>>>>>>> >>>>>>>>> Email: [email protected] >>>>>>>>> Web: http://fusesource.com >>>>>>>>> Blog: http://gnodet.blogspot.com/ >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> ------------------------ >>>>>>> Guillaume Nodet >>>>>>> ------------------------ >>>>>>> Red Hat, Open Source Integration >>>>>>> >>>>>>> Email: [email protected] >>>>>>> Web: http://fusesource.com >>>>>>> Blog: http://gnodet.blogspot.com/ >>>>>>> >>>>>>> >>>>> >>>>> >>>>> -- >>>>> ------------------------ >>>>> Guillaume Nodet >>>>> ------------------------ >>>>> Red Hat, Open Source Integration >>>>> >>>>> Email: [email protected] >>>>> Web: http://fusesource.com >>>>> Blog: http://gnodet.blogspot.com/ >>>>> >>>>> >>> >>> >>> -- >>> ------------------------ >>> Guillaume Nodet >>> ------------------------ >>> Red Hat, Open Source Integration >>> >>> Email: [email protected] >>> Web: http://fusesource.com >>> Blog: http://gnodet.blogspot.com/ >>> >>> > > > -- > ------------------------ > Guillaume Nodet > ------------------------ > Red Hat, Open Source Integration > > Email: [email protected] > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/ > >
