Oh, cool! Thanks, Guillaume! I'll take a look when I get some cycles (hopefully soon).
On Fri, Nov 18, 2016 at 3:33 PM Guillaume Nodet <[email protected]> wrote: > I've raised KARAF-4825 with a proposal for a fix, let me know what you > think. > > 2016-11-18 17:41 GMT+01:00 James Carman <[email protected]>: > > > This was when using the features:install after getting into the console. > > It really seems funny that it would pick that install order. Seems very > > counter-intuitive. Perhaps there's some room for improvement here. > > > > On Fri, Nov 18, 2016 at 11:39 AM Guillaume Nodet <[email protected]> > > wrote: > > > > > The resolver gives a list of bundles without any particular order. > Karaf > > > just sort them in alphabetic order, so "core" < "spi". > > > We could sort them based on the wiring so that importers come after > > > exporters (keeping in mind we need to get a list out of a graph). > > > Note than this is no effect at all at the time the features are > installed > > > because the wiring is imposed to the framework. If the problem you > saw > > > was mainly during a subsequent reboot, then that's the one I fixed in > > 4.1. > > > The bundle used to fix the problem is actually not much tied to karaf > and > > > could be reused in 3.x I think. > > > > > > 2016-11-18 17:33 GMT+01:00 James Carman <[email protected]>: > > > > > > > Another issue I'm seeing with 4.0.7 right now is that the install > order > > > > doesn't really seem to make sense. For example, I've got a "core" > > bundle > > > > that requires the "spi" (service provider/plugin interfaces) bundle. > > My > > > > feature lists the "spi" bundle before the "core" bundle, but for some > > > > reason, Karaf is installing "core" first and then installing "spi" > much > > > > later. Is that expected behavior? It seems strange to me. > > > > > > > > On Fri, Nov 18, 2016 at 11:30 AM James Carman < > > > [email protected]> > > > > wrote: > > > > > > > > > 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/ > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > ------------------------ > > > 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/ >
