Fwd: Blueprint property injection should not rely on presence of private field?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Fwd: Blueprint property injection should not rely on presence of private field?

Michael Vorburger
Hello Aries,

In https://github.com/opendaylight/netvirt/commit/13611ba65c69a2d19d997d4daba0a9cbcecb278a an ODL "bug" was fixed (or an Aries bug worked around?) by adding a private field, which is completely un-used, because the respective setter (just below) uses that property to construct something else with it.

In https://github.com/opendaylight/netvirt/blob/master/vpnservice/fibmanager/fibmanager-shell/src/main/resources/OSGI-INF/blueprint/blueprint.xml you can see the respective <property name="dataBroker" ref="dataBrokerRef"/>, and we've observed this injection itself seemed to eventually work (happen), but in tests that we do which verify for bundles and BP to come up seen that this bundle's BP didn't wait for that DataBroker to be available (so our respective test timed out).

It would seem as if the determination of what services a bundle has to wait on looked via introspection at private fields? That seems.. wrong, to me. At least very un-untuitive. It should look at the setter? Because that is what it actually uses to do the injection - so the presence of such a setter should be sufficient to determine service requirements - having to remember to have a dummy private field is very confusing.

Would it be fair to open a bug report in JIRA about this? Would a contribution proposing to change this be welcome?

Tx,
M.
--
Michael Vorburger, Red Hat
[hidden email] | IRC: vorburger @freenode | ~ = http://vorburger.ch

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: Blueprint property injection should not rely on presence of private field?

Michael Vorburger
+user list (previous reply was direct only):

On Mon, Jun 19, 2017 at 4:24 PM, Michael Vorburger <[hidden email]> wrote:
Hallo,

On Mon, Jun 19, 2017 at 1:56 PM, Christian Schneider <[hidden email]> wrote:
As far as I know blueprint looks at the <reference> Elements to determine which service to wait for.
Please open a jira issue to follow up on this.

please ignore this ...
 
You blueprint also refers to an ODL namespace. Could this be related in some way?

... yeah, this was related to that, we've meanwhile figured out https://git.opendaylight.org/gerrit/#/c/59158/ - sorry to bother, due to a mis-analysis of real cause and effect! ;-)
 

Christian


On 19.06.2017 13:02, Michael Vorburger wrote:
Hello Aries,

In https://github.com/opendaylight/netvirt/commit/13611ba65c69a2d19d997d4daba0a9cbcecb278a an ODL "bug" was fixed (or an Aries bug worked around?) by adding a private field, which is completely un-used, because the respective setter (just below) uses that property to construct something else with it.

In https://github.com/opendaylight/netvirt/blob/master/vpnservice/fibmanager/fibmanager-shell/src/main/resources/OSGI-INF/blueprint/blueprint.xml you can see the respective <property name="dataBroker" ref="dataBrokerRef"/>, and we've observed this injection itself seemed to eventually work (happen), but in tests that we do which verify for bundles and BP to come up seen that this bundle's BP didn't wait for that DataBroker to be available (so our respective test timed out).

It would seem as if the determination of what services a bundle has to wait on looked via introspection at private fields? That seems.. wrong, to me. At least very un-untuitive. It should look at the setter? Because that is what it actually uses to do the injection - so the presence of such a setter should be sufficient to determine service requirements - having to remember to have a dummy private field is very confusing.

Would it be fair to open a bug report in JIRA about this? Would a contribution proposing to change this be welcome?

Tx,
M.
--
Michael Vorburger, Red Hat
[hidden email] | IRC: vorburger @freenode | ~ = http://vorburger.ch


-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com


Loading...