On Mon, Sep 7, 2015 at 9:28 AM, Benson Margulies <[email protected]> wrote: > On Mon, Sep 7, 2015 at 9:25 AM, Achim Nierbeck <[email protected]> > wrote: >> hmm, must have overseen that sentence: >> >>> The onl difference in >>> bundle inventory from blueprint to DS is the addition of the >>> compendium jar, which is not even loaded by loading up CXF. >> >> >> actually it's no good idea to include that, and afaik all of the felix >> bundles already provide all of the needed >> compendium packages. >> So remove that one, cause that will make trouble and that's for sure :-) > > So, 'scope provided'? I'll try that before I go out for the walk.
Well, there you go. All is well, no capability wiring errors, no mysterious explosions. > > >> >> regards, Achim >> >> >> 2015-09-07 15:20 GMT+02:00 Benson Margulies <[email protected]>: >>> >>> Achim and David, >>> >>> I am not currently using the most recent felix resolver; that requires >>> building the trunk of Karaf with a patch. >>> >>> Over on the Karaf list, I'm pestering Achim with the following situation: >>> >>> I have, now, a working version of my system which is 100% blueprint. >>> (I did solve the problem which started all of this.) Nevertheless, you >>> and others make a convincing case for DS, so I decided to try to move >>> to DS. >>> >>> To start, I picked a bundle that has no use of CXF -- it just consumes >>> a service and registers a service. The service it consumes has no >>> Provide-Capability in its metadata. >>> >>> I: >>> >>> * removed the blueprint metadata, >>> * added a dependency on the compendium jar (5.0.0) >>> * added the DS annotations >>> * added -dsannotations: * for bnd. >>> >>> In Karaf, I install the prerequisites, which have not changed. Then I >>> install the DS service. I feared that I'd get a wiring error due to >>> the Require-Capability. But I don't. Instead, Karaf (very noisily) >>> restarts the CXF bundles that are already there. The onl difference in >>> bundle inventory from blueprint to DS is the addition of the >>> compendium jar, which is not even loaded by loading up CXF. >>> >>> If I then install an (unchanged) bundle that uses blueprint and >>> consumes the DS service, I get an NPE in the Karaf resolver. >>> >>> I think I'm going to go take a walk and then try to produce an open >>> source test case for this hysteria. >>> >>> --benson >>> >>> >>> >>> >>> >>> On Mon, Sep 7, 2015 at 9:06 AM, Achim Nierbeck <[email protected]> >>> wrote: >>> > The felix-resolver does actually look for those Require-Capabilities and >>> > throws an error if they can't be met. >>> > Now karaf uses this resolver to resolve all features, and therefore will >>> > run >>> > into the same issue when installing a feature as installing a bundle. >>> > >>> > regards, Achim >>> > >>> > >>> > 2015-09-07 15:04 GMT+02:00 David Jencks <[email protected]>: >>> >> >>> >> I think you mean @Reference? >>> >> >>> >> I was a bit worried about including those Require-Capability for >>> >> services, >>> >> but the people on the spec committee who understand resolving more >>> >> than me >>> >> said that it would not be used at runtime but only to sort of plan what >>> >> set >>> >> of bundles would be a good idea to run together. I wouldn’t rule out >>> >> this >>> >> causing the NPE however. Do you/Karaf have the latest felix resolver >>> >> installed? >>> >> >>> >> BTW Felix DS includes a gogo and a normal shell command. I wouldn’t >>> >> think this would cause a restart — it seems to me that this would >>> >> indicate a >>> >> non-osgi-friendly console — but I don’t know how the karaf console is >>> >> set >>> >> up. >>> >> >>> >> hope you continue making progress :-) >>> >> >>> >> david jencks >>> >> >>> >> > On Sep 7, 2015, at 8:52 AM, Benson Margulies <[email protected]> >>> >> > wrote: >>> >> > >>> >> > David, I note that the use of an @Requirement leads to a >>> >> > Require-Capability in the manifest. In one case, I need to consume a >>> >> > service which is registered by a boring old Activator class in a >>> >> > bundle I do not control, and which does not have the corresponding >>> >> > Provide-Capability. I haven't seen a wiring error yet, but this may >>> >> > be >>> >> > related to an NPE in the Karaf resolver that afflicts me. >>> >> > >>> >> > >>> >> > On Sun, Sep 6, 2015 at 9:46 PM, Benson Margulies >>> >> > <[email protected]> >>> >> > wrote: >>> >> >> So, the good news is that I read the spec, I followed you hints, and >>> >> >> I >>> >> >> converted a simple bundle of mine from blueprint to DS. >>> >> >> >>> >> >> The bad news is that Karaf 4.0.1 was unable to start up with a >>> >> >> combination of aries-blueprint and scr enabled. I am going to see if >>> >> >> the Karaf folks can give me a path through that before I try >>> >> >> converting _all_ my services all at once. >>> >> >>> > >>> > >>> > >>> > -- >>> > >>> > Apache Member >>> > Apache Karaf <http://karaf.apache.org/> Committer & PMC >>> > OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer >>> > & >>> > Project Lead >>> > blog <http://notizblog.nierbeck.de/> >>> > Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> >>> > >>> > Software Architect / Project Manager / Scrum Master >>> > >> >> >> >> >> -- >> >> Apache Member >> Apache Karaf <http://karaf.apache.org/> Committer & PMC >> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & >> Project Lead >> blog <http://notizblog.nierbeck.de/> >> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> >> >> Software Architect / Project Manager / Scrum Master >>
