date:20190218

Re: [osgi-dev] Clarification on reference behavior regarding field injection

2019-02-18 Thread Thomas Driessen via osgi-dev


Hi Tim,

you're right. Now the build succeeds :/ Don't know what went wrong 
during the last build.
The error message seems to have been introduced by bnd 4.2? This is a 
great aid :) In 4.1. the build suceeded also when I'm did not declare 
the field volatile.


Thanks for your patience.

Kind regards,
Thomas

-- Originalnachricht --
Von: "Tim Ward" 
An: "Thomas Driessen" 
Cc: "Neil Bartlett" ; "OSGi Developer Mail List" 


Gesendet: 18.02.2019 13:54:20
Betreff: Re: [osgi-dev] Clarification on reference behavior regarding 
field injection



Hi,

The build works fine for me in GitPod. You probably have corrupt things 
in your local repo, either delete them or force an update of snapshots 
(-U on the command line). Note that you also get a nice error message 
for the case that you claim didn’t work:


[ERROR] Failed to execute goal 
biz.aQute.bnd:bnd-maven-plugin:4.2.0-SNAPSHOT:bnd-process (default) on 
project impl: In component io.jatoms.osgi.refs.ComponentImpl, field 
tests policy is 'dynamic' and field is not volatile. -> [Help 1]


Best Regards,

Tim

On 18 Feb 2019, at 13:45, Thomas Driessen 
 wrote:


Hi Tim,

I added this plugin repository and change the bnd.version property to 
4.2.0-SNAPSHOT, but still get errors during the build with eroor 
message "No plugin found for prefix 'bnd-indexer' ..."

Maven complains about several metadata being invalid, e.g.:

The metadata 
/home/gitpod/.m2/repository/biz/aQute/bnd/bnd-maven-plugin/4.2.0-SNAPSHOT/maven-metadata-Bnd 
Snapshots.xml is invalid
The metadata 
/home/gitpod/.m2/repository/biz/aQute/bnd/bnd-maven-plugin/4.2.0-SNAPSHOT/maven-metadata-Bnd 
Snapshots.xml is invalid
The POM for 
biz.aQute.bnd:bnd-maven-plugin:jar:4.2.0-20190215.224729-106 is 
invalid

...

You can have a look at the workspace and try it for yourself if you 
want: https://gitpod.io#snapshot/9f4e97ad-0dd3-4360-8702-de0fedf9e51f 



Just type "resolve app" in the command line.

Kind regards,
Thomas



-- Originalnachricht --
Von: "Tim Ward" 
An: "Thomas Driessen" 
Cc: "Neil Bartlett" ; "OSGi Developer Mail List" 


Gesendet: 18.02.2019 10:53:23
Betreff: Re: [osgi-dev] Clarification on reference behavior regarding 
field injection


When I change the version number of bnd to 4.2.0 in the standard 
enRoute setup, then some of the bnd-plugins can not be found by 
maven.


That’s because and 4.2.0 isn’t released yet - you need to add a 
plugin repository containing 4.2.0-SNAPSHOT (which is also the 
version you should be using. If you look at the readme for the bnd 
repo on GitHub you can see the repo url is 
https://bndtools.jfrog.io/bndtools/libs-snapshot/


Tim

On 18 Feb 2019, at 10:51, Thomas Driessen 
 wrote:


Hi Neil,

thanks for this small history lesson on OSGi. You live, you learn. 
The why is in most cases so much more interesting than the what  :)


I will open an issue on Github then for bnd.

Kind regards,
Thomas

-- Originalnachricht --
Von: "Neil Bartlett" 
An: "Thomas Driessen" ; "OSGi 
Developer Mail List" 

Cc: "Tim Ward" 
Gesendet: 18.02.2019 10:44:14
Betreff: Re: [osgi-dev] Clarification on reference behavior 
regarding field injection





On Mon, Feb 18, 2019 at 9:39 AM Thomas Driessen via osgi-dev 
 wrote:

Hi Tim,

as always thanks for your super detailed answer!

Just two more questions on this topic:

1) Out of curiosity: do you know why the decision was made to make 
the default for @Reference List static, reluctant? For 
0/1..1 this makes sense to me, but for me an expected default 
behavior for 0/1..n references would have been dynamic, greedy, so 
that I end up with some services isntead of probably none.


The default is reluctant because "greedy" did not exist until DS 
1.2. If the default had been made greedy at that time, components 
coded before DS 1.2 would have seen a substantial change in 
behaviour that could be considered non-backwards-compatible.


Static has *always* been the default over dynamic, because dynamic 
forces the developer to understand thread safety and to code the 
component much more cautiously. Static is simple and safe.




2) The observed Exception for optional/dynamic/reluctant: Is it 
intended? I tried to switch to bnd 4.2.0 to see if this exxception 
occurs there too, but was unable to do so. When I change the 
version number of bnd to 4.2.0 in the standard enRoute setup, then 
some of the bnd-plugins can not be found by maven.


Probably not expected, this smells like a bug.



Kind regards,
Thomas

