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]> > 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] > https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
