Thanks a lot for your quick response. I just created a bug [1] for tracking this change
[1] https://bugs.opendaylight.org/show_bug.cgi?id=7469 From: Tom Pantelis [mailto:tompante...@gmail.com] Sent: martes, 03 de enero de 2017 16:32 To: Diego Jesus Granados Lopez <diego.jesus.granados.lo...@ericsson.com> Cc: controller-dev@lists.opendaylight.org Subject: Re: [controller-dev] Use of DOMDataTreeCommitCohorts 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<mailto: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<mailto: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
