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" <tim.w...@paremus.com>
An: "Thomas Driessen" <thomas.driessen...@gmail.com>
Cc: "Neil Bartlett" <njbartl...@gmail.com>; "OSGi Developer Mail List"
<osgi-dev@mail.osgi.org>
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
<thomas.driessen...@gmail.com> 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
<https://gitpod.io/#snapshot/9f4e97ad-0dd3-4360-8702-de0fedf9e51f>
Just type "resolve app" in the command line.
Kind regards,
Thomas
------ Originalnachricht ------
Von: "Tim Ward" <tim.w...@paremus.com>
An: "Thomas Driessen" <thomas.driessen...@gmail.com>
Cc: "Neil Bartlett" <njbartl...@gmail.com>; "OSGi Developer Mail List"
<osgi-dev@mail.osgi.org>
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
<thomas.driessen...@gmail.com> 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" <njbartl...@gmail.com>
An: "Thomas Driessen" <thomas.driessen...@gmail.com>; "OSGi
Developer Mail List" <osgi-dev@mail.osgi.org>
Cc: "Tim Ward" <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
<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<ITest> 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" <tim.w...@paremus.com>
An: "Thomas Driessen" <thomas.driessen...@gmail.com>; "OSGi
Developer Mail List" <osgi-dev@mail.osgi.org>
Cc: "Raymond Auge" <raymond.a...@liferay.com>
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
<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<ITest>.
I didn't think it makes sense to assign them vice versa, e.g.,
ITest with multiple or List<ITest> with mandatory? Or am I
wrong? If so, in what case would you use such a combination?
Kind regards,
Thomas
------ Originalnachricht ------
Von: "Raymond Auge" <raymond.a...@liferay.com>
An: "Thomas Driessen" <thomas.driessen...@gmail.com>; "OSGi
Developer Mail List" <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
<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<ITest> myTests;
}
and the observed behavior for this setup with different
combinations of the above named properties is:
<image.png>
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é <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect Liferay, Inc.
<http://www.liferay.com/> (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
(@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
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
