Liking cljdoc? Tell your friends :D
All platforms.
automaton-core.log.strategy.static-ns-level
Base strategy to statically define which logger to use
This strategy is a static one, it means it is applied at the compile time, so:
- Any evolution of that strategy requires a new deployment.
- All drop logs are not time consuming (except if the caller line makes some computation - which is the responsability of the caller)
- All selected lines could then decide on runtime if there are needed or not. For instance log4j2 logger could use its own parameters to update dynamically which one is used or not
See automaton-core.log.strategy.static-ns-level/ns-rules for rule definition details
Base strategy to statically define which logger to use This strategy is a static one, it means it is applied at the compile time, so: * Any evolution of that strategy requires a new deployment. * All drop logs are not time consuming (except if the caller line makes some computation - which is the responsability of the caller) * All selected lines could then decide on runtime if there are needed or not. For instance log4j2 logger could use its own parameters to update dynamically which one is used or not See `automaton-core.log.strategy.static-ns-level/ns-rules` for rule definition details
apply-ns-ruleclj/s
(apply-ns-rule ns {:keys [re] :as rule})If ns match the regular expression re then return a vector with:
- the minimum level required to display that message
- a description of the rule as a second parameter (useful for tracing the decision if log are needed)
If `ns` match the regular expression `re` then return a vector with: * the minimum level required to display that message * a description of the rule as a second parameter (useful for tracing the decision if log are needed)
filter-rules-by-envclj/s
(filter-rules-by-env rules env)filter-rules-by-levelclj/s
(filter-rules-by-level rules level)make-static-ns-level-strategyclj/s
(make-static-ns-level-strategy config)(make-static-ns-level-strategy config ns-rules*)Build the log-strategy/Strategy instance applying the static ns level rule
Params:
configconfig data that is used with ns-rules for helping to choose the right rules (e.g. currently we pass there config with enviroment data)ns-rulesset of rules to feed the chooser
Build the `log-strategy/Strategy` instance applying the static ns level rule Params: * `config` config data that is used with ns-rules for helping to choose the right rules (e.g. currently we pass there config with enviroment data) * `ns-rules` set of rules to feed the chooser
ns-rulesclj/s
Decides the level of log depending on namespace The order is important, the rules at the beginning of the sequence are superseeding the last ones So the first matching rule is applying This order (a little bit counter intuitive) has been chosen for performance/simplicity reasons.
rule-id- id of the rule, if set to :default is going to be treated as default logger, when multiple with same logger defined, the first one will be chosen, default logger is ignored when the same logger is defined in ns specific rule.re- is the regular expression to apply on the namespace to decide if the rule apply or notenv- is the environment in which the log should be printed, if not specified it will be considered in all envs.min-level- is the minimum expected log level to be printed (so all greater or equal log levels are printed). The levels below the min-level are silenced. Not providing that value means only max-level is accepted or if it's not set all levels.max-level- is the maximum expected log level to be printed (so all below or equal log levels are printed). The levels above the max-level are silenced. Not providing that value means only min-level is accepted or if it's also not set all levels.:logger- seq of loggers ids to apply, loggers themselves are defined later on, in clj and cljs sides as their implementation depends on the technology most of the time.
Decides the level of log depending on namespace The order is important, the rules at the beginning of the sequence are superseeding the last ones So the first matching rule is applying This order (a little bit counter intuitive) has been chosen for performance/simplicity reasons. * `rule-id` - id of the rule, if set to :default is going to be treated as default logger, when multiple with same logger defined, the first one will be chosen, default logger is ignored when the same logger is defined in ns specific rule. * `re` - is the regular expression to apply on the namespace to decide if the rule apply or not * `env` - is the environment in which the log should be printed, if not specified it will be considered in all envs. * `min-level` - is the minimum expected log level to be printed (so all greater or equal log levels are printed). The levels below the min-level are silenced. Not providing that value means only max-level is accepted or if it's not set all levels. * `max-level` - is the maximum expected log level to be printed (so all below or equal log levels are printed). The levels above the max-level are silenced. Not providing that value means only min-level is accepted or if it's also not set all levels. * `:logger` - seq of loggers ids to apply, loggers themselves are defined later on, in clj and cljs sides as their implementation depends on the technology most of the time.
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close