Thought that as well but camel, cxf, jaxrs whiteboard etc are other examples where order is important....but the symbolic names should be sufficient to guarantee a good order in most cases too
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le ven. 16 oct. 2020 à 10:24, Jean-Baptiste Onofre <j...@nanthrax.net> a écrit : > Yeah, agree that it’s weird to not have seen before ;) > > My guess is that people maybe have more "splitter/dynamic" features than > "our" scenario (even if it’s a valid one) and also have super fast machine. > Here, the application "imposes" a startup order which is not the case in > pure OSGi (by design, it’s dynamic, so it can react later). > > So, I’m pretty sure, it’s not really a problem with "dynamic ready" > modules. Here’s we identified the issue due to SpiFly and CDI. > > Don’t get my wrong, it should be improved, but not a big deal for OSGi > designed module. > > Regards > JB > > > Le 16 oct. 2020 à 07:30, Romain Manni-Bucau <rmannibu...@gmail.com> a > écrit : > > > > To try to help on the different points you mention: > > > > 1.a prerequisite is good when you have two stagings - order to respect > to > > install a full feature - so it is a very rare and limited case (in my > app I > > have 5 for ex) > > 1.b requirements doesn't help with the order (until a framework > extension), > > just with "start" which fails so you can still have a bundle starting and > > not having some dependency so at the end order is still required > > 2. the comparator is not sufficient by itself, all the Set and Map are > not > > sorted in karaf featureservice/felix resolver so they also break the > order > > > > So at the end I think the order is a requirement of the features - but > > still amazed it didnt pop up before. > > > > Romain Manni-Bucau > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > <https://rmannibucau.metawerx.net/> | Old Blog > > <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > < > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > > > Le ven. 16 oct. 2020 à 05:59, Jean-Baptiste Onofre <j...@nanthrax.net> a > > écrit : > > > >> The comparator based on symbolic name is to have something deterministic > >> but doesn’t necessary match. > >> I would like to check If using requirement in a feature would help (I’m > >> afraid it would block the installation but not guarantee the order > though). > >> > >> So, I think it’s worth to evaluate/improve the comparator to have > >> something more "user logic". > >> > >> I will create a Jira and check different scenario. > >> > >> Regards > >> JB > >> > >>> Le 15 oct. 2020 à 17:43, Łukasz Dywicki <l...@code-house.org> a écrit > : > >>> > >>> What you say makes a lot of sense. I was just refering to behavior > which > >>> I think is there since new resolver come into play. > >>> Making it a bit more deterministic is definitely fair (yet expensive in > >>> debugging) point to take. > >>> > >>> Cheers, > >>> Łukasz > >>> > >>> > >>> On 15.10.2020 17:32, Romain Manni-Bucau wrote: > >>>> Fact is if features are not installed in reversed graph order it is > not > >>>> really reliable an you can't install an app and be sure it will work, > >> even > >>>> if you sorted manually the bundles. > >>>> The ResourceComparator sorts by symbolic names which makes the > >> deployment > >>>> deterministic but potentially random from an user perspective > >>>> (uncontrollable). > >>>> Then the featureservice+resolve use a list of hashmap (or hashset) > which > >>>> also randomizes the installation. > >>>> Guess using at least a reversed dijkstra distance (or tree deepness in > >> some > >>>> simple cases) from the feature to sort bundles installation order is > >> worth > >>>> it to make it more natural and controlled for end users. > >>>> > >>>> Hope it makes sense. > >>>> > >>>> Romain Manni-Bucau > >>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog > >>>> <https://rmannibucau.metawerx.net/> | Old Blog > >>>> <http://rmannibucau.wordpress.com> | Github < > >> https://github.com/rmannibucau> | > >>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > >>>> < > >> > https://www.packtpub.com/application-development/java-ee-8-high-performance > >>> > >>>> > >>>> > >>>> Le jeu. 15 oct. 2020 à 17:28, Łukasz Dywicki <l...@code-house.org> a > >> écrit : > >>>> > >>>>> I am not sure if that's feature resolver issue. It is rather related > to > >>>>> bundle resolver which determines installation order. > >>>>> As far I remember from my last debugging session in this area bundles > >>>>> are installed in computed "dependency" order. It might be that leaf/1 > >>>>> has no direct dependencies on any of its children hence it is > installed > >>>>> first. > >>>>> Note, that I don't know details on how present feature resolution > works > >>>>> and if its just supplier for graph elements or separate graph > computed > >>>>> by same algorithm as bundles. > >>>>> > >>>>> Best, > >>>>> Łukasz > >>>>> > >>>>> > >>>>> On 15.10.2020 15:47, Jean-Baptiste Onofre wrote: > >>>>>> Hi guys, > >>>>>> > >>>>>> Romain found an issue on the feature resolver about the features > >>>>> ordering. > >>>>>> > >>>>>> For instance, if we have the following features descriptor: > >>>>>> > >>>>>> <features name="global"> > >>>>>> <feature name="nested1"> > >>>>>> <bundle>mvn:foo/nested1/2</bundle> > >>>>>> </feature> > >>>>>> <feature name="nested21"> > >>>>>> <bundle>mvn:foo/nested21/3</bundle> > >>>>>> </feature> > >>>>>> <feature name="nested2"> > >>>>>> <feature>nested21</feature> > >>>>>> <bundle>mvn:foo/nested2/2</bundle> > >>>>>> </feature> > >>>>>> <feature name="leaf"> > >>>>>> <feature>nested1</feature> > >>>>>> <feature>nested2</feature> > >>>>>> <bundle>mvn:foo/leaf/1</bundle> > >>>>>> </feature> > >>>>>> </features> > >>>>>> > >>>>>> When installing leaf feature, we expect the following order (for > >> bundles > >>>>> installation): > >>>>>> 1. foo/nested1/2 bundle (nested1 feature) > >>>>>> 2. foo/nested21/3 bundle (nested21 feature) > >>>>>> 3. foo/nested2/2 bundle (nested2 feature) > >>>>>> 4. foo/leaf/1 bundle (leaf feature) > >>>>>> > >>>>>> However, the order is not this one. During test, we saw that the > order > >>>>> is mvn:foo/leaf/1, mvn:foo/nested1/2, mvn:foo/nested21/3, > >> mvn:foo/nested2/2. > >>>>>> > >>>>>> We can see that the leaf bundle is installed before the bundles from > >>>>> inner/transitive features. > >>>>>> > >>>>>> I would like to investigate this behavior and improve this (I would > >> like > >>>>> to check if it’s also the case in previous versions). > >>>>>> > >>>>>> As the target of Karaf 4.3.0 is this week end, I would take some > time > >> to > >>>>> check and compare. > >>>>>> > >>>>>> I will keep you posted. > >>>>>> > >>>>>> Regards > >>>>>> JB > >>>>>> > >>>>> > >>>> > >> > >> > >