-- Originalnachricht --
Von: "Tim Ward" 
An: "Thomas Driessen" ; "OSGi 
Developer Mail List" 

Cc: "Raymond Auge" 
Gesendet: 18.02.2019 10:15:54
Betreff: Re: [osgi-dev] Clarification on reference behavior 
regarding field injection



Hi Thomas,

Just to clarify, the behaviour that you see with static reluctant 
services will always look “odd” for cardinalities other than 
mandatory, and what you’ve recorded is 100% correct

Re: [osgi-dev] Clarification on reference behavior regarding field injection

2019-02-18 Thread Tim Ward via osgi-dev

Hi, 

The build works fine for me in GitPod. You probably have corrupt things in your 
local repo, either delete them or force an update of snapshots (-U on the 
command line). Note that you also get a nice error message for the case that 
you claim didn’t work:

[ERROR] Failed to execute goal 
biz.aQute.bnd:bnd-maven-plugin:4.2.0-SNAPSHOT:bnd-process (default) on project 
impl: In component io.jatoms.osgi.refs.ComponentImpl, field tests policy is 
'dynamic' and field is not volatile. -> [Help 1]

Best Regards,

Tim

> On 18 Feb 2019, at 13:45, Thomas Driessen  
> wrote:
> 
> Hi Tim,
> 
> I added this plugin repository and change the bnd.version property to 
> 4.2.0-SNAPSHOT, but still get errors during the build with eroor message "No 
> plugin found for prefix 'bnd-indexer' ..." 
> Maven complains about several metadata being invalid, e.g.:
> 
> The metadata 
> /home/gitpod/.m2/repository/biz/aQute/bnd/bnd-maven-plugin/4.2.0-SNAPSHOT/maven-metadata-Bnd
>  Snapshots.xml is invalid
> The metadata 
> /home/gitpod/.m2/repository/biz/aQute/bnd/bnd-maven-plugin/4.2.0-SNAPSHOT/maven-metadata-Bnd
>  Snapshots.xml is invalid
> The POM for biz.aQute.bnd:bnd-maven-plugin:jar:4.2.0-20190215.224729-106 is 
> invalid
> ...
> 
> You can have a look at the workspace and try it for yourself if you want: 
> https://gitpod.io#snapshot/9f4e97ad-0dd3-4360-8702-de0fedf9e51f 
>  
> 
> Just type "resolve app" in the command line.
> 
> Kind regards,
> Thomas
> 
> 
> 
> -- Originalnachricht --
> Von: "Tim Ward" mailto:tim.w...@paremus.com>>
> An: "Thomas Driessen"  >
> Cc: "Neil Bartlett" mailto:njbartl...@gmail.com>>; 
> "OSGi Developer Mail List"  >
> Gesendet: 18.02.2019 10:53:23
> Betreff: Re: [osgi-dev] Clarification on reference behavior regarding field 
> injection
> 
>>> When I change the version number of bnd to 4.2.0 in the standard enRoute 
>>> setup, then some of the bnd-plugins can not be found by maven.
>> 
>> That’s because and 4.2.0 isn’t released yet - you need to add a plugin 
>> repository containing 4.2.0-SNAPSHOT (which is also the version you should 
>> be using. If you look at the readme for the bnd repo on GitHub you can see 
>> the repo url is https://bndtools.jfrog.io/bndtools/libs-snapshot/ 
>>  
>> 
>> Tim
>> 
>>> On 18 Feb 2019, at 10:51, Thomas Driessen >> > wrote:
>>> 
>>> Hi Neil,
>>> 
>>> thanks for this small history lesson on OSGi. You live, you learn. The why 
>>> is in most cases so much more interesting than the what  :)
>>> 
>>> I will open an issue on Github then for bnd. 
>>> 
>>> Kind regards,
>>> Thomas
>>> 
>>> -- Originalnachricht --
>>> Von: "Neil Bartlett" mailto:njbartl...@gmail.com>>
>>> An: "Thomas Driessen" >> >; "OSGi Developer Mail List" 
>>> mailto:osgi-dev@mail.osgi.org>>
>>> Cc: "Tim Ward" mailto:tim.w...@paremus.com>>
>>> Gesendet: 18.02.2019 10:44:14
>>> Betreff: Re: [osgi-dev] Clarification on reference behavior regarding field 
>>> injection
>>> 

 On Mon, Feb 18, 2019 at 9:39 AM Thomas Driessen via osgi-dev 
 mailto:osgi-dev@mail.osgi.org>> wrote:
 Hi Tim,

 as always thanks for your super detailed answer! 

 Just two more questions on this topic:

 1) Out of curiosity: do you know why the decision was made to make the 
 default for @Reference List static, reluctant? For 0/1..1 this 
 makes sense to me, but for me an expected default behavior for 0/1..n 
 references would have been dynamic, greedy, so that I end up with some 
 services isntead of probably none.

 The default is reluctant because "greedy" did not exist until DS 1.2. If 
 the default had been made greedy at that time, components coded before DS 
 1.2 would have seen a substantial change in behaviour that could be 
 considered non-backwards-compatible.

 Static has *always* been the default over dynamic, because dynamic forces 
 the developer to understand thread safety and to code the component much 
 more cautiously. Static is simple and safe.

 2) The observed Exception for optional/dynamic/reluctant: Is it intended? 
 I tried to switch to bnd 4.2.0 to see if this exxception occurs there too, 
 but was unable to do so. When I change the version number of bnd to 4.2.0 
 in the standard enRoute setup, then some of the bnd-plugins can not be 
 found by maven.

 Probably not expected, this smells like a bug.

 Kind regards,
 Thomas

 -- Originalnachricht --
 Von: "Tim Ward" mailto:tim.w...@paremus.com>>
 An: "Thomas Driessen" >>> >; "OSGi Developer Mail List" 
 mailto:osgi-dev@mail.osgi.org>>
 Cc: "Raymond

