The use of REQUIRED seems to be landing me with an unsatisfiable reference.
Here's the situation with the 'B2' service, which seems to be very happy:
23 | Active | 76 | 1.5.0.v20150907054257 | rosapi-worker-dummy-sdk
karaf@root>bundle:services 23
rosapi-worker-dummy-sdk (23) provides:
--------------------------------------
[com.basistech.ws.worker.api.WorkerComponentService]
karaf@root>scr:details
com.basistech.ws.sdk.dummy.impl.DummyWorkerComponentServiceImpl
Component Details
Name :
com.basistech.ws.sdk.dummy.impl.DummyWorkerComponentServiceImpl
State : REGISTERED
Properties :
component-name=template-tokenization
ComponentService.target=(component-name=template-tokenization)
component.name=com.basistech.ws.sdk.dummy.impl.DummyWorkerComponentServiceImpl
Warmup.target=(component-name=template-tokenization)
component.id=1
References
Reference : ComponentService
State : satisfied
Multiple : single
Optional : mandatory
Policy : static
Service Reference : No Services bound
Reference : Warmup
State : satisfied
Multiple : single
Optional : mandatory
Policy : static
Service Reference : No Services bound
For B3:
On my component, I have:
@Component(configurationPolicy = ConfigurationPolicy.REQUIRE,
configurationPid = "com.basistech.ws.worker")
and then:
@Reference(cardinality = ReferenceCardinality.AT_LEAST_ONE)
public void setAllComponents(List<WorkerComponentService> allComponents) {
But...
karaf@root>scr:details com.basistech.ws.worker.service.Worker
Component Details
Name : com.basistech.ws.worker.service.Worker
State : UNSATISFIED
Properties :
service.pid=com.basistech.ws.worker
configurationFilePathname=/Users/benson/x/rosapi1.5/assemblies/minimal-test/target/assembly/etc/anvils/worker-config.yaml
component.name=com.basistech.ws.worker.service.Worker
felix.fileinstall.filename=file:/Users/benson/x/rosapi1.5/assemblies/minimal-test/target/assembly/etc/com.basistech.ws.worker.cfg
component.id=2
References
Reference : AllComponents
State : unsatisfied
Multiple : multiple
Optional : mandatory
Policy : static
Service Reference : No Services bound
Reference : Bus
State : satisfied
Multiple : single
Optional : mandatory
Policy : static
Service Reference : No Services bound
On Mon, Sep 7, 2015 at 1:17 PM, Benson Margulies <[email protected]> wrote:
> On Mon, Sep 7, 2015 at 1:12 PM, David Jencks
> <[email protected]> wrote:
>> If cxf really does not have this capability, which I find hard to believe, I
>> would do the “publish to cxf” generically by having a component with a
>> dynamic reference (or a service tracker, but if your component is DS a
>> dynamic reference is easier) that uses service properties to figure out what
>> to tell cxf.
>>
>> A pretty simple example of how to do this is in the aries imx jmx-whiteboard
>> project, which is more complicated than you would need since it has to deal
>> with multiple MBean servers whereas I think you would have only one cxf.
>
> I am studying the relevant CXF code now, but I think that the thing
> you are looking for (register a service and CXF publishes it) will
> exist only if I make it exist.
>
> I have made a first pass at coding what you wrote here, but it doesn't
> work yet. What a surprise. More spelunking to do.
>
>
>
>>
>> thanks
>> david jencks
>>
>>> On Sep 7, 2015, at 12:46 PM, Benson Margulies <[email protected]> wrote:
>>>
>>> On Mon, Sep 7, 2015 at 12:45 PM, David Jencks
>>> <[email protected] <mailto:[email protected]>>
>>> wrote:
>>>> I think both of those suggestions are rather inappropriate to be used in a
>>>> DS component activate method, which generally should not block….. although
>>>> having it take a long time is also very much less than ideal.
>>>>
>>>> Certainly the second method seems to imply someone knows how many B2s
>>>> there are so the minimum cardinality can be set based on that knowledge,
>>>> possibly by whatever code has that knowledge. The (proprietary)
>>>> metatype/config admin I work with does this, it can count how many cm
>>>> Configurations there are for B2 and set properties based on that.
>>>>
>>>> If you make B3 expose a service and not be immediate, then it won’t be
>>>> activated until someone needs it and will pick up however many are then
>>>> available, even without the cardinality set.
>>>
>>> Dilemma: B3's job in life is to publish a JAX-RS service via CXF,
>>> which does not involve publishing an OSGi service. So I may need to
>>> stick with one of these less-than-ideal alternatives.
>>>
>>>
>>>>
>>>> david jencks
>>>>
>>>>> On Sep 7, 2015, at 11:46 AM, Neil Bartlett <[email protected]> wrote:
>>>>>
>>>>> Just to add a bit of detail…
>>>>>
>>>>> If you wait for 5 service instances before performing your
>>>>> initialisation, that’s great. But bear in mind that you might get a 6th
>>>>> and a 7th very soon afterwards, and depending on your implementation you
>>>>> may have to re-initialise each time that happens.
>>>>>
>>>>> If your (re)initialisation is expensive, you might want to avoid doing it
>>>>> too many times, especially if there is a rapid sequence of changes. This
>>>>> is typically the case during application startup for example. There are
>>>>> two general solutions to this:
>>>>>
>>>>> 1) You could start a timer each time the service set changes. If there
>>>>> are no further changes before the timer expires, then you do your
>>>>> reinitialisation. If there *are* changes then you cancel the existing
>>>>> timer and start a new one.
>>>>>
>>>>> 2) Use the Coordinator Service (OSGi Compendium Specification, chapter
>>>>> 130). Whoever is making changes to the set of installed bundles — e.g.
>>>>> the launcher, or some kind of management agent like FileInstall — should
>>>>> start a Coordination before it does anything, and end the coordination
>>>>> after that series of changes. Your component should be a Participant
>>>>> which detects whether there is a current coordination. If there is NO
>>>>> current coordination then it should immediately action any changes in the
>>>>> service set. However if there is a current coordination, then those
>>>>> changes should only be actioned when the coordination ends. This has the
>>>>> advantage that you don’t waste time waiting for an arbitrary-length timer
>>>>> to expire.
>>>>>
>>>>> Hope that helps. Regards,
>>>>> Neil
>>>>>
>>>>>
>>>>>
>>>>>> On 7 Sep 2015, at 16:16, Benson Margulies <[email protected]> wrote:
>>>>>>
>>>>>> That is precisely what I needed. Thanks.
>>>>>> On Sep 7, 2015 11:06 AM, "David Jencks" <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Benson,
>>>>>>>
>>>>>>> I don’t really understand what you are asking, but I’m going to guess.
>>>>>>>
>>>>>>> I think you have say 5 B2 services and you want B3 to wait to activate
>>>>>>> until all 5 B2’s are available?
>>>>>>>
>>>>>>> There is a way to do this with DS 1.3, but you have to make B3
>>>>>>> configuration-policy=REQUIRE.
>>>>>>>
>>>>>>> So you have in B3:
>>>>>>> @Component(configuration-policy=REQUIRE)
>>>>>>> public class B3 {
>>>>>>>
>>>>>>> @Reference(cardinality=MULTIPLE)
>>>>>>> void setB2(B2 b2) {}
>>>>>>> }
>>>>>>> In your (required) configuration for B3 you put a property
>>>>>>>
>>>>>>> B2.cardinality.minimum: 5
>>>>>>>
>>>>>>> that is, <reference-name>.cardinality.minimum = <number of required
>>>>>>> B2’s>
>>>>>>>
>>>>>>> Don’t mess with start levels, they will be unreliable for this purpose.
>>>>>>> There’s no guarantee that a bundle starting will start all the DS
>>>>>>> services
>>>>>>> it provides. They might have all sorts of unsatisfied dependencies…..
>>>>>>> such
>>>>>>> as missing configurations.
>>>>>>>
>>>>>>> Let me know if this guess is a total miss :-)
>>>>>>>
>>>>>>> thanks
>>>>>>> david jencks
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Sep 7, 2015, at 10:52 AM, Benson Margulies <[email protected]>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> I am hoping that David Jencks will continue his charity to strangers
>>>>>>> here.
>>>>>>>>
>>>>>>>> David, if you have any gogo jiras you'd like help with in return, just
>>>>>>> ask.
>>>>>>>>
>>>>>>>> Three bundles:
>>>>>>>>
>>>>>>>> B1 registers service S1.
>>>>>>>>
>>>>>>>> B2 consumes S1 and uses it in the implementation of S2. That is to
>>>>>>>> say, it picks up a reference to S1 with a DS @Reference with
>>>>>>>> cardinality MANDATORY.
>>>>>>>>
>>>>>>>> B3 consumes B2, but it anticipates that B2 will have siblings. So it
>>>>>>>> consumes a reference to a List<S2> with cardinality AT_LEAST_ONE.
>>>>>>>>
>>>>>>>> It can take B2 and buddies a bit of time to activate.
>>>>>>>>
>>>>>>>> I appreciate that the most general case is intended to be that
>>>>>>>> services come and go, and B3 should dynamically reconfigure itself.
>>>>>>>> I'd rather not do that yet; I'd like to arrange things so that B3
>>>>>>>> waits to finish starting itself until all the B2-ish guys are fully
>>>>>>>> set up.
>>>>>>>>
>>>>>>>> Assuming that B2 and friends are all started at an earlier start
>>>>>>>> level, is there an 'esthetic' way to arrange this? Or should I really
>>>>>>>> suck it up and do the late-binding so that B3 says, 'OK, _now_ I need
>>>>>>>> B2 service x=y, block until it's available?'
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>>>> For additional commands, e-mail: [email protected]
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>>> For additional commands, e-mail: [email protected]
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [email protected]
>>>>> For additional commands, e-mail: [email protected]
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> <mailto:[email protected]>
>>>> For additional commands, e-mail: [email protected]
>>>> <mailto:[email protected]>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> <mailto:[email protected]>
>>> For additional commands, e-mail: [email protected]
>>> <mailto:[email protected]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
