Debugging a Jini application is difficult because there are so many bits to it, and these bits are all running separately: the server for a service, the client, the lookup services, the remote activation daemons, and the HTTP servers. There are a few (not many) errors within the Jini objects themselves , but more importantly, many of these objects are implemented using multiple threads, and the flow of execution is not always clear. There are no magic "debug" flags that can be turned on to show what is happening.
On either the client or service side, a debugger such as jdb can be used to step through or trace execution of a client or server. Lots of print statements help too. There are also three flags that can be turned on to help:
java -Djava.security.debug=access \ -Dnet.jini.discovery.debug=1 \ -Djava.rmi.server.logCalls=true ...
These flags don't give complete information, but they do give some, and they can at least tell you if the application's parts are still living! If the java.security.debug property is set to access , then every time the application needs to check a security access (such as making a network connection, opening a file, etc.) it will print a message. If net.jini.discovery.debug is set to any non-null value, then any exceptions thrown during the discovery process will be printed. The final property will set on logging of RMI calls.