The Debug class

We have already seen the skeleton application using the Debug class. This is in package org.jtrix.project.libjtrix.debug.

To turn debugging on fully and use it we use something like these lines:

    // Enable debug output, including from with Beatrix. The arguments
    // are an identifier string, the bits to enable, and the bits to disable.
    // -1 as the first argument means enable all arguments. There are 63
    // useful bits (it's a long). At the time of writing these include INFO and
    // WARN among others.

    Debug.set("My netlet", -1, 0); 

    // The msg() method outputs a debug message at the appropriate level.
    // The first argument is the level, the second is the object being
    // debugged. Subsequent arguments are turned into strings and are output
    // as the debug message. Here are two examples.

    Debug.msg(Debug.INFO, this, "init(): plugin_manager: ", pluginManager().toString());
    Debug.msg(Debug.INFO, this, "Adding ServiceManager.class");

    // Here's a special method to handle debugging an exception.

    try
    {
        // Some code
    }
    catch (Exception e)
    {
        Debug.exc(this, e, "Initialise failed");
        // Handle exception
    }

Only after first setting debugging will we get any debug output, including that within Beatrix itself. It will appear in the node running the application, and includes the internal workings of Beatrix, so can be very helpful. Without this only things explicitly printed to standard output will be seen.

Actually, the Debug.set() method can be omitted in our code, because we can set its values on the launcher command line when we run the application:

launcher> run sk skeleton-launcher.xml debug={long:-1} debug-no={long:0}

This sets the debug output mask to maximum, and the debug hide mask to zero. In other words, maximum debugging.

Therefore a good way to debug an application is to:

1. Run our own node with hosting service and SAS.
2. Launch the application into our own node with the command line debug flags set appropriately.
3. Watch the debug output in the node.

We could also use the dmesg command as described above.