Re: [osgi-dev] Clarification on reference behavior regarding field injection

2019-02-18 Thread Thomas Driessen via osgi-dev


Hi Tim,

I added this plugin repository and change the bnd.version property to 
4.2.0-SNAPSHOT, but still get errors during the build with eroor message 
"No plugin found for prefix 'bnd-indexer' ..."

Maven complains about several metadata being invalid, e.g.:

The metadata 
/home/gitpod/.m2/repository/biz/aQute/bnd/bnd-maven-plugin/4.2.0-SNAPSHOT/maven-metadata-Bnd 
Snapshots.xml is invalid
The metadata 
/home/gitpod/.m2/repository/biz/aQute/bnd/bnd-maven-plugin/4.2.0-SNAPSHOT/maven-metadata-Bnd 
Snapshots.xml is invalid
The POM for biz.aQute.bnd:bnd-maven-plugin:jar:4.2.0-20190215.224729-106 
is invalid

...

You can have a look at the workspace and try it for yourself if you 
want: https://gitpod.io#snapshot/9f4e97ad-0dd3-4360-8702-de0fedf9e51f


Just type "resolve app" in the command line.

Kind regards,
Thomas



-- Originalnachricht --
Von: "Tim Ward" 
An: "Thomas Driessen" 
Cc: "Neil Bartlett" ; "OSGi Developer Mail List" 


Gesendet: 18.02.2019 10:53:23
Betreff: Re: [osgi-dev] Clarification on reference behavior regarding 
field injection


When I change the version number of bnd to 4.2.0 in the standard 
enRoute setup, then some of the bnd-plugins can not be found by 
maven.


That’s because and 4.2.0 isn’t released yet - you need to add a plugin 
repository containing 4.2.0-SNAPSHOT (which is also the version you 
should be using. If you look at the readme for the bnd repo on GitHub 
you can see the repo url is 
https://bndtools.jfrog.io/bndtools/libs-snapshot/


Tim

On 18 Feb 2019, at 10:51, Thomas Driessen 
 wrote:


Hi Neil,

thanks for this small history lesson on OSGi. You live, you learn. The 
why is in most cases so much more interesting than the what  :)


I will open an issue on Github then for bnd.

Kind regards,
Thomas

-- Originalnachricht --
Von: "Neil Bartlett" 
An: "Thomas Driessen" ; "OSGi Developer 
Mail List" 

Cc: "Tim Ward" 
Gesendet: 18.02.2019 10:44:14
Betreff: Re: [osgi-dev] Clarification on reference behavior regarding 
field injection





On Mon, Feb 18, 2019 at 9:39 AM Thomas Driessen via osgi-dev 
 wrote:

Hi Tim,

as always thanks for your super detailed answer!

Just two more questions on this topic:

1) Out of curiosity: do you know why the decision was made to make 
the default for @Reference List static, reluctant? For 0/1..1 
this makes sense to me, but for me an expected default behavior for 
0/1..n references would have been dynamic, greedy, so that I end up 
with some services isntead of probably none.


The default is reluctant because "greedy" did not exist until DS 1.2. 
If the default had been made greedy at that time, components coded 
before DS 1.2 would have seen a substantial change in behaviour that 
could be considered non-backwards-compatible.


Static has *always* been the default over dynamic, because dynamic 
forces the developer to understand thread safety and to code the 
component much more cautiously. Static is simple and safe.




2) The observed Exception for optional/dynamic/reluctant: Is it 
intended? I tried to switch to bnd 4.2.0 to see if this exxception 
occurs there too, but was unable to do so. When I change the version 
number of bnd to 4.2.0 in the standard enRoute setup, then some of 
the bnd-plugins can not be found by maven.


Probably not expected, this smells like a bug.



Kind regards,
Thomas

-- Originalnachricht --
Von: "Tim Ward" 
An: "Thomas Driessen" ; "OSGi 
Developer Mail List" 

Cc: "Raymond Auge" 
Gesendet: 18.02.2019 10:15:54
Betreff: Re: [osgi-dev] Clarification on reference behavior 
regarding field injection



Hi Thomas,

