|
•
|
vdlog<bitmode>_<p>r_<version>.dll on Windows
|
|
•
|
libvdlog<bitmode>_r.so.<version> on Solaris and Linux
|
|
•
|
|
•
|
Here “p” is for Standard C++ libraries, bitmode is “64” for 64 bit platforms, and <version> is the version of VisiBroker. The APIs of the library are exposed in the vdlog.h header file.
|
•
|
In the code snippet below, the server application is using the default logger to log its application specific messages. It is using the source name bankagentserver to identify its log messages from server code and bankagentimpl from the implementation code. Source names can be a very helpful tool for modularization and proves its worth during the filter configuration stages.
Alternatively, the application could have chosen to use a logger specific for its logging by changing the macro MYLOG as follows:
All the log messages from the source bankagentserver and bankagentimpl will then be directed to the logger mylogger and its configured appenders. The log messages coming from the ORB will go to the appenders configured on the default logger.
The following properties enable logging and set the global verbosity level to info. Any log messages with alower level are filtered out.
The following set of properties enable logging and allow only the logs from osagent communication component whose verbosity is either greater or equal to info. All other log messages are filtered out.
If the above implementation were built into a library, say Custom.dll (or libCustom.so), then by using the following properties, the framework could be made to use this:
At runtime, when the default logger is first accessed, the framework will read the configuration information, will identify that the appenders needed for the default logger are in a shared library, will try to load the shared library (assuming that the custom objects contained within would have registered themselves with the logger manager using the register_<>_factory APIs) and will then assemble the logger.
enables or disables the logger manager. The values input may be true or false and by default the value is false.
|
•
|
debug—The lowest level. It specifies fine-grained informational events that are most useful to debug an application for the developers. It is similar to using an offline debugger, for example showing parameter or argument values, the contents of a complex data structure like the marshalling buffer, particular memory contents like the message on the connection wire, etc.
|
|
•
|
info—Specifies informational messages that highlight the progress of the application at a coarse-grained level. These are general tracing statements. This level gives a linear view of how objects are created and destroyed, the flow of various calling and called functions, how certain actions are carried out, and how different components interact together.
|
|
•
|
err—Specifies error events that might still allow the application to continue running. These are scenarios where an error condition was detected, but corrective action could be taken and progress continued. Log statements in exception handlers can have this log level.
|
|
•
|
emerg—The highest level. This designates very severe error events that will presumably lead the application to abort. These are scenarios where ORB cannot proceed with the functional requirements and no corrective actions can be taken, and which lead to undefined behavior.
|
Using the above properties, custom appender and layout type names and their implementation location in shared libraries and DLLs can be made known to the logger framework. Here, “at” and “lt” are names of appender and layout types respectively which are among the comma separated type names being introduced.
To configure appender instances on the loggers, the above set of properties can be used. “ln”, here denotes the logger name. Using the first two properties, the logger framework is instructed on all the appender instance names associated with the logger and their types. If an appender type is not inbuilt, then the shared libraries as explained in the previous set of properties are loaded and appenders obtained. Please note that the logger framework assumes that the shared library on being loaded will automatically register all the appender and layout factories implemented within with the logger manager.
Apart from providing a means to use custom appenders and layouts, the framework also comes inbuilt with some appender and layout types. “stdout” outputs all its messages to console, while “rolling” performs the log append operation on a rolling file based data store. Both these appenders use layouts and can be set with “simple”, “full” or “xml” layouts or any custom layouts. “xml” formats the messages in Log4J xml format.
Each log message being output records the source from where it is emanating. This source name is actually a part of the log record itself. A fine-grained filtering mechanism is provided which allows filtering based on the source names in addition to the global switch provided in the log manager. Using properties, the filter in a logger can be configured to allow log messages based on particular source names and verbosity in context of the source name to be forwarded to the appenders. To configure these attributes of the filter, the above properties can be used. “ln”, here denotes the logger name. First all the source names that we want to control are registered with the filter using the first property. Then setting for each source name is fine tuned using the second and the third properties. “sn” denotes a source name that is registered in the comma separated source names in the first property. A special source name “all” denotes all the source names that have not been configured using the above properties.
The above properties can be fed into the logger framework using a properties file containing these properties, pointed to by the environment variable VDLOG_PROP_FILE.
ORB and all its services use the default logger named “default” and hence the ORB overrides the setting of the default logger again by using the VisiBroker for C++ property manager when the above properties are fed in using either “–D” command line parameters or through a properties file pointed to by the “–ORBpropStorage” command line parameter.