You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by James Carman <ja...@carmanconsulting.com> on 2016/11/18 15:44:59 UTC
[DISCUSS] Predictable Boot Feature Startup Order...
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
Re: [DISCUSS] Predictable Boot Feature Startup Order...
Posted by James Carman <ja...@carmanconsulting.com>.
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 <gn...@apache.org> 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 <ja...@carmanconsulting.com>:
>
> > 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 <gn...@apache.org>
> > 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 <ja...@carmanconsulting.com>:
> > >
> > > > 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 <
> > > james@carmanconsulting.com>
> > > > 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 <
> 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/
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > ------------------------
> > > 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/
>
Re: [DISCUSS] Predictable Boot Feature Startup Order...
Posted by Guillaume Nodet <gn...@apache.org>.
Actually, the bundle order has absolutely no effect in Karaf 4.1.
In 4.0.x, when the FeaturesService is called, the wiring is imposed by the
feature service. The features service uses the OSGi resolver to solve the
features and all the constraints, obtain a wiring, then call the OSGi
framework and forces that already computed wiring to be applied (by using
resolver hooks).
The missing bit which has been added to 4.1 by KARAF-4739 is that the
wiring was not enforced upon reboot. This is fixed by saving the computed
wiring and using it during the reboot.
So while I have no problem changing the ordering of bundles, it's really a
cosmetic change at this point.
2016-11-22 15:41 GMT+01:00 James Carman <ja...@carmanconsulting.com>:
> Guillaume, I like what you did there, using the wiring to help you decide
> what depends on what to control the order! This is the type of thing I'm
> looking for. We should try to put dependencies first, if possible in the
> ordering. This allows folks to be more wishy-washy when writing features,
> so they don't have to worry about ordering, which I like. I put a comment
> on the issue. I'm going to try cloning your repo and using your branch to
> build Karaf, then installing Microbule (if you don't get to it before me)
> to see if it solves my issue I'm seeing.
>
> The only thing I'm wondering is how this plays out in a situation where
> multiple bundles can satisfy the same requirement. Let's take, for
> example, two bundles:
>
> A imports package com.foo versions [1.0.0,2.0.0)
> B imports package com.foo versions [1.1.0,2.2.0)
>
> Now, A uses B and com.foo is exposed on the public API of B, so they need
> to be on the same page. Let's assume we have two bundles D1 and D2 which
> export the com.foo package with versions 1.0.0 and 1.1.0 respectively.
> Suppose we have a feature "feature-a" which installs A and D1 (since that's
> the version it needs) and we have "feature-b" which installs "feature-a"
> and D2 (because that's what it needs). It would be great if both A and B
> are wired to D2, since it's the greater version of com.foo and satisfies
> both needs. However, when installing "feature-a", you might not even know
> that D2 is going to be available. Perhaps I'm misunderstanding how all
> this wiring mumbojumbo works, but could this cause issues? If so, is there
> any way to address it? Should we even try to address it, or would we just
> say "you're doing it wrong, dummy"?
>
That's the benefit of the Karaf 4 FeaturesService implementation using the
OSGi resolver.
In this case, if both A and B can be wired to D2, D1 won't be installed (if
it's listed with the dependency="true") flag.
In the case it's not flagged as a dependency, D1 will be installed, but not
used. The same happen if you install A first, then B at a later time,
because all the features are considered globally.
If the constraints conflict somehow, A will be wired to D1 and B to D2. In
those cases, reboot could cause wiring problems because the felix resolver
is not greedy nor persistent (contrary to the equinox one), so that felix
would resolve the bundles one by one and could lead to unresolvable bundles
because of a wrong ordering (and not resolving them all in one go).
Again, KARAF-4739 should solve the problem.
Guillaume
>
> On Fri, Nov 18, 2016 at 3:33 PM Guillaume Nodet <gn...@apache.org> 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 <ja...@carmanconsulting.com>:
> >
> > > 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 <gn...@apache.org>
> > > 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 <james@carmanconsulting.com
> >:
> > > >
> > > > > 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 <
> > > > james@carmanconsulting.com>
> > > > > 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 <
> > 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/
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > ------------------------
> > > > 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/
Re: [DISCUSS] Predictable Boot Feature Startup Order...
Posted by James Carman <ja...@carmanconsulting.com>.
Guillaume, I like what you did there, using the wiring to help you decide
what depends on what to control the order! This is the type of thing I'm
looking for. We should try to put dependencies first, if possible in the
ordering. This allows folks to be more wishy-washy when writing features,
so they don't have to worry about ordering, which I like. I put a comment
on the issue. I'm going to try cloning your repo and using your branch to
build Karaf, then installing Microbule (if you don't get to it before me)
to see if it solves my issue I'm seeing.
The only thing I'm wondering is how this plays out in a situation where
multiple bundles can satisfy the same requirement. Let's take, for
example, two bundles:
A imports package com.foo versions [1.0.0,2.0.0)
B imports package com.foo versions [1.1.0,2.2.0)
Now, A uses B and com.foo is exposed on the public API of B, so they need
to be on the same page. Let's assume we have two bundles D1 and D2 which
export the com.foo package with versions 1.0.0 and 1.1.0 respectively.
Suppose we have a feature "feature-a" which installs A and D1 (since that's
the version it needs) and we have "feature-b" which installs "feature-a"
and D2 (because that's what it needs). It would be great if both A and B
are wired to D2, since it's the greater version of com.foo and satisfies
both needs. However, when installing "feature-a", you might not even know
that D2 is going to be available. Perhaps I'm misunderstanding how all
this wiring mumbojumbo works, but could this cause issues? If so, is there
any way to address it? Should we even try to address it, or would we just
say "you're doing it wrong, dummy"?
On Fri, Nov 18, 2016 at 3:33 PM Guillaume Nodet <gn...@apache.org> 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 <ja...@carmanconsulting.com>:
>
> > 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 <gn...@apache.org>
> > 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 <ja...@carmanconsulting.com>:
> > >
> > > > 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 <
> > > james@carmanconsulting.com>
> > > > 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 <
> 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/
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > ------------------------
> > > 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/
>
Re: [DISCUSS] Predictable Boot Feature Startup Order...
Posted by Guillaume Nodet <gn...@apache.org>.
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 <ja...@carmanconsulting.com>:
> 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 <gn...@apache.org>
> 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 <ja...@carmanconsulting.com>:
> >
> > > 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 <
> > james@carmanconsulting.com>
> > > 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 <gn...@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/
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > ------------------------
> > 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/
Re: [DISCUSS] Predictable Boot Feature Startup Order...
Posted by James Carman <ja...@carmanconsulting.com>.
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 <gn...@apache.org> 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 <ja...@carmanconsulting.com>:
>
> > 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 <
> james@carmanconsulting.com>
> > 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 <gn...@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 <ja...@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 <gn...@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/
> > >
> > >
> >
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Red Hat, Open Source Integration
>
> Email: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
Re: [DISCUSS] Predictable Boot Feature Startup Order...
Posted by Guillaume Nodet <gn...@apache.org>.
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 <ja...@carmanconsulting.com>:
> 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 <ja...@carmanconsulting.com>
> 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 <gn...@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 <ja...@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 <gn...@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/
> >
> >
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: [DISCUSS] Predictable Boot Feature Startup Order...
Posted by James Carman <ja...@carmanconsulting.com>.
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 <ja...@carmanconsulting.com>
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 <gn...@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 <ja...@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 <gn...@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 <ja...@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 <gn...@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/
>
>
Re: [DISCUSS] Predictable Boot Feature Startup Order...
Posted by James Carman <ja...@carmanconsulting.com>.
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 <gn...@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 <ja...@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 <gn...@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 <ja...@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 <gn...@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/
>
Re: [DISCUSS] Predictable Boot Feature Startup Order...
Posted by Guillaume Nodet <gn...@apache.org>.
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 <ja...@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 <gn...@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 <ja...@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 <gn...@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/
Re: [DISCUSS] Predictable Boot Feature Startup Order...
Posted by James Carman <ja...@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 <gn...@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 <ja...@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 <gn...@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 <ja...@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/
>
Re: [DISCUSS] Predictable Boot Feature Startup Order...
Posted by Guillaume Nodet <gn...@apache.org>.
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 <ja...@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 <gn...@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 <ja...@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/
Re: [DISCUSS] Predictable Boot Feature Startup Order...
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
It sounds good to me.
Regards
JB
On 11/20/2016 07:26 PM, Guillaume Nodet wrote:
> As I indicated to James, there's absolutely no order returned by the
> resolver.
> Karaf sorts them alphabetically, so i've raised KARAF-4825 and proposed a
> patch which can be further refined.
>
> Guillaume
>
> 2016-11-19 12:34 GMT+01:00 Christian Schneider <ch...@die-schneider.net>:
>
>> I think it is very important to resolve as many bundles in one go as
>> possible. When installing them one by one it usually creates the need for
>> bundle refreshs.
>>
>> From the numbering of the bundle ids I found a strange thing btw.
>> When I create a feature with my own bundle and several dependent features
>> it seems that my own bundle always has the lowest bundle id and the others
>> follow in the reverse ordering. It looks a bit a like a depth first search.
>> I wonder if that could be reversed. It at least would make finding the user
>> bundles simpler at the end of the list.
>> Not a big thing for me but I wonder if it could be changed.
>>
>> I am not sure how it works exactly in the feature resolver. If it spits
>> out a list of bundles at some point then I think it might just work to
>> install the bundles in the reverse order.
>>
>> Christian
>>
>>
>>
>> On 18.11.2016 17:03, James Carman wrote:
>>
>>> 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 <gn...@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 <ja...@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/
>>>>
>>>>
>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> http://www.talend.com
>>
>>
>
>
--
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [DISCUSS] Predictable Boot Feature Startup Order...
Posted by Guillaume Nodet <gn...@apache.org>.
As I indicated to James, there's absolutely no order returned by the
resolver.
Karaf sorts them alphabetically, so i've raised KARAF-4825 and proposed a
patch which can be further refined.
Guillaume
2016-11-19 12:34 GMT+01:00 Christian Schneider <ch...@die-schneider.net>:
> I think it is very important to resolve as many bundles in one go as
> possible. When installing them one by one it usually creates the need for
> bundle refreshs.
>
> From the numbering of the bundle ids I found a strange thing btw.
> When I create a feature with my own bundle and several dependent features
> it seems that my own bundle always has the lowest bundle id and the others
> follow in the reverse ordering. It looks a bit a like a depth first search.
> I wonder if that could be reversed. It at least would make finding the user
> bundles simpler at the end of the list.
> Not a big thing for me but I wonder if it could be changed.
>
> I am not sure how it works exactly in the feature resolver. If it spits
> out a list of bundles at some point then I think it might just work to
> install the bundles in the reverse order.
>
> Christian
>
>
>
> On 18.11.2016 17:03, James Carman wrote:
>
>> 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 <gn...@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 <ja...@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/
>>>
>>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: [DISCUSS] Predictable Boot Feature Startup Order...
Posted by Christian Schneider <ch...@die-schneider.net>.
I think it is very important to resolve as many bundles in one go as
possible. When installing them one by one it usually creates the need
for bundle refreshs.
From the numbering of the bundle ids I found a strange thing btw.
When I create a feature with my own bundle and several dependent
features it seems that my own bundle always has the lowest bundle id and
the others follow in the reverse ordering. It looks a bit a like a depth
first search. I wonder if that could be reversed. It at least would make
finding the user bundles simpler at the end of the list.
Not a big thing for me but I wonder if it could be changed.
I am not sure how it works exactly in the feature resolver. If it spits
out a list of bundles at some point then I think it might just work to
install the bundles in the reverse order.
Christian
On 18.11.2016 17:03, James Carman wrote:
> 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 <gn...@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 <ja...@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/
>>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: [DISCUSS] Predictable Boot Feature Startup Order...
Posted by James Carman <ja...@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 <gn...@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 <ja...@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/
>
Re: [DISCUSS] Predictable Boot Feature Startup Order...
Posted by Guillaume Nodet <gn...@apache.org>.
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 <ja...@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/