Just to clarify, the behaviour that you see with static reluctant 
services will always look “odd” for cardinalities other than 
mandatory, and what you’ve recorded is 100% correct behaviour.


Static references force the component to be re-created if the value 
of the reference changesReluctant references avoid rebinding the 
service unless it is required


Therefore:

An optional reference bound to nothing will never bind to anything 
again (unless the component is re-created for another reason) 
because having zero references is valid and you are reluctant to 
re-create the component instanceAn optional reference bound to a 
service will not change until that service is unregistered 
(ignoring all new services), at which point it will either:Pick up 
the highest ranked of any matching registered servicesBind to 
nothing if no matching services are availableA multiple reference 
bound to nothing will behave exactly like an optional componentA 
multiple reference bound to one or more services will not change 
until any of the bound services are unregistered (ignoring all new 
services), at which point it will either:Pick up all the available 
registered servicesBind to nothing if no matching services are 
availableAn “at least one" reference bound to one or more services 
will not change until any of the bound services are unregistered 
(ignoring all new

Re: [osgi-dev] Clarification on reference behavior regarding field injection

2019-02-18 Thread Tim Ward via osgi-dev

> When I change the version number of bnd to 4.2.0 in the standard enRoute 
> setup, then some of the bnd-plugins can not be found by maven.

That’s because and 4.2.0 isn’t released yet - you need to add a plugin 
repository containing 4.2.0-SNAPSHOT (which is also the version you should be 
using. If you look at the readme for the bnd repo on GitHub you can see the 
repo url is https://bndtools.jfrog.io/bndtools/libs-snapshot/ 
 

Tim

> On 18 Feb 2019, at 10:51, Thomas Driessen  
> wrote:
> 
> Hi Neil,
> 
> thanks for this small history lesson on OSGi. You live, you learn. The why is 
> in most cases so much more interesting than the what  :)
> 
> I will open an issue on Github then for bnd. 
> 
> Kind regards,
> Thomas
> 
> -- Originalnachricht --
> Von: "Neil Bartlett" mailto:njbartl...@gmail.com>>
> An: "Thomas Driessen"  >; "OSGi Developer Mail List" 
> mailto:osgi-dev@mail.osgi.org>>
> Cc: "Tim Ward" mailto:tim.w...@paremus.com>>
> Gesendet: 18.02.2019 10:44:14
> Betreff: Re: [osgi-dev] Clarification on reference behavior regarding field 
> injection
> 
>> 
>> 
>> On Mon, Feb 18, 2019 at 9:39 AM Thomas Driessen via osgi-dev 
>> mailto:osgi-dev@mail.osgi.org>> wrote:
>> Hi Tim,
>> 
>> as always thanks for your super detailed answer! 
>> 
>> Just two more questions on this topic:
>> 
>> 1) Out of curiosity: do you know why the decision was made to make the 
>> default for @Reference List static, reluctant? For 0/1..1 this makes 
>> sense to me, but for me an expected default behavior for 0/1..n references 
>> would have been dynamic, greedy, so that I end up with some services isntead 
>> of probably none.
>> 
>> The default is reluctant because "greedy" did not exist until DS 1.2. If the 
>> default had been made greedy at that time, components coded before DS 1.2 
>> would have seen a substantial change in behaviour that could be considered 
>> non-backwards-compatible.
>> 
>> Static has *always* been the default over dynamic, because dynamic forces 
>> the developer to understand thread safety and to code the component much 
>> more cautiously. Static is simple and safe.
>>  
>> 
>> 2) The observed Exception for optional/dynamic/reluctant: Is it intended? I 
>> tried to switch to bnd 4.2.0 to see if this exxception occurs there too, but 
>> was unable to do so. When I change the version number of bnd to 4.2.0 in the 
>> standard enRoute setup, then some of the bnd-plugins can not be found by 
>> maven.
>> 
>> Probably not expected, this smells like a bug.
>>  
>> 
>> Kind regards,
>> Thomas
>> 
>> -- Originalnachricht --
>> Von: "Tim Ward" mailto:tim.w...@paremus.com>>
>> An: "Thomas Driessen" > >; "OSGi Developer Mail List" 
>> mailto:osgi-dev@mail.osgi.org>>
>> Cc: "Raymond Auge" > >
>> Gesendet: 18.02.2019 10:15:54
>> Betreff: Re: [osgi-dev] Clarification on reference behavior regarding field 
>> injection
>> 
>>> Hi Thomas,
>>> 
>>> Just to clarify, the behaviour that you see with static reluctant services 
>>> will always look “odd” for cardinalities other than mandatory, and what 
>>> you’ve recorded is 100% correct behaviour.
>>> 
>>> Static references force the component to be re-created if the value of the 
>>> reference changes
>>> Reluctant references avoid rebinding the service unless it is required
>>> 
>>> Therefore:
>>> 
>>> An optional reference bound to nothing will never bind to anything again 
>>> (unless the component is re-created for another reason) because having zero 
>>> references is valid and you are reluctant to re-create the component 
>>> instance
>>> An optional reference bound to a service will not change until that service 
>>> is unregistered (ignoring all new services), at which point it will either:
>>> Pick up the highest ranked of any matching registered services
>>> Bind to nothing if no matching services are available
>>> A multiple reference bound to nothing will behave exactly like an optional 
>>> component
>>> A multiple reference bound to one or more services will not change until 
>>> any of the bound services are unregistered (ignoring all new services), at 
>>> which point it will either:
>>> Pick up all the available registered services
>>> Bind to nothing if no matching services are available
>>> An “at least one" reference bound to one or more services will not change 
>>> until any of the bound services are unregistered (ignoring all new 
>>> services), at which point it will either:
>>> Pick up all the available registered services
>>> Make the component unsatisfied
>>> 
>>> 
>>> The end result of this is that references that can accept zero will tend to 
>>> zero over time, and then tend to stay with zero bound references. At least 
>>> one references will tend to a small number of “stable” services with new 
>>> services ignored.
>>> 
>>> In general references of these

