From OpenNMS

OpenNMS can be enabled with the Java debugging port (JDPA) by passing the -t option

Starting in debugging mode

sudo ./bin/opennms -t start

JDB

Once it is up and running you can then run a java debugger like JDB and connect to the running instance

17:04 ajb@pitcairn/x86_64 [opennms.git-svn] >jdb -attach localhost:8001
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
Initializing jdb ...
> 
Exception occurred: java.lang.OutOfMemoryError (uncaught)"thread=TCPRecord Chuncker[127.0.0.1:56876]", java.net.SocketInputStream.read(), line=153 bci=128

TCPRecord Chuncker[127.0.0.1:56876][1] resume
All threads resumed.
> catch uncaught java.lang.NullPointerException

Eclipse

Any part of OpenNMS can be debugged from Eclipse also. Having started opennms with -t, goto Eclipse. Goto the Run menu, select Debug Configurations. In the configuration dialog, select "Remote Java Application" in the left hand tree, and click the "New" button up the top. Give it a name, select the project containing the code you want to break into, leave connection type as "Standard (Socket Attach)", hostname as "localhost" or the name of the computer where OpenNMS is running, and Port to 8001.

Then, click "Debug". Set your breakpoints like normal, and when OpenNMS hits that bit of code, it'll break out in Eclipse and you can do normal debugging. I do not know what the behaviour is with multiple threads hitting the same breakpoint; or whether other threads are even running while debugging. Do not expect fully normal system-wide behaviour while doing this sort of debugging. But for finding out the root of a problem quickly, it's very very cool and quick

Even cooler, if you modify code while paused, it'll pick up the changes next time through that method, without having to do a full compile/restart cycle (at least for the webapp; haven't tried for other bits)