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]
