Right. Thanks, Tim! Cheers, =David
> On Jul 18, 2018, at 17:47, Tim Ward <tim.w...@paremus.com> wrote: > > Promises are great, and should be used much more often! > > Note that if you want to have more control of the threading then you can > instantiate a PromiseFactory with the executor that should be used to run > callbacks. In this case, for example, you may wish to use an Immediate > executor (available as a static method on PromiseFactory) to ensure that the > callbacks are always run without a thread switch. > > Best Regards, > > Tim > >> On 18 Jul 2018, at 07:50, David Leangen via osgi-dev <osgi-dev@mail.osgi.org >> <mailto:osgi-dev@mail.osgi.org>> wrote: >> >> >> Brilliant! Thank you. :-) >> >> >>> On Jul 18, 2018, at 14:46, Peter Kriens <peter.kri...@aqute.biz >>> <mailto:peter.kri...@aqute.biz>> wrote: >>> >>> A really elegant solution to these problems is to use a Promise … >>> >>> 1) Create a Deferrred >>> 2) Execute your item code through the promise of the deferred >>> 3) When the Executor reference is set, you resolve the deferred >>> >>> >>> @Component >>> public class Foo { >>> Deferred<Executor> deferred = new Deferred<>(); >>> >>> @Reference >>> void setExecutor( Executor e) { deferred.resolve(e); } >>> >>> @Reference( multiple/dynmaic) >>> void addItem( Item item) { >>> deferred.getPromise().thenAccept ( executor -> … ) >>> } >>> } >>> >>> This will automatically process your items after the executor is set. It >>> think it also easily extends to multiple dependencies but would have to >>> puzzle a bit. If you’re unfamiliar with Promises, I’ve written an app note, >>> ehh blog, recently about 1.1 Promises >>> http://aqute.biz/2018/06/28/Promises.html >>> <http://aqute.biz/2018/06/28/Promises.html>. They really shine in these >>> ordering issues. >>> >>> Kind regards, >>> >>> Peter Kriens >>> >>> >>> >>>> On 18 Jul 2018, at 00:16, David Leangen via osgi-dev >>>> <osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>> wrote: >>>> >>>> >>>> Hi! >>>> >>>> I have a component that acts a bit like a whiteboard provider. It looks >>>> something like this: >>>> >>>> public class MyWhiteboard >>>> { >>>> boolean isActive; >>>> >>>> @Reference MyExecutor executor; // Required service to execute on an Item >>>> >>>> @Reference(multiple/dynamic) >>>> void bindItem( Item item ) >>>> { >>>> if (isActivated) >>>> // add the Item >>>> else >>>> // Store the item to be added once this component is activated >>>> } >>>> >>>> void unbindItem( Item item ) >>>> { >>>> // Remove the item >>>> } >>>> >>>> @Activate >>>> void activate() >>>> { >>>> // execute non-processed Items >>>> isActivate = true; >>>> } >>>> } >>>> >>>> The MyExecutor must be present before an Item can be processed, but there >>>> is no guarantee as to the binding order. All I can think of doing is >>>> ensuring that the Component is Activated before processing. >>>> >>>> My question is: is there a more elegant / simpler / less error prone way >>>> of accomplishing this? >>>> >>>> >>>> Thanks! >>>> =David >>>> >>>> >>>> _______________________________________________ >>>> OSGi Developer Mail List >>>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> >>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>> <https://mail.osgi.org/mailman/listinfo/osgi-dev> >>> >> >> _______________________________________________ >> OSGi Developer Mail List >> osgi-dev@mail.osgi.org <mailto: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
