c4hgol

package module
v0.14.0 Latest Latest
Warning

This package is not in the latest version of its module.

Go to latest
Published: Dec 5, 2023 License: MIT Imports: 12 Imported by: 14

README

c4hgol

Test Coverage Go Report Card GoDoc

import "git.fractalqb.de/fractalqb/c4hgol"


Configuration for Heterogeneous Go Loggers

Though Go has a logging package in its standard library this package is rather basic. IMHO this is the reason why there are several additional and different logging libraries in the Go community which lead to some irritation when one wants to write an application that ends up with having several different logging frameworks included due to package dependencies.

This package does not address the desire to have one unified logger or at least a unified logging interface. – Let the packages choose their loggers… for good or for bad. However, what I want to be able to do is configure all those loggers in my application in a unified way! At least configure some common things that one often wants to configure:

  • Switching loggers for some “topics” on and off
  • Setting the log level of loggers
  • Set a writer as the target for the logging messages
  • (to come: log format?)

Note that the first bullet in the list gives the hint that loggers shall be grouped into topics so that configuration becomes simpler.

Log Packages Architecture Proposition

Make a virtue of necessity…

Theoretical Approach

First of all one has to question why it could come to the situation that a single executable includes different logging libraries! If each component (library), an executable is made of, returns detailed information about the outcome of each of its offered services (functions/methods) the executable can decide if and how to log those outcomes.—No need for a component to do logging at all, i.e. only the executable uses logging and therefore can arrange to use one logging library.

In theory this could be done for exceptional situations, aka errors. Here one could start to collect context information at the point of failure. This information then propagates back to the executable while being enriched with relevant context information. Again, it would be up to the executable to decide what to do with this.

For “small” components and when executables have a rather shallow dependency graph this approach does not only work well, it is also a desirable approach. – It keeps things simple!

Facing the Real World…

…at least when things become more and more complex. In reality we often see requirements that break the Theoretical Approach:

  • In practice error/exception handling is rarely perfect and most often only comes with a text message. This makes reasonable decisions difficult for executables.

  • As soon as one also wants information about the happy case details from a deeply “buried” component it gets difficult, if not impossible, for top-level executable's code to get that.

For short: One has to expect that sufficiently sophisticated components come with their own logging included.

Would that be a problem? IMHO not, as long as you have some means to configure the loggers to your need. I.e. make c4hgol a concept! This would address the need of application developers and gives reasonable choices to component developers:

  1. Component developers can chose their logging API

  2. Logging calls can be static calls, i.e. no dynamic dispatching through interfaces

Used by

Documentation

Overview

Though Go has a logging package in its standard library this package is rather basic. IMHO this is the reason why there are several additional and different logging libraries in the Go community which lead to some irritation when one wants to write an application that ends up with having several different logging frameworks included due to package dependencies.

This package does not address the desire to have one unified logger or at least a unified logging interface. – Let the packages choose their loggers… for good or for bad. However, what I want to be able to do is configure all those loggers in my application in a unified way! At least configure some common things that one often wants to configure:

- Switching loggers for some “topics” on and off

- Setting the log level of loggers

- (may be other things to come in the future)

Note that the first bullet in the list gives the hint that loggers shall be hierarchically grouped so that configuration becomes simpler.

Index

Examples

Constants

This section is empty.

Variables

This section is empty.

Functions

func Configure added in v0.13.0

func Configure(cfg Config, desc string, strict bool) error

TODO enable / disable

func FeatureType added in v0.14.0

func FeatureType(feature any) string
Example
fmt.Println(FeatureType(Enable(false)))
fmt.Println(FeatureType(InfoLevel))
fmt.Println(FeatureType(Output{os.Stderr}))
fmt.Println(FeatureType(SrcFile))
Output:

git.fractalqb.de/fractalqb/c4hgol.Enable
git.fractalqb.de/fractalqb/c4hgol.Level
git.fractalqb.de/fractalqb/c4hgol.Output
git.fractalqb.de/fractalqb/c4hgol.Source

func FlagDoc added in v0.13.0

func FlagDoc() string

func Visit added in v0.13.0

func Visit(start Config, do func(c Config, path string) error) error

Types

type Config added in v0.10.1

type Config interface {
	Set(feature any) error
	Get(zero any) (value any, err error)
	Features() []any
}

type Enable added in v0.13.0

type Enable bool

type Group added in v0.10.0

type Group struct {
	Named
	// contains filtered or unexported fields
}

func MustNewGroup added in v0.14.0

func MustNewGroup(name string, members ...Config) *Group

func MustNewLogGroup added in v0.14.0

func MustNewLogGroup(cfg Config, name string, members ...Config) *Group

func NewGroup added in v0.10.0

func NewGroup(name string, members ...Config) (*Group, error)

func NewLogGroup added in v0.13.0

func NewLogGroup(cfg Config, name string, members ...Config) (*Group, error)

func (*Group) Set added in v0.14.0

func (g *Group) Set(feature any) (err error)

type Level

type Level int
const (
	TraceLevel Level = -100
	DebugLevel Level = -50
	InfoLevel  Level = 0
	WarnLevel  Level = 50
	ErrorLevel Level = 100

	DefaultLevel = InfoLevel
)

func (Level) String added in v0.14.0

func (l Level) String() string

type LevelMap

type LevelMap struct {
	// contains filtered or unexported fields
}

func MustNewLevelMap added in v0.14.0

func MustNewLevelMap(pairs ...any) LevelMap

func NewLevelMap added in v0.14.0

func NewLevelMap(pairs ...any) (LevelMap, error)

func (LevelMap) Map added in v0.14.0

func (m LevelMap) Map(a int64) int64

func (LevelMap) Revert added in v0.14.0

func (m LevelMap) Revert(b int64) int64

type Named added in v0.14.0

type Named struct {
	// contains filtered or unexported fields
}

func MustNewNamed added in v0.14.0

func MustNewNamed(cfg Config, name string) *Named

func NewNamed added in v0.14.0

func NewNamed(cfg Config, name string) (*Named, error)

func (*Named) Features added in v0.14.0

func (n *Named) Features() []any

func (*Named) Get added in v0.14.0

func (n *Named) Get(zero any) (value any, err error)

func (*Named) Name added in v0.14.0

func (n *Named) Name() string

func (*Named) Path added in v0.14.0

func (n *Named) Path() string

func (*Named) Set added in v0.14.0

func (n *Named) Set(feature any) error

type Output added in v0.13.0

type Output struct {
	io.Writer
}

func (Output) String added in v0.14.0

func (o Output) String() string

type Source added in v0.14.0

type Source int
const (
	SrcOff Source = iota
	SrcFile
	SrcPath
	SrcStack
)

func (Source) String added in v0.14.0

func (l Source) String() string

type Unsupported added in v0.14.0

type Unsupported struct {
	Feature any
}

func (Unsupported) Error added in v0.14.0

func (u Unsupported) Error() string

func (Unsupported) Is added in v0.14.0

func (u Unsupported) Is(err error) bool

Directories

Path Synopsis
Configure Go standard log with c4hgol log configuration system.
Configure Go standard log with c4hgol log configuration system.

Jump to

Keyboard shortcuts

? : This menu
/ : Search site
f or F : Jump to
y or Y : Canonical URL