Am Mo., 13. Aug. 2018 um 14:58 Uhr schrieb Jean-Baptiste Onofré < [email protected]>:
> OK, got it. > > That's true that we introduced the features resolver in Karaf 4, which > is much more powerful than we had in Karaf 3. > > In your case, as you start with boot features, did you try: > > 1. to install the feature in sync mode (defined in > etc/org.apache.karaf.features.cfg) > What do you mean by sync mode. Do you mean to set the property featuresBootAsynchronous to false? Tried it with value true and false, but have had no luck. > 2. to use stage in featuresBoot using ( and ), allowing you to define > the startup order. > > However, startup order should not be an issue. If you use service > tracker, your bundles should react as soon as a service becomes available. > That's the point: My services are no OSGI services. They are handmade services with it's own handmade lookup mechanism. I tried to defined capabilities in the OSGI headers for my bundles in the form: Provide-Capability =my.service; type:List=org.foo.ServiceInterface1,org.fooServiceInterface2 And for a consumer: Require-Capability: my.service;effective:=active;filter:=(type= org.foo.ServiceInterface1 ) But it seems that such requirements are not considered for the startup order of the bundles. They are only considered for the resolve process. Is it possible to influence the start order of the bundles that hosts such handmade services or do I have to migrate all my services to OSGI services? Thank you Richard > > Regards > JB > > On 13/08/2018 14:27, Richard Hierlmeier wrote: > > Hi JB, > > > > I start the bundles via many features. The features are defined in > > etc/org.apache.karaf.features.cfg in the property featuresBoot. Normally > > only one feature is added to the featuresBoot property. > > However the feature requires normally other features. > > > > The first startup of Karaf (data directory does not exist) works > > normally. However the restart of Karaf (the data directory exists) does > > not work. > > > > Richard > > > > Am Mo., 13. Aug. 2018 um 14:03 Uhr schrieb Jean-Baptiste Onofré > > <[email protected] <mailto:[email protected]>>: > > > > Hi Richard, > > > > do you start your bundles as part of features ? Or directly in > > etc/startup.properties (or by hand) ? > > > > Regards > > JB > > > > On 13/08/2018 13:57, Richard Hierlmeier wrote: > > > I have to migrate an application to Karaf 4. This application has > it's > > > own service infrastructure (full qualified names of the > implementation > > > classes are defined in text file in META-INF/myServices.txt). > > > > > > The modules of application have uses an handmade lookup mechanism > to > > > find instances of the services. > > > In Karaf 3 we implemented a bundle activator that reads a bundle > start > > > the services from the META-INF/myServices.txt and registers the > > services > > > instances in the handmade lookup. > > > > > > It worked fine in Karaf 3. > > > When migrating to Karaf 4 this mechanism is no longer working. It > > seems > > > that the start order of the bundles has been improved. > > > The following scenario is no longer working: > > > > > > interface of service S1 is defined in bundle B1 > > > implementation of services S1 is in bundle B2 > > > Bundle B3 uses service S1. > > > Bundle B3 does not use directly use a package of bundle B2. > > > > > > It happens Karaf 4 that bundle B3 starts before bundle B2. > > > > > > One possibility would be to register all "handmade" services as > OSGI > > > services and the hand made lookup looks also for OSGI services. > > > However I am afraid that we get unwanted side effects because up > > to now > > > the handmade service infrastructure and the OSGI service > > > very strictly divided. > > > > > > Is it possible to solve the problem with Require-/Provide > Capabilities > > > Header in the OSGI manifiest? > > > > > > Is it in Karaf 4 possible to define a custom management agent that > > > influences the start level of OSGI bundles? > > > > > > Richard > > > > -- > > Jean-Baptiste Onofré > > [email protected] <mailto:[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 >
