2016-09-29 16:22 GMT+02:00 Benson Margulies <[email protected]>: > On Thu, Sep 29, 2016 at 10:12 AM, Guillaume Nodet <[email protected]> > wrote: > > Manually maintaining the feature set is not something you should do. > > Please raise a JIRA and attach a test case if you can produce one (an > > integration test for the plugin would be awesome) : that's not really > > supported I think. > > As a workaround, I would suggest you force the rosapi-worker-flinx-sdk > to > > be in the startup stage. > > OK, can you tell me how to do that in the configuration of the > karaf-maven-plugin? >
<startupFeatures> > <feature>rosapi-worker-flinx-sdk</feature> > </startupFeatures> > > > > > > You really need this dependency as a prerequisite, right ? The only real > > use case is for URL handlers used inside feature definitions. Anything > > related to the wiring (packages, services, etc...) does not need to be a > > prerequisite. > > As I tried to explain, this results from a mistake. We have a few > bundles with activators that try to obtain services from other > bundles, without properly accounting for indefinite startup order. I > have code changes in train to use DS properly to fix this; these > bundles were written some time ago when we barely understood OSGi. > > My foray into prerequisites is entirely a matter of trying to work > around until the DS changes are in place. I am making a small > experiment with start-level now since the prerequisite approach seems > a bit, well, fraught. > > I will try to find time to make you a test case, it does appear as if > it takes a somewhat complex collection of features and dependencies to > elicit this problem, so it might take me a while. > > I might be able to describe the situation in a way that sheds some > light for you in the interim: > > Feature Q declares feature R as a prerequisite. > > Feature R declares Feature S as an ordinary dependency > (<feature>S</feature>). > > Feature S includes a bundle that imports javax.servlet, but does not > include a bundle that exports javax.servlet. Instead, it normally gets > that package from pax-jetty, which is not declared as a feature > dependency at all. It's just included in the assembly. > > Maybe I should ask this question: if _all_ I need to control is > startup order, and not wiring order, is 'prerequisite' even what I'm > supposed to do? > Definitely not. I'm not even sure that would work during the boot because the bundles part of the prerequisite feature may not even start if the start level is too high. So if you're problem is start order of the bundles, use the start level on bundles. Fwiw, if feature S requires javax.servlet, it would be better to add that bundle as a <bundle dependency="true">xxx</bundle> or have a <feature dependency="true">http</feature>. There's very few valid reason why a feature should not be transitively closed. > > Thanks, > > benson > > > > > > > > > > > 2016-09-29 16:08 GMT+02:00 Benson Margulies <[email protected]>: > >> > >> On Thu, Sep 29, 2016 at 10:05 AM, Jean-Baptiste Onofré <[email protected] > > > >> wrote: > >> > Actually, you are using multi-stage: stage1 is (wrap) and stage2 is > all > >> > the > >> > rest. > >> > > >> > I would recommend to group all dependency features in stage1 and the > >> > rest in > >> > stage2. > >> > >> How can I do that while still using the karaf-maven-plugin to write > >> this file for me? Do I have to give up and manually maintain that > >> property? > >> > >> Would the syntax be (a,b,c,d),e,g,f? > >> > >> thanks, > >> benson > >> > >> > >> > >> > > >> > Regards > >> > JB > >> > > >> > > >> > On 09/29/2016 03:54 PM, Benson Margulies wrote: > >> >> > >> >> Hi JB, > >> >> > >> >> I let the maven plugin write org.apache.karaf.features.cfg, so I > don't > >> >> know, to be honest, if I'm using multi-stage. > >> >> > >> >> _Without_ the failing prerequisites, I have the following content of > >> >> org.apache.karaf.features.cfg. I'm using the property editor feature > >> >> to turn off capability enforcement. > >> >> > >> >> > >> >> rosapi-all-sdks is just a bag of <feature> declarations for other > >> >> features. Things break when I try to make one of them a prerequisite > >> >> of another. My problem is really to prevent the activation of a few > >> >> bundles until another bundle is safely under control, and I am hoping > >> >> for a workaround in the interim until we can really fix this with DS > >> >> in a few weeks. > >> >> > >> >> > >> >> #Modified by org.apache.karaf.tools.utils.KarafPropertiesFile > >> >> #Thu Sep 29 09:49:19 EDT 2016 > >> >> featuresBootAsynchronous=false > >> >> serviceRequirements=disable > >> >> featuresBoot = \ > >> >> (wrap), \ > >> >> log, \ > >> >> rosapi-front-end-anvils-transport, \ > >> >> bean-validation-support, \ > >> >> rosapi-worker-common, \ > >> >> ssh, \ > >> >> rosapi-front-end-logstash-request-tracker, \ > >> >> rosapi-front-end-service, \ > >> >> aries-blueprint, \ > >> >> feature, \ > >> >> jaas, \ > >> >> diagnostic, \ > >> >> rosapi-worker-download-text-extraction-component, \ > >> >> rosapi-front-end-null-request-tracker, \ > >> >> bundle, \ > >> >> rosapi-all-sdks, \ > >> >> rosapi-front-end-local-usage-tracker, \ > >> >> package, \ > >> >> scr, \ > >> >> rosapi-common, \ > >> >> cxf-jaxrs, \ > >> >> rosette-api, \ > >> >> rosapi-front-end-embedded-transport, \ > >> >> system, \ > >> >> shell, \ > >> >> shell-compat, \ > >> >> config > >> >> featuresRepositories = \ > >> >> mvn:com.basistech.ws/rosapi-features/1.5.0-SNAPSHOT/xml/features, > \ > >> >> mvn:org.apache.karaf.features/standard/4.0.6/xml/features, \ > >> >> mvn:org.apache.cxf.karaf/apache-cxf/3.1.4/xml/features, \ > >> >> mvn:org.apache.karaf.features/framework/4.0.6/xml/features > >> >> > >> >> > >> >> On Thu, Sep 29, 2016 at 9:47 AM, Jean-Baptiste Onofré < > [email protected]> > >> >> wrote: > >> >>> > >> >>> Hi Benson, > >> >>> > >> >>> do you use multi-stage in featuresBoot ? > >> >>> > >> >>> Regards > >> >>> JB > >> >>> > >> >>> > >> >>> On 09/29/2016 03:33 PM, Benson Margulies wrote: > >> >>>> > >> >>>> > >> >>>> Folks, > >> >>>> > >> >>>> I build an assembly in which all the feature are boot features, > >> >>>> because they are all going to be used. > >> >>>> > >> >>>> When I try to make one of them a prerequisite of another, I get a > >> >>>> wiring error, because, apparently, the dependency tree at the > package > >> >>>> level is not being respected in wiring the bundles. > >> >>>> > >> >>>> All of this is a temporary stopgap until some components get > correct > >> >>>> DS @Reference dependencies, which some of them lack. > >> >>>> > >> >>>> Questions: Am I making an error using boot features? I realize that > >> >>>> this report lacks specificity. I could try to build up a model on > >> >>>> github. > >> >>>> > >> >>>> TIA, > >> >>>> benson > >> >>>> > >> >>> > >> >>> -- > >> >>> Jean-Baptiste Onofré > >> >>> [email protected] > >> >>> http://blog.nanthrax.net > >> >>> Talend - http://www.talend.com > >> > > >> > > >> > -- > >> > Jean-Baptiste Onofré > >> > [email protected] > >> > http://blog.nanthrax.net > >> > Talend - http://www.talend.com > > > > > > > > > > -- > > ------------------------ > > Guillaume Nodet > > ------------------------ > > Red Hat, Open Source Integration > > > > Email: [email protected] > > Web: http://fusesource.com > > Blog: http://gnodet.blogspot.com/ > > > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: [email protected] Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