Re: [osgi-dev] Clarification on reference behavior regarding field injection

2019-02-18 Thread Thomas Driessen via osgi-dev


Hi Neil,

thanks for this small history lesson on OSGi. You live, you learn. The 
why is in most cases so much more interesting than the what  :)


I will open an issue on Github then for bnd.

Kind regards,
Thomas

-- Originalnachricht --
Von: "Neil Bartlett" 
An: "Thomas Driessen" ; "OSGi Developer 
Mail List" 

Cc: "Tim Ward" 
Gesendet: 18.02.2019 10:44:14
Betreff: Re: [osgi-dev] Clarification on reference behavior regarding 
field injection





On Mon, Feb 18, 2019 at 9:39 AM Thomas Driessen via osgi-dev 
 wrote:

Hi Tim,

as always thanks for your super detailed answer!

Just two more questions on this topic:

1) Out of curiosity: do you know why the decision was made to make the 
default for @Reference List static, reluctant? For 0/1..1 this 
makes sense to me, but for me an expected default behavior for 0/1..n 
references would have been dynamic, greedy, so that I end up with some 
services isntead of probably none.


The default is reluctant because "greedy" did not exist until DS 1.2. 
If the default had been made greedy at that time, components coded 
before DS 1.2 would have seen a substantial change in behaviour that 
could be considered non-backwards-compatible.


Static has *always* been the default over dynamic, because dynamic 
forces the developer to understand thread safety and to code the 
component much more cautiously. Static is simple and safe.




2) The observed Exception for optional/dynamic/reluctant: Is it 
intended? I tried to switch to bnd 4.2.0 to see if this exxception 
occurs there too, but was unable to do so. When I change the version 
number of bnd to 4.2.0 in the standard enRoute setup, then some of the 
bnd-plugins can not be found by maven.


Probably not expected, this smells like a bug.



Kind regards,
Thomas

-- Originalnachricht --
Von: "Tim Ward" 
An: "Thomas Driessen" ; "OSGi Developer 
Mail List" 

Cc: "Raymond Auge" 
Gesendet: 18.02.2019 10:15:54
Betreff: Re: [osgi-dev] Clarification on reference behavior regarding 
field injection



Hi Thomas,

Just to clarify, the behaviour that you see with static reluctant 
services will always look “odd” for cardinalities other than 
mandatory, and what you’ve recorded is 100% correct behaviour.


Static references force the component to be re-created if the value 
of the reference changesReluctant references avoid rebinding the 
service unless it is required


Therefore:

An optional reference bound to nothing will never bind to anything 
again (unless the component is re-created for another reason) because 
having zero references is valid and you are reluctant to re-create 
the component instanceAn optional reference bound to a service will 
not change until that service is unregistered (ignoring all new 
services), at which point it will either:Pick up the highest ranked 
of any matching registered servicesBind to nothing if no matching 
services are availableA multiple reference bound to nothing will 
behave exactly like an optional componentA multiple reference bound 
to one or more services will not change until any of the bound 
services are unregistered (ignoring all new services), at which point 
it will either:Pick up all the available registered servicesBind to 
nothing if no matching services are availableAn “at least one" 
reference bound to one or more services will not change until any of 
the bound services are unregistered (ignoring all new services), at 
which point it will either:Pick up all the available registered 
servicesMake the component unsatisfied



The end result of this is that references that can accept zero will 
tend to zero over time, and then tend to stay with zero bound 
references. At least one references will tend to a small number of 
“stable” services with new services ignored.


In general references of these types should be dynamic or greedy (or 
both).


Best Regards,

Tim

On 18 Feb 2019, at 09:38, Thomas Driessen via osgi-dev 
 wrote:


Oh Sorry :/

Those combinations with cardinalities optional/mandatory have been 
assigned to ITest, those with multiple/at_least_one have been 
assigned to List.


I didn't think it makes sense to assign them vice versa, e.g., ITest 
with multiple or List with mandatory? Or am I wrong? If so, 
in what case would you use such a combination?


Kind regards,
Thomas

-- Originalnachricht --
Von: "Raymond Auge" 
An: "Thomas Driessen" ; "OSGi 
Developer Mail List" 

