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
.
Do 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.
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
- The interface of the
org.snmp4j.util.ArgumentParser
has changed. Especially, theparse
method now returnsMap<String,List<Object>>
insteadMap<String,List<?>>
in version 2.x. - You need to change your source code accordingly, although this API change is binary compatible.
MOChangeEvent Granularity Changed
MOChangeEvent
in SNMP4J-Agent version 3.0 and later is fired byDefaultMOTable
for row level changes too!- In version 2.x and earlier,
MOChangeEvent
was fired onVariable
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. - In version 3.1 and later, in addition to (2.) row level changes (added row, updated, and deleted rows) are fired as
MOChangeEvent
s with a specialOidType
index
. - Note: In version 3.0.x, the new fields
OidType
andModification
were not set forMOChangeEvent
s fired on behalf of (2.). In version 3.1 or laterOidType
is always set toOidType.index
andModification
is deducted from theVariable
change that happened. - 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
MOChangeEvent
s while these operations execute - at least you will have to ignore allMOChangeEvent
s withOidType.index
in order to retain the same behaviour of your existing code as with SNMP4J-Agent 2.x or earlier.