On Jun 3, 2008, at 5:52 PM, DJ Gregor wrote: > I wonder how hard it would be to pass such exceptions in SNMP4J up > to the right walker in OpenNMS.
There would be some changes needed in SNMP4J to make it really show any value. Currently SNMP4J either swallows runtime exceptions that it encounters or throws a new RuntimeException whose cause is the original exception. Even if we catch these, it's hard to know programmatically what kind of problem they describe as there isn't really an exception hierarchy in SNMP4J. I made a change for 1.5.92 that turns on logging within SNMP4J and directs its log messages to their own log file, snmp4j-internal.log. I think that will be a big help, but more still needs to be done to make these messages easier to interpret. Many of them are logged from way down in the depths of the BER class methods, are quite cryptic, and contain no information about the peer to which they pertain, which is what DJ means about the log messages not being linked. > this stuff is hard enough as it is for the 99.999% of our user base > who are non-experts with SNMP. I would say it's too hard for non-experts. > Anyone have any ideas on how we might do this? See above :) -jeff ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Please read the OpenNMS Mailing List FAQ: http://www.opennms.org/index.php/Mailing_List_FAQ opennms-devel mailing list To *unsubscribe* or change your subscription options, see the bottom of this page: https://lists.sourceforge.net/lists/listinfo/opennms-devel