Gesendet: 16.02.2019 17:42:19
Betreff: Re: [osgi-dev] Clarification on reference behavior 
regarding field injection


You're chart doesn't appear to list _which_ field (Reference) was 
associated with any given line (collection vs. scalar). It makes a 
difference.


- Ray

On Sat, Feb 16, 2019 at 9:15 AM Thomas Driessen via osgi-dev 
 wrote:

Hi,

I'm trying to get an overview over the effects of different 
combinations of cardinality, policy and policyOption within a 
@Reference annotation for a field.


My Example looks like this:

@Component
public class

Re: [osgi-dev] Clarification on reference behavior regarding field injection

2019-02-18 Thread Neil Bartlett via osgi-dev

On Mon, Feb 18, 2019 at 9:39 AM Thomas Driessen via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> Hi Tim,
>
> as always thanks for your super detailed answer!
>
> Just two more questions on this topic:
>
> 1) Out of curiosity: do you know why the decision was made to make the
> default for @Reference List static, reluctant? For 0/1..1 this makes
> sense to me, but for me an expected default behavior for 0/1..n references
> would have been dynamic, greedy, so that I end up with some services
> isntead of probably none.
>

The default is reluctant because "greedy" did not exist until DS 1.2. If
the default had been made greedy at that time, components coded before DS
1.2 would have seen a substantial change in behaviour that could be
considered non-backwards-compatible.

Static has *always* been the default over dynamic, because dynamic forces
the developer to understand thread safety and to code the component much
more cautiously. Static is simple and safe.


>
> 2) The observed Exception for optional/dynamic/reluctant: Is it intended?
> I tried to switch to bnd 4.2.0 to see if this exxception occurs there too,
> but was unable to do so. When I change the version number of bnd to 4.2.0
> in the standard enRoute setup, then some of the bnd-plugins can not be
> found by maven.
>

Probably not expected, this smells like a bug.


>
> Kind regards,
> Thomas
>
> -- Originalnachricht --
> Von: "Tim Ward" 
> An: "Thomas Driessen" ; "OSGi Developer
> Mail List" 
> Cc: "Raymond Auge" 
> Gesendet: 18.02.2019 10:15:54
> Betreff: Re: [osgi-dev] Clarification on reference behavior regarding
> field injection
>
> Hi Thomas,
>
> Just to clarify, the behaviour that you see with static reluctant services
> will always look “odd” for cardinalities other than mandatory, and what
> you’ve recorded is 100% correct behaviour.
>
>
>- Static references force the component to be re-created if the value
>of the reference changes
>- Reluctant references avoid rebinding the service unless it is
>required
>
>
> Therefore:
>
>
>- An optional reference bound to nothing will never bind to anything
>again (unless the component is re-created for another reason) because
>having zero references is valid and you are reluctant to re-create the
>component instance
>- An optional reference bound to a service will not change until that
>service is unregistered (ignoring all new services), at which point it will
>either:
>   - Pick up the highest ranked of any matching registered services
>   - Bind to nothing if no matching services are available
>- A multiple reference bound to nothing will behave exactly like an
>optional component
>- A multiple reference bound to one or more services will not change
>until any of the bound services are unregistered (ignoring all new
>services), at which point it will either:
>   - Pick up all the available registered services
>   - Bind to nothing if no matching services are available
>- An “at least one" reference bound to one or more services will not
>change until any of the bound services are unregistered (ignoring all new
>services), at which point it will either:
>   - Pick up all the available registered services
>   - Make the component unsatisfied
>
>
>
> The end result of this is that references that can accept zero will tend
> to zero over time, and then tend to stay with zero bound references. At
> least one references will tend to a small number of “stable” services with
> new services ignored.
>
> In general references of these types should be dynamic or greedy (or both).
>
> Best Regards,
>
> Tim
>
> On 18 Feb 2019, at 09:38, Thomas Driessen via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
> Oh Sorry :/
>
> Those combinations with cardinalities optional/mandatory have been
> assigned to ITest, those with multiple/at_least_one have been assigned to
> List.
>
> I didn't think it makes sense to assign them vice versa, e.g., ITest with
> multiple or List with mandatory? Or am I wrong? If so, in what case
> would you use such a combination?
>
> Kind regards,
> Thomas
>
> -- Originalnachricht --
> Von: "Raymond Auge" 
> An: "Thomas Driessen" ; "OSGi Developer
> Mail List" 
> Gesendet: 16.02.2019 17:42:19
> Betreff: Re: [osgi-dev] Clarification on reference behavior regarding
> field injection
>
> You're chart doesn't appear to list _which_ field (Reference) was
> associated with any given line (collection vs. scalar). It makes a
> difference.
>
> - Ray
>
> On Sat, Feb 16, 2019 at 9:15 AM Thomas Driessen via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
>> Hi,
>>
>> I'm trying to get an overview over the effects of different combinations
>> of cardinality, policy and policyOption within a @Reference annotation for
>> a field.
>>
>> My Example looks like this:
>>
>> @Component
>> public class MyComp{
>>   @Reference(...)
>>   ITest myTest;
>>
>>   @Reference(...)
>>   List myTests;
>> }
>>

