Hello, Interesting thread.
Without fully appreciating what exactly a ping-pong DOMDataTreeChangeService is (doc?), IMHO if code needs to talk to (invoke methods of) a DOMDataTreeChangeService, then in "proper DI" one should be able to just ask for an @Inject'd DOMDataTreeChangeService, and not have to know how to perform magic on a DataBroker to adapt it, which is what getSupportedExtensions() looks like to me (that mechanism seems like something similar to Eclipse's generic IAdaptable pattern). So I think I like and +1 when you say "a change in core to also advertise the PingPongDataBroker instance with the DOMDataTreeChangeService interface" - that would seem like it enables "proper DI" to me. Tx, M. PS: Spring always blurred wiring too automagical for my taste. I like how in Guice and Dagger you decide under what interface you expose service implementations, explicitly. Sometimes that means exposing the same singleton bean under two interfaces (explicitly), and that's just fine IMHO. -- Michael Vorburger <vorbur...@redhat.com> | IRC: vorburger @freenode | ~ = http://vorburger.ch On Tue, Aug 23, 2016 at 6:04 PM, Tom Pantelis <tompante...@gmail.com> wrote: > I see that the registerDataTreeChangeListener isn't explicitly defined in > the DOMDataBroker interface as it doesn't extend DOMDataTreeChangeService. > But it is indirectly available via the getSupportedExtensions method, ie > > final DOMDataTreeChangeService treeService = (DOMDataTreeChangeService) > delegate.getSupportedExtensions().get( > DOMDataTreeChangeService.class); > if (treeService != null) { > treeService.registerDataTreeChangeListener(treeId, listener); > } > > This is actually what PingPongDataBroker.registerDataTreeChangeListener > does. Maybe it should be safe to have DOMDataBroker extend > DOMDataTreeChangeService in Carbon. > > The other option is to import the DOMDataTreeChangeService: > > <reference id="dataBrokerTreeService" > > interface="org.opendaylight.controller.md.sal.dom.api.DOMDataTreeChangeService" > odl:type="pingpong" /> > > but that would require a change in core to also advertise the > PingPongDataBroker > instance with the DOMDataTreeChangeService interface. > > I'll submit a patch to implement toString on PingPongDataBroker > appropriately to avoid future confusion. > > On Tue, Aug 23, 2016 at 10:45 AM, Martin Dindoffer < > martin.dindof...@pantheon.tech> wrote: > >> Actually, now I noticed we are using the >> pingpong.registerDataTreeChangeListener() >> method, so we need to cast the databroker to the PingPongDataBroker class. >> >> >> ------------------------------ >> *Od:* Martin Dindoffer <martin.dindof...@pantheon.tech> >> *Odoslané:* 23. augusta 2016 16:26 >> *Komu:* Tom Pantelis; Robert Varga >> *Kópia:* controller-dev@lists.opendaylight.org; >> rele...@lists.opendaylight.org >> *Predmet:* Re: [release] [controller-dev] Blueprint injects incorrect >> implementation of DOMDataBroker >> >> >> But the "instanceof PingPongDataBroker" returns false. Are we supposed to >> ignore that and just use it as DOMDataBroker interface? >> >> Thanks >> ------------------------------ >> *Od:* Tom Pantelis <tompante...@gmail.com> >> *Odoslané:* 23. augusta 2016 14:57 >> *Komu:* Robert Varga >> *Kópia:* Martin Dindoffer; rele...@lists.opendaylight.org; >> controller-dev@lists.opendaylight.org >> *Predmet:* Re: [controller-dev] [release] Blueprint injects incorrect >> implementation of DOMDataBroker >> >> I assume you printed the toString of the injected instance. >> PingPongDataBroker extends from ForwardingObject which forwards toString >> to the delegate which is the ConcurrentDOMDataBroker. Unfortunately this >> hides the fact that it's actually the PingPongDataBroker. To confirm it >> actually is, I implemented toString in PingPongDataBroker. So it does work >> correctly. >> >> Also looking at the DOMDataBroker services in karaf, you can see what >> you're bundle is using. Eg below, I changed the org.opendaylight.controlle >> r.samples.clustering-it-provider bundle to import the DOMDataBroker >> <service> with odl:type="pingpong": >> >> opendaylight-user@root>service:list DOMDataBroker >> [org.opendaylight.controller.md.sal.dom.api.DOMDataBroker] >> ---------------------------------------------------------- >> osgi.service.blueprint.compname = domPingPongDataBroker >> type = pingpong >> service.id = 794 >> Provided by : >> org.opendaylight.controller.sal-broker-impl (135) >> Used by: >> org.opendaylight.controller.sal-binding-broker-impl (137) >> org.opendaylight.controller.samples.clustering-it-provider (254) >> >> >> >> On Tue, Aug 23, 2016 at 6:13 AM, Robert Varga <n...@hq.sk> wrote: >> >>> On 08/23/2016 11:24 AM, Martin Dindoffer wrote: >>> > Hi, >>> > >>> > I am trying to migrate Topoprocessing project to Blueprint. We need >>> the >>> > /org.opendaylight.controller.md.sal.dom.broker.impl.PingPong >>> DataBroker/ >>> > class, however when using: >>> > >>> > <reference id="dataBrokerImpl" >>> > interface="org.opendaylight.controller.md.sal.dom.api.DOMDa >>> taBroker" >>> > odl:type="pingpong" /> >>> > >>> > blueprint injects the >>> > /org.opendaylight.controller.cluster.databroker.ConcurrentDO >>> MDataBroker >>> > / >>> > >>> > / >>> > / >>> > >>> > This looks like a bug in Controller, can someone please confirm? >>> >>> Looks like a bug to me. Can you file an issue in bugzilla, please? This >>> would be a release blocker... >>> >>> Bye, >>> Robert >>> >>> >>> _______________________________________________ >>> controller-dev mailing list >>> controller-dev@lists.opendaylight.org >>> https://lists.opendaylight.org/mailman/listinfo/controller-dev >>> >>> >> MartinDindoffer >> >> Software Developer >> >> >> Sídlo / Mlynské Nivy 56 / 821 05 Bratislava / Slovakia >> R&D centrum / Bôrická cesta 107 / 010 01 Žilina / Slovakia >> / martin.dindof...@pantheon.tech >> reception: +421 2 212 93 331 / www.pantheon.sk >> >> [image: logo] >> >> >> >> MartinDindoffer >> >> Software Developer >> >> >> Sídlo / Mlynské Nivy 56 / 821 05 Bratislava / Slovakia >> R&D centrum / Bôrická cesta 107 / 010 01 Žilina / Slovakia >> / martin.dindof...@pantheon.tech >> reception: +421 2 212 93 331 / www.pantheon.sk >> >> [image: logo] >> >> >> > > > _______________________________________________ > controller-dev mailing list > controller-dev@lists.opendaylight.org > https://lists.opendaylight.org/mailman/listinfo/controller-dev > >
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
