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: <CALznzY4r-jxyUJKgJ5171C9Lm+Hc=uraSMZdAyeunRoLvfOKGA@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>
 <CAA66TppPxdb7jur2isQCRqkZSye-iQ=HuePCXULJCntv_fcDmQ@mail.gmail.com> <CALznzY4r-jxyUJKgJ5171C9Lm+Hc=uraSMZdAyeunRoLvfOKGA@mail.gmail.com>
From: Guillaume Nodet <gnodet@apache.org>
Date: Fri, 18 Nov 2016 21:32:59 +0100
Message-ID: <CAA66TprvsT0zzS=djgU_o0ubXxXRFvSAHRODF1vAun=nSZvFmA@mail.gmail.com>
Subject: Re: [DISCUSS] Predictable Boot Feature Startup Order...
To: dev <dev@karaf.apache.org>
Content-Type: multipart/alternative; boundary=001a1147097c75241d05419937b1
archived-at: Fri, 18 Nov 2016 20:33:23 -0000

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

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 <james@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 <gnodet@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/

--001a1147097c75241d05419937b1--