Perhaps I am confusing the order of installation with the bundle start level.
But let me ask you this: how can I actually verify in what order the bundles
are started in from the Karaf shell?
It seems like what you are saying is that the bundle id order does not
reflect the startup order. At the v
Also, one of our app developers has posted their attempt to make a bundle
that depends on taverna-robundle, while excluding Xerces from the embedded
dependencies and importing it from the system packages.
However, this does not work - the following exception occurs when Jena tries
to use a Xerces
What we're looking for is a way that a bundle can function while embedding
bundles that require Xerces *without* making any changes to the assembly. As
an example, here is the first few lines of the stack trace we get from a
bundle trying to use a embedded dependency that requires Xerces.
java.la
It does not ignore the start levels.
If you run "bundle:list -t 0", you'll see a bunch of bundles with various
start levels. Those are not set in a random fashion ;-) So the bundle
start levels are at least set correctly.
And when I look at the debug log of the FeaturesServiceImpl, I can see th
Hi Guillaume, using the start-level, as you suggested, is one of the first
things I tried and I was surprised that it did not have the expected effect.
My determination is that Karaf 4.0.5 completely ignores the start-level.
--
View this message in context:
http://karaf.922171.n3.nabble.com/Kar
Have you tried the following ?
mvn:com.example/
bundle-a/${project.version}
mvn:com.example/
bundle-b/${project.version}
2016-08-26 20:00 GMT+02:00 oski_bear :
> I was able to solve my bundle ordering issues by creating feature
> dependencies. E.g.
>
> description=
I was able to solve my bundle ordering issues by creating feature
dependencies. E.g.
mvn:com.example/bundle-a/${project.version}
feature-a
mvn:com.example/bundle-b/${project.version}
I have some mixed feelings about this solution. On the one hand, it's
Honestly, we haven't been using K4 much. I'm going to try to bring up one
of our more troubling scenarios in K3 (< 3.0.8) and see what happens in
K4. Thanks for the explanation, Guillaume! Hopefully K4 "just works"! :)
On Fri, Aug 26, 2016 at 10:05 AM Guillaume Nodet wrote:
> Yeah, that's a
Yeah, that's actually the only case where the bundle is is important afaik.
However, when using Karaf 4 feature service, things are slightly different
: let's say you have 2 features, each feature containing a bundle which
export the same package but in different version. If a single bundle can
b
The bundle id is important, especially when trying to resolve the same
packages from multiple bundles, because the lower bundle id is supposed to
be chosen when there are multiple options for the same dependency range.
That's what I'm trying to control mostly.
On Fri, Aug 26, 2016 at 8:59 AM Guill
2016-08-26 14:59 GMT+02:00 Guillaume Nodet :
> The installation order is not really relevent, what is important is the
> startup order.
> Once the list of bundles has been computed, the features service does the
> following:
>#1: stop bundles that needs to be updated or uninstalled in order
>
The installation order is not really relevent, what is important is the
startup order.
Once the list of bundles has been computed, the features service does the
following:
#1: stop bundles that needs to be updated or uninstalled in order
#2: uninstall needed bundles
#3: update regions
#
Wonderful. Something needs to be done about that, then.
On Fri, Aug 26, 2016 at 7:55 AM Guillaume Nodet wrote:
> No, that's true for 2.x and 3.x.
> 4.x converts the feature list to a list of requirements, builds resources,
> launch the OSGi resolver, check the current state and apply the differen
No, that's true for 2.x and 3.x.
4.x converts the feature list to a list of requirements, builds resources,
launch the OSGi resolver, check the current state and apply the difference.
2016-08-26 13:52 GMT+02:00 James Carman :
> It iterates through what you hand it, doesn't it?
>
> On Fri, Aug 26,
It iterates through what you hand it, doesn't it?
On Fri, Aug 26, 2016 at 7:50 AM Guillaume Nodet wrote:
> Yeah, BootFeaturesInstaller keeps the order and pass a LinkedHashSet to
> the FeaturesServiceImpl, but that one does not care about the order by
> design.
>
>
> 2016-08-26 13:46 GMT+02:00 J
Yeah, BootFeaturesInstaller keeps the order and pass a LinkedHashSet to the
FeaturesServiceImpl, but that one does not care about the order by design.
2016-08-26 13:46 GMT+02:00 James Carman :
> We change the code to use a list ordered set, so the order is preserved.
> It has been applied to all
We change the code to use a list ordered set, so the order is preserved. It
has been applied to all branches
On Fri, Aug 26, 2016 at 7:45 AM Guillaume Nodet wrote:
> Afaik karaf-4642 only really applies to 3.x unless you use stages with one
> feature per stage.
> Features in a single stage are i
Afaik karaf-4642 only really applies to 3.x unless you use stages with one
feature per stage.
Features in a single stage are installed all at once, so the order is lost.
A simple proof is to look at the list of bundles installed with a bare
karaf 4.x install : the order of the installed bundles is
That's not entirely true. The featuresBoot ordering has been fixed by
karaf-4642.
On Fri, Aug 26, 2016 at 3:42 AM Guillaume Nodet wrote:
> The only way to influence the start order of bundles is to specify the
> start level on the feature or on the feature's bundles using the
> start-level attri
Embedding dependencies such as Xerces may be a bit difficult, depending on
how you use it.
For example if you use the standard xml api, the api will most certainly
use the parser from the JVM. In order to use your own copy of xerces, you
need to create your factories explicitly i think.
On a more
The only way to influence the start order of bundles is to specify the
start level on the feature or on the feature's bundles using the start-level
attribute (see
https://github.com/apache/karaf/blob/karaf-4.0.x/assemblies/features/standard/src/main/feature/feature.xml
for some examples).
In Karaf
21 matches
Mail list logo
