kandi X-RAY | mdsal Summary
kandi X-RAY | mdsal Summary
The Model-Driven Service Adaptation Layer (MD-SAL) is message-bus inspired extensible middleware component that provides messaging and data storage functionality based on data and interface models defined by application developers (i.e. user-defined models). // FIXME: Common integration point / reword this better. The MD-SAL uses YANG as the modeling language for both interface and data definitions, and provides a messaging and data-centric runtime for such services based on YANG modeling. The MD-SAL provides two different API types (flavours): +. Binding:: MD-SAL APIs which extensively uses APIs and classes generated from YANG models, which provides compile-time safety and allows developers to use more natural way to work with data. DOM:: (Document Object Model) APIs which uses DOM-like representation of data, which makes them more powerful, but provides less compile-time safety. NOTE: Model-driven nature of the MD-SAL and DOM-based APIs allows for behind-the-scene API and payload type mediation and transformation to facilitate seamless communication between applications - this enables for other components and applications to provide connectors / expose different set of APIs and derive most of its functionality purely from models, which all existing code can benefit from without modification. For example RESTCONF Connector is an application built on top of MD-SAL and exposes YANG-modeled application APIs transparently via HTTP and adds support for XML and JSON payload type.
Top functions reviewed by kandi - BETA
- Returns a transfer object .
- Creates children of the given effective statement .
- Tries to recompile the state of the service group .
- Get the codec codec context node .
- Recursively compute the child addressability summary .
- Determines if this group can be resolved .
- Formats the given text into a Paragraph .
- Create imports for a generated type .
- Find the class loader for the given class .
- Append snippet .
mdsal Key Features
mdsal Examples and Code Snippets
Trending Discussions on mdsal
I need to access the config subsystem (a.ka. the datastore) in OpenDaylight. I have read the user guide and know that the way to access it is via:...
ANSWERAnswered 2020-Aug-27 at 02:26
It looks like the config subsystem endpoint was deprecated back in Flourine--but the documentation has not been updated--even the latest release notes for Sodium indicate that they still maintain a CSS NETCONF server as part of their standard set of questions the dev team answers. I found this here:
I believe the MDSAL server is the only one available now, and it does (in its HELLO response) seem to indicate that it maintains the capabilities for all YANG-compliant modules. However, I cannot access these elements using the netopeer2-cli as the libyang parsing seems to issue a lot of errors. I suspect this is an issue related to netopeer2-cli and its requesting/parsing of the various YANG files after the initial HELLO and how it works with libyang to construct a local version of the model for the purposes of handling various NETCONF requests.
I am new at Opendaylight so I try to build Hello api on Magnesium via this tutorial.
I am going step by step what tutorial said but encountered an error when building app...
ANSWERAnswered 2020-Jul-03 at 03:10
The type of the
DataBroker constructor parameter for
HelloProvider in the blueprint XML (
org.opendaylight.controller.md.sal.binding.api.DataBroker) doesn't match the code (
I am working on an opendaylight project that uses apache karaf. At the start of the program, I need karaf to have some features installed. Currently (and this works) I manually type this into the shell and the features get installed:...
ANSWERAnswered 2020-Apr-03 at 21:39
we use the org.apache.karaf.features.cfg file exclusively in upstream ODL system test. you can see it inside this log, but specifically, here is what it looks like for one of our yangtools jobs:
I try to get the web interface of OpenDaylight controller (Magnesium Version).
But I cannot install the features
odl-restconf odl-l2switch-switch odl-mdsal-apidocs odl-dlux-all
A web interface is still available in ODL controller?...
ANSWERAnswered 2020-Apr-01 at 21:22
This question comes up periodically. the DLUX GUI project as well as the spanning-tree l2switch project are no longer maintained or part of an OpenDaylight release. You can try an older version of OpenDaylight. Or, if you are the developer type, you can try to bring DLUX and/or l2switch up to speed with the current ODL project and possibly get it to build and install.
I'm trying to compile a project but I'm running into a Maven plugin error.
I use Apache Maven 3.3.9 and
java-9-openjdk, with the command
ANSWERAnswered 2018-Oct-16 at 08:07
Based on the mention of
mdsal-binding in your POM, you’re trying to build an OpenDaylight project (I’m guessing either
transportpce) with JDK 9. We don’t support that yet; you must build with JDK 8.
I have installed the Beryllium release with Mininet on the side and was able to have everything running however I can't login. I installed the following features:...
ANSWERAnswered 2018-Dec-11 at 16:14
Beryllium is staggeringly old by ODL standards. It hasn't been supported upstream for many years. Please use a recent version of ODL.
Based on the doc, I downloaded & installed OpenDaylight
opendaylight-startup-archetype 1.1.0, then I wanted to install dlux-core, dluxapps and mdsal-apidocs to help navigating ODL interface via a browser. However, the karaf CLI said that those features weren't present in the repository.
How can I install DLUX and apidocs? Here's a list of available features.
Step to reproduce:...
ANSWERAnswered 2018-Sep-11 at 13:47
The API doc explorer feature is called odl-mdsal-apidocs, not mdsal-apidocs.
The dlux and dluxapps feature repos aren't included by the archetype - it's just a starting point - you can add whatever other feature you want. That said, the dlux and dluxapps projects are no longer actively maintained and thus were archived a few months ago. However you can still download and get them to build yourself. If you're interested in rebooting them upstream, contributions are always welcome.
I am able to generate Pojos from Yang files using opendaylight yangtools. however i constantly get this error after generation finishes after mvn generate-sources or mvn clean build:...
ANSWERAnswered 2018-Jul-22 at 17:15
org.opendaylight.mdsal.maven.sal.api.gen.plugin.CodeGeneratorImpl is incorrect - it should be org.opendaylight.mdsal.binding.maven.api.gen.plugin.CodeGeneratorImpl.
However you are deriving your pom from binding-parent so you don't need to re-define the yang-maven plugin at all as it is already defined/provided by binding-parent.
We are using ODL Nitrogen version. When we perform warm start (ie., restart Karaf servers, without deleting "KARAF_HOME/data" folder following bundles are in "GracePeriod" state for a long time, hence other application bundles that are dependent on this are failing. However when we start Karaf in a clean (without data folder) state, all bundles comes up fine.
We also noticed, netty.tcp port 2550 is not getting binded when bundles goes into failure state. Confirmed this port is not being used by other process also....
ANSWERAnswered 2018-Jul-06 at 07:58
You need to set SO_REUSEADDR to enable the port to be directly reused after it is closed. See https://docs.oracle.com/javase/7/docs/api/java/net/StandardSocketOptions.html#SO_REUSEADDR If you do not set this option then the port will stay blocked for a while dependent on the operation system.
You should also not forcefully kill a process if possible as this does not cleanly shut down the ports.
I have a YANG model (known to MDSAL) which I am using in an opendaylight application. In my application, I am presented with a json formatted String which I want to store in the MDSAL database. I could use the builder of the object that I wish to store and set its with fields presented in the json formatted String one by one but this is laborious and error prone.
Alternatively I could post from within the application to the Northbound API which will eventually write to the MDSAL datastore.
Is there a simpler way to do this?
ANSWERAnswered 2018-May-28 at 08:13
Assuming that your incoming JSON matches the structure of your YANG model exactly (does it?), I believe what you are really looking for is to transform that JSON into a "binding independant" (not setters of the generated Java class) internal model - NormalizedNode & Co. Somewhere in the controller or mdsal project there is a "codec" class that can do this.
You can either search for such code, and its usages (I find looking at tests are always useful) in the ODL controller and mdsal projects source code, or in other ODL projects which do similar things - I'm thinking specifically browsing around the jsonrpc and daexim projects sources; specifically this looks like it may inspire you: https://github.com/opendaylight/daexim/blob/stable/nitrogen/impl/src/main/java/org/opendaylight/daexim/impl/ImportTask.java
Best of luck.
No vulnerabilities reported
You can use mdsal like any standard Java library. Please include the the jar files in your classpath. You can also use any IDE and you can run and debug the mdsal component as you would do with any other Java program. Best practice is to use a build tool that supports dependency management such as Maven or Gradle. For Maven installation, please refer maven.apache.org. For Gradle installation, please refer gradle.org .
Reuse Trending Solutions
Subscribe to our newsletter for trending solutions and developer bootcamps
Share this Page