[MDSAL-699] CodeGenerator cannot implement listeners for notifications inside groupings Created: 19/Oct/21  Updated: 19/Oct/21  Resolved: 19/Oct/21

Status: Resolved
Project: mdsal
Component/s: Binding codegen
Affects Version/s: 7.0.6
Fix Version/s: None

Type: Bug Priority: Medium
Reporter: Robert Magaldi Assignee: Unassigned
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File test-grouping-notif@2021-10-18.yang    

 Description   

We are experimenting with Broadband forum yang files and noticed that yang notifications are declared in groupings. The groupings are used by containers. 

The MD-SAL code generator does not create listeners for this type of yang, nor does it even recognize that notification "object" is even a notification. 

Is this a bug in the mdsal code generator? 

A yang file is attached, as will as an even simplified version below. We have a grouping declared with is a notification for device state changes. A container has a sub container that uses this grouping.  

module test-grouping-notif-a {
  yang-version 1.1;
  namespace "urn:test:yang:grouping:notifa";
  prefix test-grouping-notifa;

  organization "Some organization";
  contact "Some contact";
  description
    "This is a test yang created to reproduce an issue where groupings 
     including notifications do not generate a listener from the md-sal code generator";
  revision 2021-10-18 {
    description "test";
  }

  grouping notification-grouping-a {
    description "This is a grouping which contains a notification";
    notification device-state-change {
      description "Device state changed";
      leaf event {
        type enumeration {
          enum online;
          enum offline;
        }

        description "events definition for device state change";
      }
    }
  }

  container grouping-notif-a {
    description "Just a test yang model";
    container device-notification-a {
      description "A notification that is wrapped in a grouping";
      uses notification-grouping-a;
    }
  }
}

The code generator creates a "DeviceStateChange" interface like this:

 

    @Generated("mdsal-binding-generator")
     public interface DeviceStateChange
         extends
         DataObject,
         Augmentable<DeviceStateChange>,
         InstanceNotification<DeviceStateChange, DeviceNotificationA>
     {
  
    @Generated("mdsal-binding-generator")
     public interface DeviceNotificationA    
         extends
         ChildOf<GroupingNotifA>,
          Augmentable<DeviceNotificationA>,
         NotificationGroupingA
     {
 
    @Generated("mdsal-binding-generator")
         public interface NotificationGroupingA
         extends
         DataObject
     {

 

 

So, there is no object that extends "NotificationListener" here. 

 

 

The code generator is show in a snippet from a pom.xml file. 

org.opendaylight.mdsal.binding.maven.api.gen.plugin.CodeGeneratorImpl version 7.0.6

pom.xml generator:

<plugin>
 <groupId>org.opendaylight.yangtools</groupId>
 <artifactId>yang-maven-plugin</artifactId>
 <version>6.0.5</version>
 <dependencies>
  <dependency>
   <groupId>org.opendaylight.mdsal</groupId>
   <artifactId>maven-sal-api-gen-plugin</artifactId>
   <version>7.0.6</version>
   <type>jar</type>
  </dependency>
 </dependencies>
 <executions>
  <execution>
   <id>binding</id>
   <goals>
    <goal>generate-sources</goal>
   </goals>
   <configuration>
    <yangFilesRootDir>${yangFilesPath}</yangFilesRootDir>
    <codeGenerators>
     <generator>
      <codeGeneratorClass>org.opendaylight.mdsal.binding.maven.api.gen.plugin.CodeGeneratorImpl</codeGeneratorClass>
      <outputBaseDir>${salGeneratorPath}</outputBaseDir>
     </generator>
    </codeGenerators>
    <inspectDependencies>true</inspectDependencies>
   </configuration>
  </execution>
 </executions>
</plugin>

 Comments   
Comment by Robert Varga [ 19/Oct/21 ]

This a instance (YANG 1.1) notification. These follow a different codegen pattern from global (YANG 1.0) notifications. This is similar to how YANG 1.1 actions result in different codegen from YANG 1.0 rpcs.

Generated files for this model are:

./$YangModelBindingProvider.java
./$YangModuleInfoImpl.java
./GroupingNotifBuilder.java
./grouping/notif/DeviceNotificationBuilder.java
./grouping/notif/device/notification/DeviceStateChangeBuilder.java
./grouping/notif/device/notification/DeviceStateChange.java
./grouping/notif/DeviceNotification.java
./GroupingNotif.java
./grouping/notif/ManagedDeviceBuilder.java
./grouping/notif/managed/device/DeviceBuilder.java
./grouping/notif/managed/device/Device.java
./grouping/notif/managed/device/DeviceKey.java
./grouping/notif/ManagedDevice.java
./NotificationGrouping.java
./TestGroupingNotifData.java

here DeviceStateChange.java has the following:

@Generated("mdsal-binding-generator")
public interface DeviceStateChange
    extends
    DataObject,
    Augmentable<DeviceStateChange>,
    InstanceNotification<DeviceStateChange, DeviceNotification>
{
Comment by Robert Magaldi [ 19/Oct/21 ]

Are there any examples on how to generate listeners using yang 1.1 models which are created in this manner (using InstanceNotification)? Thanks for your time. 

Found this

https://jira.opendaylight.org/browse/MDSAL-494

https://jira.opendaylight.org/browse/MDSAL-700

Does this mean they are not supported  yet?

Comment by Robert Varga [ 19/Oct/21 ]

Yes it does. MDSAL-494 is the tracker for the mdsal-binding-api part of the support. The patch associated with that issue is pretty much the API we are looking to expose.
MDSAL-700 is about refreshing the YANG 1.0 notification design to Java 8+.

Comment by Robert Magaldi [ 19/Oct/21 ]

One more question , although I hate to ask this question.. 

Is there an estimated time when the 1.1 support for notifications would be available?  Is it months or a year? 

Thanks

Generated at Wed Feb 07 20:10:37 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.