Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Added migration hints for GenericManagedObject

When upgrading from SNMP4J-Agent 2.x to 3.x some changes to your existing code might be necessary, which are described here:

Migration Tasks

Custom ManagedObjects should implement new GenericManagedObject Interface

SNMP4J-Agent 3 introduces a new interface GenericManagedObject which needs to be implemented by a ManagedObject to be found by the agent (Command handler respectively).  

The following SNMP4J-Agent classes already implement GenericManagedObject:

  • MOScalar
  • DefaultMOTable
  • MOSubtreeProxy
  • StaticMOGroup 

If your class extends one of these, you do not have to change anything. Otherwise, please implement GenericManagedObject instead ManagedObject.

Warning
titleDo not forget to implement GenericManagedObject Interface

If you do not implement GenericManagedObject for your ManagedObject, then it will not be found during MIB walk or for a GET request. It is then not accessible for SNMP requests. 


Tip

You can use generics even more precisely in your ManagedObject code if you overload the methods of the GenericManagedObject interface like AgentXNode of SNMP4J-AgentX version 3 does:


public void
prepare(SubRequest<?> request) {
prepare((SnmpRequest.SnmpSubRequest)request);
}

public void prepare(SnmpRequest.SnmpSubRequest request) {
addAgentXSet2Queue(request);
markAsProcessed(request);
}


SNMP4J ArgumentParser Interface

...

  1. MOChangeEvent in SNMP4J-Agent version 3.0 and later is fired by DefaultMOTable for row level changes too!
  2. In version 2.x and earlier, MOChangeEvent was fired on Variable updates only. If fired in the prepare phase of a SNMP SET request processing it was "deniable" and if fired after then commit it was not deniable.
  3. In version 3.1 and later, in addition to (2.) row level changes (added row, updated, and deleted rows) are fired as MOChangeEvents with a special OidType index.
  4. Note: In version 3.0.x, the new fields OidType and Modification were not set for MOChangeEvents fired on behalf of (2.). In version 3.1 or later OidType is always set to OidType.index and Modification is deducted from the Variable change that happened.
  5. If you trigger operations like writing MIB table objects to disk that itself modify those tables on row level, then you will need to ignore MOChangeEvents while these operations execute - at least you will have to ignore all MOChangeEvents with OidType.index in order to retain the same behaviour of your existing code as with SNMP4J-Agent 2.x or earlier.  


Content by Label
showLabelsfalse
max5
spacesSNMP4J
showSpacefalse
sortmodified
reversetrue
typepage
cqllabel in ("snmp4j-agent","migration") and type = "page" and space = "SNMP4J"
labelsmigration snmp4j-agent

...

Page properties
hiddentrue


Related issues