Right. Thanks, Tim! Cheers, =David
> On Jul 18, 2018, at 17:47, Tim Ward <[email protected]> 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 <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> Brilliant! Thank you. :-) >> >> >>> On Jul 18, 2018, at 14:46, Peter Kriens <[email protected] >>> <mailto:[email protected]>> 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 >>>> <[email protected] <mailto:[email protected]>> 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 >>>> [email protected] <mailto:[email protected]> >>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>> <https://mail.osgi.org/mailman/listinfo/osgi-dev> >>> >> >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] <mailto:[email protected]> >> https://mail.osgi.org/mailman/listinfo/osgi-dev >
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
