Thank you so much for this. I will join that list as well and try to do
a better job keeping up with emails.
David
On 2015-09-07 20:31, Benson Margulies wrote:
> 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, <[email protected]> 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 <[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/ [1]> Committer & PMC OPS4J Pax Web
<http://wiki.ops4j.org/display/paxweb/Pax+Web/ [2]> Committer & Project Lead
blog <http://notizblog.nierbeck.de/ [3]> Co-Author of Apache Karaf Cookbook
<http://bit.ly/1ps9rkS [4]> Software Architect / Project Manager / Scrum Master
-- Apache Member Apache Karaf <http://karaf.apache.org/ [1]> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/ [2]> Committer &
Project Lead blog <http://notizblog.nierbeck.de/ [3]> Co-Author of Apache Karaf
Cookbook
<http://bit.ly/1ps9rkS [4]> Software Architect / Project Manager / Scrum Master
Links:
------
[1] http://karaf.apache.org/
[2] http://wiki.ops4j.org/display/paxweb/Pax+Web/
[3] http://notizblog.nierbeck.de/
[4] http://bit.ly/1ps9rkS
