You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Many of the log messages emitted by the SDK are emitted by a specific instance of a class. In #1659, we made sure that all such log messages include information that identifies the instance.
Often, one ("parent") object will create other ("child") objects, and these children will go on to emit log messages. Sometimes, when viewing log messages emitted by a parent, we also want to see log messages emitted by their children. For example, if we want to understand all of the events that occurred relating to a given instance of ARTRealtime, it is helpful to also be able to see all of the log messages emitted by the ARTRealtimeChannel instances created by that instance.
This means that we want log messages emitted by a child object to also include information about the ancestors of that object.
Requirements
Each message logged by a class instance should include the following information about its ancestors (i.e. its parents, their parents, and so on):
The above should be implemented in a way that is consistent throughout the codebase and which is easy to include in new log messages. This means exposing an internal logging API that helps us to emit this information.
As in #1659, I’d suggest storing this hierarchy information in the logger object.
Prior art
What I’m suggesting above is based on the way we do logging in the Asset Tracking SDK. The InternalLogHandler type is expected to store a list of subsystems, and to insert this list of subsystems into its logged messages. Upon creating a new subsystem, we create a new logger instance which appends the new subsystem to the provided logger’s list of subsystems (example).
Current state
Our existing log messages sometimes include the address of the parent of the object that created them, but it is done in an ad-hoc fashion (i.e. needing to remember to include "RS: %p C:%p" at the start of the message). For example:
Background
Many of the log messages emitted by the SDK are emitted by a specific instance of a class. In #1659, we made sure that all such log messages include information that identifies the instance.
Often, one ("parent") object will create other ("child") objects, and these children will go on to emit log messages. Sometimes, when viewing log messages emitted by a parent, we also want to see log messages emitted by their children. For example, if we want to understand all of the events that occurred relating to a given instance of
ARTRealtime
, it is helpful to also be able to see all of the log messages emitted by theARTRealtimeChannel
instances created by that instance.This means that we want log messages emitted by a child object to also include information about the ancestors of that object.
Requirements
Each message logged by a class instance should include the following information about its ancestors (i.e. its parents, their parents, and so on):
Logging API considerations (falls under #1617)
The above should be implemented in a way that is consistent throughout the codebase and which is easy to include in new log messages. This means exposing an internal logging API that helps us to emit this information.
As in #1659, I’d suggest storing this hierarchy information in the logger object.
Prior art
What I’m suggesting above is based on the way we do logging in the Asset Tracking SDK. The
InternalLogHandler
type is expected to store a list of subsystems, and to insert this list of subsystems into its logged messages. Upon creating a new subsystem, we create a new logger instance which appends the new subsystem to the provided logger’s list of subsystems (example).Current state
Our existing log messages sometimes include the address of the parent of the object that created them, but it is done in an ad-hoc fashion (i.e. needing to remember to include "RS: %p C:%p" at the start of the message). For example:
Depends on
┆Issue is synchronized with this Jira Task by Unito
The text was updated successfully, but these errors were encountered: