Logging in Weave is done using a third party library. Prior to Weave 2.6.7 Log4j 1.2 was used. From 2.6.7 onwards Logback is used. It is beyond the scope of this document to explain how the logging infrastructure works with Log4j and Logback so the reader is encouraged to visit the Log4j or Logback websites to find out more information about the inner workings of these libraries.
...
Level: The Level object defines the granularity and priority of any logging information. Each piece of logging information is accompanied by its appropriate Level object, which tells the Logger object about the priority of the information. There are seven The levels of logging defined within the API are: TRACE, DEBUG, INFO, WARN and ERROR. The Level values can be arranged in an ascending manner as:
TRACE < DEBUG < INFO < WARN < ERROR
During normal operation of Weave you’re likely to only require log messages with a level of INFO or higher (WARN and ERROR) which will tell you what Weave is doing and if there are any problems. But when you’re trying to figure out a problem, or are actively configuring the system, then seeing the log level of DEBUG can also be useful. It’s unlikely that a Weave instance would require a log level of TRACE which will produce . This log level produces a large amount of low level detail and is mainly intended to help developers to troubleshoot issues with the Weave code.
Additionally, when filtering log output, you can specify OFF as a log level to disable all log output from a specific logger, for . For example a number of third party libraries used by Weave also produce log output but they produce this can be unnecessary noise when trying to view the Weave log output, so the default Weave log configuration disables the log output from a number of these libraries by setting their specific log level to OFF (or in some cases ERROR or WARN).
...
The configuration below defines the level of the root logger as DEBUG and specifies the appender to use as testAppender. Next, the appender testAppender is defined as referencing the ch.qos.logback.core.ConsoleAppender object and the layout of the appender as the pattern is specified. A pattern requires that a conversion pattern or a format be supplied. In this case the conversion pattern of %m%n is supplied, which means the logging message will be printed followed by a newline character, more . More information about these patterns are available at https://logback.qos.ch/manual/layouts.html#conversionWord
...
The default logging.xml file included with Weave is similar to the above example but has some additional configuration that enables the different types of log output depending upon how Weave was started. For example, for example if you use startup.cmd to start Weave you only get the console output, but if you started Weave as a service then you only get the weave.log file output. This is done by including conditions around the appender-ref tags in the root section of the file, but if you want to explicitly determine which log output is generated you can remove those additional condition tags and have the same output regardless of how Weave was started.
Note that the default log level set in logging.xml this does not effect the log information recorded in a support dump, a support dump Support Dump. A Support Dump generated from Weave will now always include all log messages generated during startup of Weave and all log messages generated (up to a certain number) before the dump was produced , regardless of the log level set in logging.xml.
...
| Code Block |
|---|
00:06:45,405 DEBUG [OSGi Console] com.cohga.search.indexer.internal.Activator "Stopping Weave Index ..." |
Item | Value | Description |
|---|---|---|
TIME | 00:06:45,405 | States the time the message was logged to the file. Format is HOURS:MINUTES:SECONDS,MILLISECONDS |
LOGGING_LEVEL | DEBUG | The Level of the message logged. Possible values are DEBUG, WARN, INFO or ERROR |
THREAD | [OSGi Console] | The thread that the message was logged in (See below for more information about reading logs). |
MESSAGE_ORIGIN | com.cohga.search.indexer.internal.Activator | The class that the message was logged against. e.g. The class Activator in the package com.cohga.search.indexer.internal |
MESSAGE | "Stopping Weave Index ..." | The message that is being set to the log. Typically this is in human readable form, however sometimes the messages may not be that intuitive to the user. |
The main items that change, and that should be noted are the Thread, Message Origin and the Message. These three items define when and where the message was logged from. The Thread component can cause some confusion to many first time readers if they have not familiar with multithreaded applications. A key example is that the same message may be logged three times in succession. This happens due the the WebService, that Weave runs under, which is handling requests from multiple different locations at the same time. Each thread is being executed concurrently and working in isolation within the Weave application. An example of what you would see in the log file for this is:
...