Return-Path: <dev-return-11350-archive-asf-public=cust-asf.ponee.io@karaf.apache.org>
X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io
Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io
Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183])
	by cust-asf2.ponee.io (Postfix) with ESMTP id 04993200BC3
	for <archive-asf-public-internal@cust-asf2.ponee.io>; Fri, 18 Nov 2016 17:23:13 +0100 (CET)
Received: by cust-asf.ponee.io (Postfix)
	id 0306D160B04; Fri, 18 Nov 2016 16:23:13 +0000 (UTC)
Delivered-To: archive-asf-public@cust-asf.ponee.io
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by cust-asf.ponee.io (Postfix) with SMTP id 4EE49160B03
	for <archive-asf-public@cust-asf.ponee.io>; Fri, 18 Nov 2016 17:23:12 +0100 (CET)
Received: (qmail 34956 invoked by uid 500); 18 Nov 2016 16:23:11 -0000
Mailing-List: contact dev-help@karaf.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@karaf.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@karaf.apache.org>
List-Post: <mailto:dev@karaf.apache.org>
List-Id: <dev.karaf.apache.org>
Reply-To: dev@karaf.apache.org
Delivered-To: mailing list dev@karaf.apache.org
Received: (qmail 34945 invoked by uid 99); 18 Nov 2016 16:23:11 -0000
Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 18 Nov 2016 16:23:11 +0000
Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com [209.85.218.51])
	by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id D65EA1A00A8
	for <dev@karaf.apache.org>; Fri, 18 Nov 2016 16:23:10 +0000 (UTC)
Received: by mail-oi0-f51.google.com with SMTP id z62so93688130oiz.1
        for <dev@karaf.apache.org>; Fri, 18 Nov 2016 08:23:10 -0800 (PST)
X-Gm-Message-State: AKaTC00dKZaNEfDiSS2PFu0PKvwcEb6GU4d5UwRCqIfNdNffFJeuHxFbPO+qNkVSAGYcaD/3Hxdv2E3JEWLs/g==
X-Received: by 10.202.182.6 with SMTP id g6mr307054oif.85.1479486189592; Fri,
 18 Nov 2016 08:23:09 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.49.3 with HTTP; Fri, 18 Nov 2016 08:22:49 -0800 (PST)
In-Reply-To: <CALznzY6U6TpcCWEpYoyROYjmvRFWbwaq0BNKhA1bbS=D8c7t6w@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>
From: Guillaume Nodet <gnodet@apache.org>
Date: Fri, 18 Nov 2016 17:22:49 +0100
X-Gmail-Original-Message-ID: <CAA66Tpo348b_6=3o7jaA9L6yq8t_N+tRsbvSwtp-oq+stDg29Q@mail.gmail.com>
Message-ID: <CAA66Tpo348b_6=3o7jaA9L6yq8t_N+tRsbvSwtp-oq+stDg29Q@mail.gmail.com>
Subject: Re: [DISCUSS] Predictable Boot Feature Startup Order...
To: dev <dev@karaf.apache.org>
Content-Type: multipart/alternative; boundary=001a1135d144c7ec91054195b8bb
archived-at: Fri, 18 Nov 2016 16:23:13 -0000

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

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/

--001a1135d144c7ec91054195b8bb--