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 >
