date:20180717

Re: [osgi-dev] Service binding order

2018-07-17 Thread Peter Kriens via osgi-dev

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

Re: [osgi-dev] Re : Service binding order

2018-07-17 Thread Dirk Fauth via osgi-dev

Hi,

A good whiteboard implementation even takes care that your executor could
come and go or an executor with a higher service ranking could come.
Therefore the best thing is to keep the references of your items and
process them once the executor comes.

You should not rely on the order and I would also not use @Activate here.
At least not if you want to take care of dynamics and use DS.

Greez,
Dirk


David Leangen via osgi-dev  schrieb am Mi., 18.
Juli 2018, 03:25:

>
> To answer my own question…
>
> It looks like it may be easier to just use a ServiceTracker, which gets
> instantiated in the @Activate method. That way there are no timing issues.
>
>
> Cheers,
> =David
>
>
>
> On Jul 18, 2018, at 9:33, David Leangen  wrote:
>
>
> Hi Clément,
>
> Thanks for your reply.
>
> The problem here is that the Items are dynamic, which means that they can
> come and go at any time, even before the MyExecutor. :-(
> This happens regardless of the order, and that is exactly my problem.
>
>
> Cheers,
> =David
>
>
>
> On Jul 18, 2018, at 7:59, Clément Delgrange via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
> Hi David,
>
> From the spec I read:
>
> > 112.5.10 Binding Services
> >
> > When binding services, the references are processed in the order in
> which they are specified in the component description. That is, target
> services from the first specified reference are bound before services from
> the next specified reference.
>
> So, I understand that if your executor comes before yours items reference
> in the component declaration you have the garantee that the executor will
> be bounded before your items.
>
> Cheers,
> Clément.
>
>
>
>
>  Message d'origine 
> On 18 juil. 2018 à 00:16, David Leangen via osgi-dev <
> osgi-dev@mail.osgi.org > a écrit :
>
>
>
> 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
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Re : Service binding order

2018-07-17 Thread David Leangen via osgi-dev


To answer my own question…

It looks like it may be easier to just use a ServiceTracker, which gets 
instantiated in the @Activate method. That way there are no timing issues.


Cheers,
=David



> On Jul 18, 2018, at 9:33, David Leangen  wrote:
> 
> 
> Hi Clément,
> 
> Thanks for your reply.
> 
> The problem here is that the Items are dynamic, which means that they can 
> come and go at any time, even before the MyExecutor. :-(
> This happens regardless of the order, and that is exactly my problem.
> 
> 
> Cheers,
> =David
> 
> 
> 
>> On Jul 18, 2018, at 7:59, Clément Delgrange via osgi-dev 
>> mailto:osgi-dev@mail.osgi.org>> wrote:
>> 
>> Hi David, 
>> 
>> From the spec I read:
>> 
>> > 112.5.10 Binding Services
>> >
>> > When binding services, the references are processed in the order in which 
>> > they are specified in the component description. That is, target services 
>> > from the first specified reference are bound before services from the next 
>> > specified reference. 
>> 
>> So, I understand that if your executor comes before yours items reference in 
>> the component declaration you have the garantee that the executor will be 
>> bounded before your items. 
>> 
>> Cheers, 
>> Clément. 
>> 
>> 
>> 
>> 
>>  Message d'origine 
>> On 18 juil. 2018 à 00:16, David Leangen via osgi-dev < 
>> osgi-dev@mail.osgi.org  > a écrit :
>> 
>> 
>> 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] Re : Service binding order

2018-07-17 Thread David Leangen via osgi-dev


Hi Clément,

Thanks for your reply.

The problem here is that the Items are dynamic, which means that they can come 
and go at any time, even before the MyExecutor. :-(
This happens regardless of the order, and that is exactly my problem.


Cheers,
=David



> On Jul 18, 2018, at 7:59, Clément Delgrange via osgi-dev 
>  wrote:
> 
> Hi David, 
> 
> From the spec I read:
> 
> > 112.5.10 Binding Services
> >
> > When binding services, the references are processed in the order in which 
> > they are specified in the component description. That is, target services 
> > from the first specified reference are bound before services from the next 
> > specified reference. 
> 
> So, I understand that if your executor comes before yours items reference in 
> the component declaration you have the garantee that the executor will be 
> bounded before your items. 
> 
> Cheers, 
> Clément. 
> 
> 
> 
> 
>  Message d'origine 
> On 18 juil. 2018 à 00:16, David Leangen via osgi-dev < osgi-dev@mail.osgi.org 
> > a écrit :
> 
> 
> 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

[osgi-dev] Re : Service binding order

2018-07-17 Thread Clément Delgrange via osgi-dev

Hi David,

From the spec I read:

> 112.5.10 Binding Services
>
> When binding services, the references are processed in the order in which 
> they are specified in the component description. That is, target services 
> from the first specified reference are bound before services from the next 
> specified reference.

So, I understand that if your executor comes before yours items reference in 
the component declaration you have the garantee that the executor will be 
bounded before your items.

Cheers,
Clément.

 Message d'origine 
On 18 juil. 2018 à 00:16, David Leangen via osgi-dev a écrit :

> 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-dev] Service binding order

2018-07-17 Thread David Leangen via osgi-dev



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

Re: [osgi-dev] Tool/API to analyze component dependencies

2018-07-17 Thread Tim Ward via osgi-dev

Hi Alain

It’s not possible to model this accurately at build time because services may 
come and go at runtime, and their service properties may change with 
configuration. Added to this it is also possible to change the target filters 
on references which changes/restricts what they may bind to.

Another potential pitfall with the static approach is that not all services are 
provided with DS. At the very least you would also need to analyse the 
Provide-Capability header to find other services.

In summary, the best that you can do with static analysis is to come up with a 
guess of how things might wire. The Runtime DTOs will tell you how things have 
actually wired.

Best Regards,

Tim

> On 17 Jul 2018, at 13:14, BJ Hargrave via osgi-dev  
> wrote:
> 
> Yes, that is at runtime.
> --
> 
> BJ Hargrave
> Senior Technical Staff Member, IBM // office: +1 386 848 1781
> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
> hargr...@us.ibm.com
>  
>  
> - Original message -
> From: Alain Picard 
> To: hargr...@us.ibm.com
> Cc: osgi-dev@mail.osgi.org
> Subject: Re: [osgi-dev] Tool/API to analyze component dependencies
> Date: Tue, Jul 17, 2018 8:07 AM
>  
> Thanks BJ, from what I see that will do the trick, expect that it is runtime, 
> but I can live with that.
>  
> Alain
>  
> On Tue, Jul 17, 2018 at 7:58 AM BJ Hargrave  > wrote:
> Look at the ServiceComponentRuntime service: 
> https://osgi.org/specification/osgi.cmpn/7.0.0/service.component.html#service.component-introspection
>  
> 
>  
> It provides access to DTOs which describe each component description, 
> ComponentDescriptionDTO, and actual component instances, 
> ComponentConfigurationDTO. You can follows the ReferenceDTOs to see the 
> dependency graph.
>  
>  
> --
> 
> BJ Hargrave
> Senior Technical Staff Member, IBM // office: +1 386 848 1781
> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
> hargr...@us.ibm.com 
>  
>  
> - Original message -
> From: Alain Picard via osgi-dev  >
> Sent by: osgi-dev-boun...@mail.osgi.org 
> 
> To: osgi-dev@mail.osgi.org 
> Cc:
> Subject: [osgi-dev] Tool/API to analyze component dependencies
> Date: Tue, Jul 17, 2018 6:27 AM
>  
> As I'm going through our migration to DS I am in need of understanding our 
> component "graph" and to make sure there are no cycles. For the core ones, I 
> manually created of small dot file from the @Reference and used graphviz to 
> render.
>  
> Now I am looking for some API to automate the process, at dev time if 
> possible. AFAIK, DS will read the component.xml and create a registry with 
> all info. Can I make use of this resolution to grab all the info that I need?
>  
> Thanks
> Alain
> ___
> 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] Tool/API to analyze component dependencies

