I got it with a ton of help from other people on the felix list. The
CXF part is trivial.
1: Make a component with no services:
@Component(configurationPid = "com.basistech.ws.worker",
configurationPolicy = ConfigurationPolicy.REQUIRE,
/* No services; we're here to register ourself with CXF. */
service = {})
2: Mark this up as a resource, or you can use other classes as the resource:
3: in your @Activate:
JAXRSServerFactoryBean sf = new JAXRSServerFactoryBean();
sf.setServiceBean(this);
sf.setAddress("/worker");
server = sf.create();
On the felix list you will see a river of email about how to make this
depend on a variable collection of components registering OSGI
services that you want to delegate to in your resource(s).
On Mon, Sep 7, 2015 at 3:40 PM, <developm...@mobigov.com> wrote:
> When you figure out how to add providers and services to cxf without
> blueprint please follow up. It would be helpful to me as well.
>
> Thanks for all your great questions,
>
> David
>
>
>
>
>
> On 2015-09-07 09:31, Benson Margulies wrote:
>
> On Mon, Sep 7, 2015 at 9:28 AM, Benson Margulies <ben...@basistech.com>
> wrote:
>
> On Mon, Sep 7, 2015 at 9:25 AM, Achim Nierbeck <bcanh...@googlemail.com>
> 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
> <ben...@basistech.com>:
>
> 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 <bcanh...@googlemail.com> 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 <david_jen...@yahoo.com>:
>
> 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 <ben...@basistech.com> 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
> <ben...@basistech.com> 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
