Mailing-List: contact dev-help@karaf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@karaf.apache.org
MIME-Version: 1.0
In-Reply-To: <CALznzY6WaQW5B28prp49Z400Bn4ooAq4hiOQ-1FuKhAfi0Ja2A@mail.gmail.com>
References: <CALznzY5ZAhrWSxer8AnfnjuJyabPvJjDmbFJNaF67mDkLBY-Pg@mail.gmail.com>
 <CAA66TpqUvNBwujgJSeJ4UnNqc3Dm4TM4w86TGwMAsnceh=OzhQ@mail.gmail.com>
 <CALznzY5Yr+wAwf3YDX+qj5izou8k5LiJfbRnXrfueys1nJd5Qg@mail.gmail.com>
 <CAA66Tpr46LJqBa8vGwH1AUCce6zSqYGNf8n7H=b4vkVFKDMUgg@mail.gmail.com>
 <CALznzY6U6TpcCWEpYoyROYjmvRFWbwaq0BNKhA1bbS=D8c7t6w@mail.gmail.com>
 <CAA66Tpo348b_6=3o7jaA9L6yq8t_N+tRsbvSwtp-oq+stDg29Q@mail.gmail.com>
 <CALznzY6tfV=DgwtK8wWxt1n3DTZFZj3Zf8UXmAroAn5vZ9eOGw@mail.gmail.com> <CALznzY6WaQW5B28prp49Z400Bn4ooAq4hiOQ-1FuKhAfi0Ja2A@mail.gmail.com>
From: Guillaume Nodet <gnodet@apache.org>
Date: Fri, 18 Nov 2016 17:39:19 +0100
Message-ID: <CAA66TppPxdb7jur2isQCRqkZSye-iQ=HuePCXULJCntv_fcDmQ@mail.gmail.com>
Subject: Re: [DISCUSS] Predictable Boot Feature Startup Order...
To: dev <dev@karaf.apache.org>
Content-Type: multipart/alternative; boundary=001a1147097ccd73c1054195f3eb
archived-at: Fri, 18 Nov 2016 16:39:43 -0000

--001a1147097ccd73c1054195f3eb
Content-Type: text/plain; charset=UTF-8

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/

--001a1147097ccd73c1054195f3eb--