When upgrading from SNMP4J-Agent 2.x to 3.x some changes to your existing code might be necessary, which are described here:
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
.
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. |
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:
|
org.snmp4j.util.ArgumentParser
has changed. Especially, the parse
method now returns Map<String,List<Object>>
instead Map<String,List<?>>
in version 2.x. MOChangeEvent
in SNMP4J-Agent version 3.0 and later is fired by DefaultMOTable
for row level changes too!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.MOChangeEvent
s with a special OidType
index
.OidType
and Modification
were not set for MOChangeEvent
s 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.MOChangeEvent
s while these operations execute - at least you will have to ignore all MOChangeEvent
s with OidType.index
in order to retain the same behaviour of your existing code as with SNMP4J-Agent 2.x or earlier.
|