2018-07-17 Thread BJ Hargrave via osgi-dev

Yes, that is at runtime.
--BJ HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788hargr...@us.ibm.com
 
 
- Original message -From: Alain Picard To: hargr...@us.ibm.comCc: osgi-dev@mail.osgi.orgSubject: Re: [osgi-dev] Tool/API to analyze component dependenciesDate: Tue, Jul 17, 2018 8:07 AM 
Thanks BJ, from what I see that will do the trick, expect that it is runtime, but I can live with that.
 
Alain 

On Tue, Jul 17, 2018 at 7:58 AM BJ Hargrave  wrote:
Look at the ServiceComponentRuntime service: https://osgi.org/specification/osgi.cmpn/7.0.0/service.component.html#service.component-introspection
 
It provides access to DTOs which describe each component description, ComponentDescriptionDTO, and actual component instances, ComponentConfigurationDTO. You can follows the ReferenceDTOs to see the dependency graph.
 
 
--BJ HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788hargr...@us.ibm.com
 
 
- Original message -From: Alain Picard via osgi-dev Sent by: osgi-dev-boun...@mail.osgi.orgTo: osgi-dev@mail.osgi.orgCc:Subject: [osgi-dev] Tool/API to analyze component dependenciesDate: Tue, Jul 17, 2018 6:27 AM 
As I'm going through our migration to DS I am in need of understanding our component "graph" and to make sure there are no cycles. For the core ones, I manually created of small dot file from the @Reference and used graphviz to render.
 
