 |
ALox
V. 2402 R. 0
|
Well, it seems like a miracle that C++ compilers are written in C++ and looking behind the scenes it is really fine piece of software art when you really start bootstrapping such a system from scratch!
Well, with ALox it was much more simple: We implemented ALox and when this was done, we just added ALox Log lines into ALox code. Easy!
So, this chapter explains how these internal logs are organized and how an ALox user can work with them. A first introduction to this is given in the language-specific tutorials, chapter ALox Configuration Information and Internal Log Messages (C++, C#, Java).
Log Domains are hierarchically organized in ALox. All Log Domains together constitute a tree of Log Domains. Class Lox (C++, C#, Java) maintains the tree, inserts Log Domains 'on the fly' and manages the Verbosity on a per Log Domain and Logger basis.
For internal Log Statements, ALox uses a second, separate domain tree. The separation is made to keep the main tree of Log Domains 'free' for custom domains. If this was different, then setting the root domain as in the following sample:
would affect internal log messages as well. Because of the separation, they are not. To set or modify the Verbosity of internal Log Domains, static field ALox.InternalDomains (C++, C#, Java) has to be used as follows:
When you check out the reference documentation as linked above, you will see that this field is a simple string "$/". Therefore, the code:
is equivalent to the previous line.
"$/" to be compatible with future versions of ALox (...or at least get a compiler error if this would be changed to something different than a string code.).This piece of information is all you need to control Verbosity of ALox internal messages.
Please Note that method Log.AddDebugLogger (C++, C#, Java) sets the Verbosity.Warning for the internal domain. This way, when using ALox, your debug-logger will show you errors and warnings if something goes wrong inside of ALox (e.g. when you pass wrong parameters to ALox, etc.).
For different topics, ALox uses different sub-domains for its internal logging. As usual, this allows to control the Verbosity of the internal log output more granular then by setting the internal root domain "$/". For example, if a software uses wrong Log Domains evaluated from a more complex configuration of Scope Domains, then, to investigate into the problem, sub-domain 'DMN' could be set to more verbose, while suppressing other internal messages:
The list of sub-domains used by ALox is given in the following table:
| Sub-Domain | Description |
|---|---|
| LGR | Used when Loggers are registered, retrieved or removed from a Lox and when the Verbosity of a Log Domain for a Logger is changed. In addition used with method Lox.SetStartTime. |
| DMN | Used when Log Domains are registered (on first use), when Scope Domains are set or removed and when Domain Substitution Rules are set. |
| PFX | Used when Prefix Logables are set or removed. |
| THR | Used with method Lox.MapThreadName. |
| LGD | Used with storing and retrieving Log Data objects. |
| VAR | Used when parsing and processing external variables. |
It is not 'forbidden' to have custom Log Statements using the internal domain tree:
Of-course it is advisable to do so only if there are good reasons for that. There is one occasion where this is already, by default done. ALox builds on underlying utility library ALib (C++, C#, Java). ALib does not 'know' ALox (it is just too low level to 'know') and hence uses an own way to have at least a minimum, fundamental way to communicate problems to the outer world. This communication is implemented using ALib classes Report (C#, Java) and ReportWriter (C#, Java). These classes together implement a pattern of having a 'pluggable' object that handles report messages. The whole concept is mainly used in debug versions of ALib to report assertions caused by wrong parameters or other faulty use of ALib classes.
Now, method Log.AddDebugLogger (C++, C#, Java) not only creates a (or more) Logger and attaches it to the Lox singleton used for debug-logging, it also creates a custom ReportWriter and plugs it to ALib! The type of this ReportWriter is ALoxReportWriter (C#, Java). This class is forwarding ALib reports to the debug Lox singleton using internal domain '$/REPORT'.
This all makes a lot of sense, because this way, internal ALib reports are directed to the same domain tree as internal ALox logging! When enabling internal log messages of ALox for a Logger, then also reports are received.
It is absolutely OK, to register a Logger exclusively for internal domains. Methods Lox.RemoveLogger (C++, C#, Java) always removes the logger from both, internal and standard Log Domains.
As an alternative to internal logging, method Lox.State (C++, C#, Java) provides an actual snapshot of all (or selected) settings made for a Lox and its Loggers attached. Depending on the situation, each way to disclose what is going on inside ALox might help when something is irritating. As an alternative to (temporarily) adding an invocation of Lox.State to your code, ALox provides configuration variable ALOX_LOXNAME_DUMP_STATE_ON_EXIT. This allows to enable an automatic dump of the state using a command line parameter or other external configuration variable sources.
1.8.16