Thanks Neil,
just want to clarify one thing. You wrote " That is, you can have a
requirement with effective:=*resolve* that is not satisfied, and OSGi will
still resolve and activate the bundle just fine."
Did you mean to write something other than "resolve" here? Because from the
previous sentance it seams the "resolve" is what actually the OSGi runtime
will NOT ignore!
Best,
Milen
On Fri, Aug 18, 2017 at 4:20 AM, Neil Bartlett <njbartl...@gmail.com> wrote:
> Hi Milen,
>
> It’s pretty simple… if ‘effective' is unspecified OR has the value
> “resolve”, then the OSGi Framework uses that requirement in its own
> resolution of the bundle. If you specify ANY value other than “resolve”,
> then OSGi Framework completely ignores the requirement. That is, you can
> have a requirement with effective:=resolve that is not satisfied, and OSGi
> will still resolve and activate the bundle just fine.
>
> When you resolve in Bndtools, we always try to find matches for all
> effective:=resolve requirements (otherwise the end result would be broken
> in OSGi!). Optionally you can choose to find matches for additional
> effective values such as “active”. That’s what “-resolve-effective: active”
> means in a bndrun file.
>
> The convention of using effective:=active in a bundle exists because
> sometimes you want to indicate to tools (like Bndtools) that you would LIKE
> to have a thing… but if the thing doesn’t exist, then you don’t want that
> to prevent resolution of the bundle in OSGi.
>
> I hope that all makes sense.
>
> Unfortunately I don’t think this is really relevant to Christian’s
> problem, though.
>
> Neil
>
>
> On 17 Aug 2017, at 16:50, Milen Dyankov <milendyan...@gmail.com> wrote:
>
> Hi Christian,
>
> have you tried adding effective="..." to the annotations and then
> -resolve-effective:
> ... to bndrun file? Sorry for the dots but I never understood how to
> determine what the values should be to make given resolver ignore or
> enforce the requirement. I always play around with them until they give me
> the desired result. I something think there are no more than 10 people on
> this planet who actually understand this :)
>
> Best,
> Milen
>
> On Thu, Aug 17, 2017 at 1:34 PM, Christian Schneider <
> ch...@die-schneider.net> wrote:
>
>> Hi Peter,
>>
>> thanks for your help.
>>
>> I do not cast the type. The user only uses the RComponent interface. The
>> idea of the component model is that the user of component is not exposed to
>> the implementation details of a component. This is of course the root of
>> the problem of why I need more than java types. It is the same for camel.
>>
>> I just tried to create a custom annotation but the result in the manifest
>> looked a bit strange so I now first try to use plain @RequireCapability and
>> @ProvideCapability. When I got this working I will try again with a custom
>> annotation to make it easier to use.
>>
>> This is what I got now..
>> On my mqtt component I define:
>> @ProvideCapability( ns="rcomp", name="mqtt")
>>
>> It results in this Provide-Capability header:
>> rcomp;rcomp=mqtt
>>
>> In my rcomp-example bundle I use:
>> @RequireCapability(ns="rcomp", filter="(rcomp=mqtt)")
>>
>> It results in this Require-Capability header:
>> rcomp;filter:="(rcomp=mqtt)"
>>
>> So I think this looks good.
>>
>> Strangely when I create my bndrun with a requirement on rcomp-example and
>> do a resolve then it does not add my rcomp-mqtt bundle.
>>
>> When I then run the framework it fails with this error:
>> could not resolve the bundles: [rcomp-examples-1.0.0.201708171022
>> org.osgi.framework.BundleException: Unable to resolve rcomp-examples
>> [12](R 12.0): missing requirement [rcomp-examples [12](R 12.0)] rcomp;
>> (rcomp=mqtt) Unresolved requirements: [[rcomp-examples [12](R 12.0)] rcomp;
>> (rcomp=mqtt)]
>> ]
>>
>> Shouldn't the resolver automatically add the rcomp-mqtt bundle and even
>> abort the resolve in case the bundle is not available in the repository?
>>
>> Best
>> Christian
>>
>>
>>
>>
>> On 17.08.2017 10:31, Peter Kriens wrote:
>>
>>> The purpose of the @Reference.target is to be overridden by
>>> configuration, adding the filter to the requirement would basically destroy
>>> that use case.
>>>
>>> For what you want there is a very good solution: Plain Old Java Types …
>>> I suspect that in your code you already do some casting to a more specific
>>> type from RComponent? If that is the case then you have a bad code smell,
>>> which is also visible in Camel I think. We ‘know’ the type but we’re forced
>>> to go to properties to line things up as we want.
>>>
>>> However, I am guessing so you might need it in a different scenario. If
>>> you want to do what you want I think you can use the annotation support in
>>> bnd for requirements.
>>>
>>> @RequireCapability( ns=“osgi.service”,
>>> filter=“(&(objectClass=org.apache.karaf.rcomp.api.RComponent)(name=${value}))”
>>> )
>>> @interface ReqRc { String value(); }
>>>
>>> @ReqRc(“mqtt” )
>>> @Component(property=“name=mqtt”)
>>> public class …
>>>
>>> Hope this helps.
>>>
>>> Kind regards,
>>>
>>> Peter Kriens
>>>
>>> On 17 Aug 2017, at 10:07, Christian Schneider <ch...@die-schneider.net>
>>>> wrote:
>>>>
>>>> I am currently working on a little framework that offers components
>>>> with a common service interface but different property value per component.
>>>>
>>>> LIke:
>>>>
>>>> https://github.com/cschneider/reactive-components/blob/maste
>>>> r/rcomp-mqtt/src/main/java/org/apache/karaf/rcomp/mqtt/MqttC
>>>> omponent.java
>>>> @Component(property="name=mqtt")
>>>>
>>>> A user of the mqtt component will use a filter like this:
>>>> @Reference(target="(name=mqtt)")
>>>>
>>>> Bnd creates a requirement like this:
>>>> osgi.service;filter:="(objectClass=org.apache.karaf.rcomp.ap
>>>> i.RComponent)";effective:=active
>>>>
>>>> The requirement does not include the filter.
>>>>
>>>> It would be nice if bndtools or karaf later could help me by auto
>>>> picking or recommending the mqtt component bundle when the user bundle is
>>>> required.
>>>>
>>>> Can I somehow make bnd create a requirement including a filter? .. or
>>>> alternatively is there another easy to use way how a specific provider can
>>>> announce itself and a user bundle can specify the requirement for a
>>>> specific provider?
>>>>
>>>> I think this same problem applies to Apache Camel. When a user bundle
>>>> uses a certain camel component then the resolver currently does not help
>>>> with this and the bundle fails at runtime.
>>>>
>>>> Christian
>>>>
>>>> --
>>>> Christian Schneider
>>>> http://www.liquid-reality.de
>>>>
>>>> Open Source Architect
>>>> http://www.talend.com
>>>>
>>>> _______________________________________________
>>>> OSGi Developer Mail List
>>>> osgi-dev@mail.osgi.org
>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>>>
>>> _______________________________________________
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>>
>>
>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> http://www.talend.com
>>
>> _______________________________________________
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>
>
>
> --
> http://about.me/milen
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
--
http://about.me/milen
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
