Java DMK expects decodeSnmpPdu to behave as follows:
Decode the SnmpMsg object and return a fully initialized SnmpPdu
Return null if it judges the SnmpMsg object to be unsafe; in this case, Java DMK will refuse the SnmpMsg object.
Throw an SnmpStatusException if the decoding failed or if the PDU contains illegal values; in this case, Java DMK will refuse the SnmpMsg object.
Java DMK expects encodeSnmpPdu to behave as follows:
Encode the SnmpPdu object and return a fully initialized SnmpMsg object
Throw an SnmpStatusException if the SnmpPdu object contains illegal values
Throw an SnmpTooBigException if the SnmpPdu object does not fit into the internal buffer used by Java DMK
Return null if it fails to secure the SnmpPdu object; in this case, Java DMK aborts the current request and reports an error. This probably means that the agent or the manager contains a bug
Because SnmpPdu and SnmpMsg are abstract classes, you should delegate their creation and initialization to an instance of SnmpPduFactoryBER and work on the result returned.
You can change the SnmpPduFactory object used by the SNMP adaptor by using the setPduFactory method, shown in Example 20–15.
... myAdaptor.setPduFactory(new MyFireWallPduFactory()) ; ... |
In Java DMK 4.2, the SnmpPduFactory was attached to the SnmpPeer object. In Java DMK 5.0, the SnmpPduFactory is attached to the SnmpSession. Factories set via the deprecated SnmpPeer API are reused in Java DMK 5.0. They can be changed using the setPduFactory method, as shown in Example 20–16:
... SnmpSession mySession = new SnmpSession() ; mySession.setPduFactory(new MyFireWallPduFactory()) ; mySession.snmpGet(myPeer, this, myVarBindList) ; ... |
Setting two different factories in the peer and in the session can lead to unpredictable behavior. Use the same factory at both levels.