The ConcurrentDOMDataBroker implements DOMDataTreeCommitCohortRegistry but it does not advertise it from what I can see. Must've been an oversight. It either needs to add it as an extension or, better yet, advertise the DOMDataTreeCommitCohortRegistry interface in the OSGi service registry via blueprint.
On Tue, Jan 3, 2017 at 9:27 AM, Diego Jesus Granados Lopez < diego.jesus.granados.lo...@ericsson.com> wrote: > Hi, > > > > I’m trying to perform validation to datastore operations (they would be > unvaluable for preventing severe situations caused because of bad > configuration in SFC project). I found the fix to [1] which would be pretty > much what I need, but I’m struggling to find a way to use the proposed > correction. Specifically, from the DOMDataBroker that I’m provided via > blueprint inyection, I’m unable to access this cohorts API (specifically, I > can create a DOMDataTreeCommitCohort, but I’m unable to register it). I > throughtfully read the thread [2] on DOMDataBroker delegation / extension > model, but still can’t understand how to retrieve the > ConcurrentDOMDataBroker that I could use in order to register my cohort. > From that thread, my understanding is that I shouldn’t try to cast the > DOMDataBroker directly to ConcurrentDOMDataBroker (this is correct, even > though toString() in the inyected DOMDataBroker instance returns “Clustered > ConcurrentDOMDataBroker”, direct cast fails), but to access extensions in > order to use more specific / improved behaviors. But examining all > supported extensions, the list only contains an instance of > org.opendaylight.controller.md.sal.dom.api.DOMDataTreeChangeService, > which neither can be used to register the cohort / access the > ConcurrentDOMDataBroker underneath. > > > > So the question is: could you provide an example on how could a > DOMDataTreeCommitCohort be registered by an application, provided a > DOMDataBroker instance is available? > > > > PS. Just in case the question raises, I’m aware of the performance > implications introduced by the use of synchronous DOMDataTreeCommitCohort > validations. Let’s assume we’d be using this for cases on which the ability > to guarantee data model consistency is more valuable than the performance > price to pay. > > > > Best regards, > > Diego > > > > [1] https://bugs.opendaylight.org/show_bug.cgi?id=1435 > > [2] https://lists.opendaylight.org/pipermail/controller-dev/ > 2016-August/012505.html > > _______________________________________________ > 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
