Re: [osgi-dev] Service binding order

[David Leangen via osgi-dev]

Right. Thanks, Tim!

Cheers,
=David



> On Jul 18, 2018, at 17:47, Tim Ward  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 > > wrote:
>> 
>> 
>> Brilliant! Thank you. :-)
>> 
>> 
>>> On Jul 18, 2018, at 14:46, Peter Kriens >> > 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  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 
>>> . They really shine in these 
>>> ordering issues.
>>> 
>>> Kind regards,
>>> 
>>> Peter Kriens
>>> 
>>> 
>>> 
 On 18 Jul 2018, at 00:16, David Leangen via osgi-dev 
 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 
 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
> 

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Service binding order

[Tim Ward via osgi-dev]

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  
> wrote:
> 
> 
> Brilliant! Thank you. :-)
> 
> 
>> On Jul 18, 2018, at 14:46, Peter Kriens > > 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  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 
>> . They really shine in these 
>> ordering issues.
>> 
>> Kind regards,
>> 
>>  Peter Kriens
>> 
>> 
>> 
>>> On 18 Jul 2018, at 00:16, David Leangen via osgi-dev 
>>> 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 
>>> 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

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Service binding order

[David Leangen via osgi-dev]

Brilliant! Thank you. :-)


> On Jul 18, 2018, at 14:46, Peter Kriens  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  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 
> . They really shine in these 
> ordering issues.
> 
> Kind regards,
> 
>   Peter Kriens
> 
> 
> 
>> On 18 Jul 2018, at 00:16, David Leangen via osgi-dev > > 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 
>> 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