Re: [osgi-dev] Clarification on reference behavior regarding field injection

2019-02-18 Thread Thomas Driessen via osgi-dev


Hi Tim,

as always thanks for your super detailed answer!

Just two more questions on this topic:

1) Out of curiosity: do you know why the decision was made to make the 
default for @Reference List static, reluctant? For 0/1..1 this 
makes sense to me, but for me an expected default behavior for 0/1..n 
references would have been dynamic, greedy, so that I end up with some 
services isntead of probably none.


2) The observed Exception for optional/dynamic/reluctant: Is it 
intended? I tried to switch to bnd 4.2.0 to see if this exxception 
occurs there too, but was unable to do so. When I change the version 
number of bnd to 4.2.0 in the standard enRoute setup, then some of the 
bnd-plugins can not be found by maven.


Kind regards,
Thomas

-- Originalnachricht --
Von: "Tim Ward" 
An: "Thomas Driessen" ; "OSGi Developer 
Mail List" 

Cc: "Raymond Auge" 
Gesendet: 18.02.2019 10:15:54
Betreff: Re: [osgi-dev] Clarification on reference behavior regarding 
field injection



Hi Thomas,

Just to clarify, the behaviour that you see with static reluctant 
services will always look “odd” for cardinalities other than mandatory, 
and what you’ve recorded is 100% correct behaviour.


Static references force the component to be re-created if the value of 
the reference changesReluctant references avoid rebinding the service 
unless it is required


Therefore:

An optional reference bound to nothing will never bind to anything 
again (unless the component is re-created for another reason) because 
having zero references is valid and you are reluctant to re-create the 
component instanceAn optional reference bound to a service will not 
change until that service is unregistered (ignoring all new services), 
at which point it will either:Pick up the highest ranked of any 
matching registered servicesBind to nothing if no matching services are 
availableA multiple reference bound to nothing will behave exactly like 
an optional componentA multiple reference bound to one or more services 
will not change until any of the bound services are unregistered 
(ignoring all new services), at which point it will either:Pick up all 
the available registered servicesBind to nothing if no matching 
services are availableAn “at least one" reference bound to one or more 
services will not change until any of the bound services are 
unregistered (ignoring all new services), at which point it will 
either:Pick up all the available registered servicesMake the component 
unsatisfied



The end result of this is that references that can accept zero will 
tend to zero over time, and then tend to stay with zero bound 
references. At least one references will tend to a small number of 
“stable” services with new services ignored.


In general references of these types should be dynamic or greedy (or 
both).


Best Regards,

Tim

On 18 Feb 2019, at 09:38, Thomas Driessen via osgi-dev 
 wrote:


Oh Sorry :/

Those combinations with cardinalities optional/mandatory have been 
assigned to ITest, those with multiple/at_least_one have been assigned 
to List.


I didn't think it makes sense to assign them vice versa, e.g., ITest 
with multiple or List with mandatory? Or am I wrong? If so, in 
what case would you use such a combination?


Kind regards,
Thomas

-- Originalnachricht --
Von: "Raymond Auge" 
An: "Thomas Driessen" ; "OSGi Developer 
Mail List" 

Gesendet: 16.02.2019 17:42:19
Betreff: Re: [osgi-dev] Clarification on reference behavior regarding 
field injection


You're chart doesn't appear to list _which_ field (Reference) was 
associated with any given line (collection vs. scalar). It makes a 
difference.


- Ray

On Sat, Feb 16, 2019 at 9:15 AM Thomas Driessen via osgi-dev 
 wrote:

Hi,

I'm trying to get an overview over the effects of different 
combinations of cardinality, policy and policyOption within a 
@Reference annotation for a field.


My Example looks like this:

@Component
public class MyComp{
  @Reference(...)
  ITest myTest;

  @Reference(...)
  List myTests;
}

and the observed behavior for this setup with different combinations 
of the above named properties is:



I'm especially interested in the yellow marked cases: Is this an 
intended behavior?


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



--
Raymond Augé  
(@rotty3000)
Senior Software Architect Liferay, Inc.  
(@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  
(@OSGiAlliance)

___
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] Clarification on reference behavior regarding field injection

2019-02-18 Thread Tim Ward via osgi-dev

Hi Thomas,

Just to clarify, the behaviour that you see with static reluctant services will 
always look “odd” for cardinalities other than mandatory, and what you’ve 
recorded is 100% correct behaviour.

Static references force the component to be re-created if the value of the 
reference changes
Reluctant references avoid rebinding the service unless it is required

Therefore:

