The main issue I faced was when different features install different versions of the same bundle (my particular problem child was GSON I think). The main issue that we saw was when the lower version installed/started earlier than the higher version. So, some bundles would bind to the lower version and later bundles which require a higher minor version, would bind to the higher version. Hopefully that makes sense :)
On Fri, Nov 18, 2016 at 11:23 AM Guillaume Nodet <[email protected]> wrote: > Here's the 3.x code > for (Set<Feature> features : stagedFeatures) { > features.removeAll(installedFeatures); > featuresService.installFeatures(features, > EnumSet.of(Option.NoAutoRefreshBundles, Option.NoCleanIfFailure, > Option.ContinueBatchOnFailure)); > } > > The 3.x features service will install the features one by one in a given > set however. > The difference may come from the Option.NoAutoRefreshBundles, but that's > the benefit of using the osgi resolver, i.e. the features are considered as > a whole ;-) > > Just to refresh my memory, what's the actual use case : is it a bundle > startup order or a bundle installation order (which has an impact on > resolution when choosing between the same package exported by multiple > bundles). > Note that the bundle startup order will be different when rebooting, > whereas when using a single stage, the order should be the same. If the > problem is a wiring problem because you have packages exported by multiple > bundles, I've tried to fix some of this problem in 4.1 by ensuring that the > same wiring is reused after a reboot. > > 2016-11-18 17:13 GMT+01:00 James Carman <[email protected]>: > > > I know. I looked at the code. That's why I was surprised when I had > > issues when trying it that way. It could be I'm doing something strange > > with CXF, but it works in a non-staged setup. If I get some cycles, > > perhaps I can try it again and record the error. > > > > > > On Fri, Nov 18, 2016 at 11:11 AM Guillaume Nodet <[email protected]> > > wrote: > > > > > Using staged features with one feature per set will have the exact same > > > behavior than installing the features one by one. > > > > > > Here's the BootFeaturesInstaller code: > > > > > > List<Set<String>> stagedFeatures = parseBootFeatures(features); > > > for (Set<String> features : stagedFeatures) { > > > featuresService.installFeatures(features, > > > EnumSet.of(FeaturesService.Option.NoFailOnFeatureNotFound)); > > > } > > > featuresService.bootDone(); > > > > > > > > > > > > 2016-11-18 17:03 GMT+01:00 James Carman <[email protected]>: > > > > > > > Yes, I've tried using staged boot, but in 3.0.x it caused some > > classpath > > > > issues with CXF. It would be great if we could just set up our > > features > > > so > > > > that they're just installed in the order they're defined. > > > > > > > > On Fri, Nov 18, 2016 at 10:56 AM Guillaume Nodet <[email protected]> > > > > wrote: > > > > > > > > > You mean installing the features one by one instead of all in one > go > > ? > > > > > Have you tried using > > > > > (myfeature1,myfeature2),(myfeature3,myfeature4) > > > > > so that you end up with 2 stages ? > > > > > Ultimately, you can use > > > > > (myfeature1),(myfeature2),(myfeature3),(myfeature4) > > > > > > > > > > 2016-11-18 16:44 GMT+01:00 James Carman < > [email protected] > > >: > > > > > > > > > > > Karaf 3.0.8+ now provides predictable boot feature startup order, > > but > > > > the > > > > > > 4.0.x line does not provide that guarantee. It apparently tries > to > > > be > > > > > > smart and figure out what you need, but sometimes it just works > > > better > > > > if > > > > > > we can let the user control things explicitly. Is there, > perhaps, > > a > > > > > > compromise here? Could we perhaps have a switch in the > > > > > > org.apache.karaf.features.cfg file that allows you to turn on > > manual > > > > > > control of the startup order? I'm not the only one who has > > > encountered > > > > > > this issue. There have been emails recently where other folks > have > > > > > > observed it. Thoughts? > > > > > > > > > > > > James > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > ------------------------ > > > > > 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/ >
