Viewing Logging Messages

There are two ways to view logging messages:

• View in General Interface Builder

• View at runtime

Viewing Logging Messages in General Interface Builder

To show logging messages during development, General Interface Builder defines a handler class, jsx3.ide.SystemLogHandler. This class handles logging messages by printing them in the System Log palette located in the bottom panel of the user interface. This handler class is configured in the logging system configuration file just like any other handler.

The logging system configuration file, logger.xml, is located in the GI_HOME directory. The default configuration file includes the following lines that declare the General Interface Builder ide handler:

<handler name="ide" class="jsx3.ide.SystemLogHandler"

    lazy="true">

  <property name="bufferSize" eval="true" value="0"/>

  <property name="format" value="%t %n (%l) - %M"/>

  <property name="beepLevel" eval="true"

    value="jsx3.util.Logger.ERROR"/>

</handler>

The following lines register the ide handler with the global logger:

<!-- The global logger. -->

  <logger name="global" level="INFO">

    <handler-ref name="ide"/>

  </logger>

By default, the ide handler is defined without a log level, so messages aren't filtered by level. Because the global logger is configured with level INFO, all messages of INFO and higher are forwarded to the ide handler and output to the System Log palette. TRACE and DEBUG messages aren't forwarded to the handler, regardless of the handler's level.

If you add level =" WARN" as an attribute of the handler element, the System Log palette would only display messages of severity WARN and higher, instead of INFO and higher. For example,

<handler name="ide" class="jsx3.ide.SystemLogHandler"

     lazy="true" level ="WARN">

Viewing Logging Messages at Runtime

Runtime access to the logging system is provided by the jsx3.app.Monitor handler class. This class handles logging messages by printing them in a separate browser window along side a running application.

An application monitor has three running modes that correspond to four stages of application development:

• Off The monitor isn't configured in the logging system configuration file. This is the default setting. This is appropriate at the beginning of application development when all development occurs in General Interface Builder or at the end of development when the application is stable and error-free.

• On The monitor is configured in the logging system configuration file with the activateOnHotKey property equal to false. This is appropriate when only developers are using a deployed application, because logging messages are always visible.

• Hot Key Activated The monitor is configured in the logging system configuration file with the activateOnHotKey property equal to true. This is appropriate when a mix of developers and users have access to an application or when an error needs to be diagnosed in a live, deployed application.

To enable and use the application monitor,

1. Modify the logger system configuration file:
   
   • Create a handler for each application you want to monitor. See Creating an Application Monitor Handler.
     
   • Register the handler with a logger. See Registering an Application Monitor Handler with a Logger.
2. Run the application and see the log messages in the application monitor, which opens in a new browser window. If the activateOnHotKey property is set to true, press Ctrl+Alt+m to launch the monitor.

Creating an Application Monitor Handler

A jsx3.app.Monitor handler must be configured for each monitored application. Add as many monitors as you'd like, each with a unique handler name, such as appMonitor1, appMonitor2, and so on. Monitors are matched up to applications by the serverNamespace property. The value for this property should be identical to the server namespace of the application, which is set in the deployment options (Project > Project Settings > Deployment).

Alternatively, if the serverNamespace property is omitted, the application monitor is associated with the entire General Interface runtime rather than to a particular server.

If you prefer, you can use logger.xml in the workspace/settings directory as a template and create a separate logger file for each deployment page. See Creating a Custom Logging System Configuration File.

In the following XML snippet of the logging system configuration file (logger.xml), two monitor handlers are created, one for each application.

<handler name="appMonitor1" class="jsx3.app.Monitor"

    require="true">

  <property name="serverNamespace" value="myApp"/>

  <property name="disableInIDE" eval="true" value="true"/>

  <property name="activateOnHotKey" eval="true" value="false"/>

  <property name="format" value="%t %n (%l) - %M"/>

</handler>



<handler name="appMonitor2" class="jsx3.app.Monitor"

    require="true">

  <property name="serverNamespace" value="yourApp"/>

  <property name="disableInIDE" eval="true" value="true"/>

  <property name="activateOnHotKey" eval="true" value="false"/>

  <property name="format" value="%t %n (%l) - %M"/>

</handler>

If the specified handler class is not a statically loaded class, use require="true", so the class is dynamically loaded and available when it's needed. For a list of statically loaded classes, see General Interface Framework Classes.

Registering an Application Monitor Handler with a Logger

Next, you need to register each monitor with a logger in the logging system configuration file. In the following XML snippet, two application monitor handlers are registered with the global logger.

<logger name="global" level="INFO">

  <handler-ref name="memory"/>

  <handler-ref name="ide"/>

  <handler-ref name="appMonitor1"/>

  <handler-ref name="appMonitor2"/>

</logger>

Popup blockers may interfere with application monitors, since they exist in separate browser windows. If the monitor window does not appear as expected, verify that popup windows aren't blocked.