Now I am looking for some API to automate the process, at dev time if possible. AFAIK, DS will read the component.xml and create a registry with all info. Can I make use of this resolution to grab all the info that I need?
 
Thanks
Alain
___OSGi Developer Mail Listosgi-dev@mail.osgi.orghttps://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] Tool/API to analyze component dependencies

2018-07-17 Thread BJ Hargrave via osgi-dev

Look at the ServiceComponentRuntime service: https://osgi.org/specification/osgi.cmpn/7.0.0/service.component.html#service.component-introspection
 
It provides access to DTOs which describe each component description, ComponentDescriptionDTO, and actual component instances, ComponentConfigurationDTO. You can follows the ReferenceDTOs to see the dependency graph.
 
 
--BJ HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788hargr...@us.ibm.com
 
 
- Original message -From: Alain Picard via osgi-dev Sent by: osgi-dev-boun...@mail.osgi.orgTo: osgi-dev@mail.osgi.orgCc:Subject: [osgi-dev] Tool/API to analyze component dependenciesDate: Tue, Jul 17, 2018 6:27 AM 
As I'm going through our migration to DS I am in need of understanding our component "graph" and to make sure there are no cycles. For the core ones, I manually created of small dot file from the @Reference and used graphviz to render.
 
Now I am looking for some API to automate the process, at dev time if possible. AFAIK, DS will read the component.xml and create a registry with all info. Can I make use of this resolution to grab all the info that I need?
 
Thanks
Alain
___OSGi Developer Mail Listosgi-dev@mail.osgi.orghttps://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

Re: [osgi-dev] Re : Service binding order

Re: [osgi-dev] Re : Service binding order

Re: [osgi-dev] Re : Service binding order

[osgi-dev] Re : Service binding order

[osgi-dev] Service binding order

Re: [osgi-dev] Tool/API to analyze component dependencies

Re: [osgi-dev] Tool/API to analyze component dependencies

Re: [osgi-dev] Tool/API to analyze component dependencies

9 matches

Site Navigation

Mail list logo

Footer information