We can advertise PingPongDataBroker with DOMDataTreeChangeService if needed but I think we should be able to have DOMDataBroker extend DOMDataTreeChangeService in Carbon.
On Tue, Aug 23, 2016 at 1:36 PM, Michael Vorburger <vorbur...@redhat.com> wrote: > 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.getSupportedExtension >> s().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
