karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <ja...@carmanconsulting.com>
Subject Re: [DISCUSS] Predictable Boot Feature Startup Order...
Date Fri, 18 Nov 2016 16:30:45 GMT
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 <gnodet@apache.org> 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 <james@carmanconsulting.com>:
>
> > 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 <gnodet@apache.org>
> > 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 <james@carmanconsulting.com>:
> > >
> > > > 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 <gnodet@apache.org>
> > > > 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 <
> james@carmanconsulting.com
> > >:
> > > > >
> > > > > > 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: gnodet@redhat.com
> > > > > Web: http://fusesource.com
> > > > > Blog: http://gnodet.blogspot.com/
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > ------------------------
> > > Guillaume Nodet
> > > ------------------------
> > > Red Hat, Open Source Integration
> > >
> > > Email: gnodet@redhat.com
> > > Web: http://fusesource.com
> > > Blog: http://gnodet.blogspot.com/
> > >
> >
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Red Hat, Open Source Integration
>
> Email: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message