An optional reference bound to nothing will never bind to anything again 
(unless the component is re-created for another reason) because having zero 
references is valid and you are reluctant to re-create the component instance
An optional reference bound to a service will not change until that service is 
unregistered (ignoring all new services), at which point it will either:
Pick up the highest ranked of any matching registered services
Bind to nothing if no matching services are available
A multiple reference bound to nothing will behave exactly like an optional 
component
A multiple reference bound to one or more services will not change until any of 
the bound services are unregistered (ignoring all new services), at which point 
it will either:
Pick up all the available registered services
Bind to nothing if no matching services are available
An “at least one" reference bound to one or more services will not change until 
any of the bound services are unregistered (ignoring all new services), at 
which point it will either:
Pick up all the available registered services
Make the component unsatisfied


The end result of this is that references that can accept zero will tend to 
zero over time, and then tend to stay with zero bound references. At least one 
references will tend to a small number of “stable” services with new services 
ignored.

In general references of these types should be dynamic or greedy (or both).

Best Regards,

Tim

> On 18 Feb 2019, at 09:38, Thomas Driessen via osgi-dev 
>  wrote:
> 
> Oh Sorry :/
> 
> Those combinations with cardinalities optional/mandatory have been assigned 
> to ITest, those with multiple/at_least_one have been assigned to List.
> 
> I didn't think it makes sense to assign them vice versa, e.g., ITest with 
> multiple or List with mandatory? Or am I wrong? If so, in what case 
> would you use such a combination?
> 
> Kind regards,
> Thomas
> 
> -- Originalnachricht --
> Von: "Raymond Auge"  >
> An: "Thomas Driessen"  >; "OSGi Developer Mail List" 
> mailto:osgi-dev@mail.osgi.org>>
> Gesendet: 16.02.2019 17:42:19
> Betreff: Re: [osgi-dev] Clarification on reference behavior regarding field 
> injection
> 
>> You're chart doesn't appear to list _which_ field (Reference) was associated 
>> with any given line (collection vs. scalar). It makes a difference.
>> 
>> - Ray
>> 
>> On Sat, Feb 16, 2019 at 9:15 AM Thomas Driessen via osgi-dev 
>> mailto:osgi-dev@mail.osgi.org>> wrote:
>> Hi,
>> 
>> I'm trying to get an overview over the effects of different combinations of 
>> cardinality, policy and policyOption within a @Reference annotation for a 
>> field.
>> 
>> My Example looks like this:
>> 
>> @Component 
>> public class MyComp{
>>   @Reference(...)
>>   ITest myTest;
>> 
>>   @Reference(...)
>>   List myTests;
>> }
>> 
>> and the observed behavior for this setup with different combinations of the 
>> above named properties is:
>> 
>> 
>> I'm especially interested in the yellow marked cases: Is this an intended 
>> behavior?
>> 
>> Kind regards,
>> Thomas
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org 
>> https://mail.osgi.org/mailman/listinfo/osgi-dev 
>> 
>> 
>> -- 
>> Raymond Augé  (@rotty3000)
>> Senior Software Architect Liferay, Inc.  (@Liferay)
>> Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
> ___
> 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] Clarification on reference behavior regarding field injection

2019-02-18 Thread Thomas Driessen via osgi-dev


Oh Sorry :/

Those combinations with cardinalities optional/mandatory have been 
assigned to ITest, those with multiple/at_least_one have been assigned 
to List.


I didn't think it makes sense to assign them vice versa, e.g., ITest 
with multiple or List with mandatory? Or am I wrong? If so, in 
what case would you use such a combination?


Kind regards,
Thomas

-- Originalnachricht --
Von: "Raymond Auge" 
An: "Thomas Driessen" ; "OSGi Developer 
Mail List" 

Gesendet: 16.02.2019 17:42:19
Betreff: Re: [osgi-dev] Clarification on reference behavior regarding 
field injection


You're chart doesn't appear to list _which_ field (Reference) was 
associated with any given line (collection vs. scalar). It makes a 
difference.


- Ray

On Sat, Feb 16, 2019 at 9:15 AM Thomas Driessen via osgi-dev 
 wrote:

Hi,

I'm trying to get an overview over the effects of different 
combinations of cardinality, policy and policyOption within a 
@Reference annotation for a field.


My Example looks like this:

@Component
public class MyComp{
  @Reference(...)
  ITest myTest;

  @Reference(...)
  List myTests;
}

and the observed behavior for this setup with different combinations 
of the above named properties is:



I'm especially interested in the yellow marked cases: Is this an 
intended behavior?


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



--
Raymond Augé  
(@rotty3000)
Senior Software Architect Liferay, Inc.  
(@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  
(@OSGiAlliance)___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Clarification on reference behavior regarding field injection

Re: [osgi-dev] Clarification on reference behavior regarding field injection

Re: [osgi-dev] Clarification on reference behavior regarding field injection

Re: [osgi-dev] Clarification on reference behavior regarding field injection

Re: [osgi-dev] Clarification on reference behavior regarding field injection

Re: [osgi-dev] Clarification on reference behavior regarding field injection

Re: [osgi-dev] Clarification on reference behavior regarding field injection

Re: [osgi-dev] Clarification on reference behavior regarding field injection

Re: [osgi-dev] Clarification on reference behavior regarding field injection

9 matches

Site Navigation

Mail list logo

Footer information