The "refcodes-logger" artifact supports straight forward, composite
(clustering) or partitioning functionality as implementations of the
Logger type. The "REFCODES.ORG" runtime logger
RuntimeLogger integrates with "SLF4J" seamlessly
and also acts as an alternative to to "SLF4J".
RuntimeLogger implementations are being
configured with a
Logger implementation. In your
code, you use the
RuntimeLogger type which,
depending on you configuring it, logs to a "SimpleDB" cluster, the console
(with "ANSI" escape sequence support) or any I/O device as well as to an
Being an alternative to "SLF4J", the
RuntimeLogger's architecture settles upon the
much more generic
Logger; which actually can be
used to log high volume logs of any data type and not being restricted to
runtime logs. The
add functionality not found in other logging frameworks (logging out the
class- and method-names of the logging methods without any configuration or
additional lines of code)
Loggeris the most plain logger definition allowing you to log any kinds of data
Records; being of type
Record- and which can contain any number of
Columns, so that you are enabled to log big data of any structured information (e.g. high volume HTTP-Requests entering your RESTful microservice).
RuntimeLoggerdefines a plain simple interface for logging out runtime information generated by software systems. The
RuntimeLoggerImplimplementation takes care of logging out the class and the method generating a log line.
- ConsoleLoggerImpl (ConsoleLoggerImpl)
Loggerimplementations in the refcodes-logger-alt artifact's modules)
Use the factory (the factory is implemented as a singleton)
RuntimeLogger instances configured by a
runtimelogger.ini" file (see
"http://www.refcodes.org/refcodes/refcodes-logger"). On how to configure,
take a look at it's super-class
A SLF4J binding exists in the refcodes-logger-ext-slf4j" artifact which binds the refcodes-logger framework to SLF4J enabling to log all your SLF4J logs out by the refcodes-logger framework, e.g. to a SimpleDbLoggerImpl.
RuntimeLogger may also be configured with one
of the below mentioned loggers.
CompositeLoggerImpluses the composite patter to forward logger functionality to a number encapsulated logger instances. Depending on the performance (and availability) of an encapsulated logger, the calls to the composite's #log(Record) method are executed by the next encapsulated logger ready for execution.
An invocation of the
method is forwarded to exactly one of the encapsulated
Logger instances. The actual instance being
called depends on its availability (in case, partitioning is needed, take a
look at the
PartedLoggerImpl and its
CompositeLoggerImpl, a huge number of
Record instances can be logged in parallel by
logging them to different physical data sinks (represented by the
encapsulated logger instances), thereby avoiding a bottleneck which a single
physical data sink would cause for logging.
Internally a log line queue (holding
instances to be logged) as well a daemon thread per encapsulated logger
(taking elements from the log line queue) are used to decouple the
encapsulated logger instances from the
A given number of retries are approached in case there is an overflow of the
log line queue; this happens when the queue is full and there are none
encapsulated logger instances to take the next
To avoid a building up of the log line queue, eventually causing an out of memory, log lines not being taken into the log line queue (as it is full) within the given number of retries, them log lines are dismissed. In such a case a warning with a log-level WARN is printed out.
CompositeLoggerImplwith the query logger functionality. In contrast to the #log(Record) method, which is forwarded to exactly one of the encapsulated query logger instances, the #findLogs() method calls are forwarded to all of the encapsulated query logger instances. (in case, partitioning is needed, take a look at the
CompositeQueryLoggerImplwith the trim logger functionality. In contrast to the
AbstractCompositeLogger.log(org.refcodes.tabular.Record)method, which is forwarded to exactly one of the encapsulated trim logger instances, the
AbstractCompositeTrimLogger.clear()method calls are forwarded to all of the encapsulated
TrimLoggerinstances (in case, partitioning is needed, take a look at the
PartedLoggerImplis a partitioning logger which encapsulates
CompositeLoggerImplinstances (or sub-classes of it) representing partitions.
This means: A partition is regarded to be a dedicated physical data sink or a
Logger instances attached to physical data sinks.
A physical data sink may be a database (SQL or NoSQL), a files-system or
volatile memory (in memory). To be more concrete: A physical data sink may be
a domain when using Amazon's SimpleDB, it may be a database table when using
MySQL, it may be a HashMap or a List when using in memory storage.
Record instances as managed by the
Logger instances are mapped to the fields of the
physical data sink (e.g. table columns regarding databases).
Record instances are stored to, retrieved
from or deleted from dedicated partitions depending on partitioning
Criteria contained in the
Record instances (or the query
Criteria instances). The
Criteria (e.g. the column partition
Criteria in a
Record) as provided to the #log(Record) method
is used by the
PartedLoggerImpl to select the
partition to be addressed. In case of query operations the query
Criteria is used to determine the targeted
(in case no partition can be determined and a fallback logger has been configured, then data may get logged to the fallback logger)
In practice there can be several (composite) logger instances being the
partitions of the
individually addressed by the partitioning
This approach a) helps us scale horizontally per partition when using
CompositeLoggerImpl instances per partition and
b) helps limiting the traffic on those horizontally scaling (composite)
logger instances by partitioning the data per
Criteria using the parted logger (or its
sub-classes): Partitioning simply means switching to the partition defined by
Criteria to perform the according logger
Not having the
PartedLoggerImpl (or a sub-class
of it) would cause all the traffic for all
Criteria to hit just a single (composite)
Logger, limiting the possibility to scale
endlessly (this one logger would be the bottleneck, even when being massively
scaled horizontally): In particular this applies when looking at the extended
versions of the
PartedLoggerImpl such as the
PartedQueryLoggerImpl and the
PartedTrimLoggerImpl where query requests are
passed only to the partition which contains the required data: Increasing
query traffic is parted and does not hit increasingly a single (composite)
Record to be assigned to a partition must
provide a column, the so called partition column, whose value is used to
determine which partition is to be addressed. The partition identifying
column is passed upon construction to this
PartedLoggerImpl. Specializations may hide this
parameter from their constructors and pass their partitioning column from
inside their constructor to the super constructor.
PartedQueryLoggerImpl extends the
PartedLoggerImpl with the functionality of a
query logger. Any query operations, such as #findLogs(Criteria), are targeted
at that partition containing the queried data. For this to work, the query
must obey some rules:
The query is to contain an
addressing the partition in an unambiguous way; by being part of a root level
AndCriteria or an unambiguously nested
AndCriteria hierarchy. More than one partition
gets detected when unambiguous
applied to the partition criteria. In such cases, the query is addressed to
the potential partitions.
In case it was not possible to identify any partitions, then as a fallback, all partitions are queried.
Query results are taken from from the invoked partitions (in normal cases
this would be a single partition) round robin. the first result is taken from
the first queried partition's result set (
Record s), the next result from the next queried
partition and so on to start over again with the first queried partition.
Round robin has been used to prevent invalidation of physical data sinks's
result sets as of timeouts.
PartedTrimLoggerImpl extends the parted query
logger with the functionality of a trim logger. Delete operations with a
query such as #deleteLogs(Criteria) are applied to the partitions in the same
manner as done for #findLogs(Criteria).
Interface Summary Interface Description ColumnLayoutAccessorProvides an accessor for a column layout property. ColumnLayoutAccessor.ColumnLayoutBuilder<B extends ColumnLayoutAccessor.ColumnLayoutBuilder<B>>Provides a builder method for a column layout property returning the builder for applying multiple build operations. ColumnLayoutAccessor.ColumnLayoutMutatorProvides a mutator for a column layout property. ColumnLayoutAccessor.ColumnLayoutPropertyProvides a column layout property. LogDecoratorThe
LogDecoratorprovides means to beautify or enrich logs for example when printing user friendly logs to the console.
Loggerinterface defines those methods required for an atomic (sub-)logger to implement.
LoggerAccessor<L extends Logger<?>>Provides an accessor for a
LoggerAccessor.LoggerMutator<L extends Logger<?>>Provides a mutator for a
LoggerAccessor.LoggerProperty<L extends Logger<?>>Provides a
LoggerFactory<L extends Logger<?>> LogPriorityAccessorProvides an accessor for a
LogPriorityAccessor.LogPriorityMutatorProvides a mutator for a
MessageLogger<M>The message logger is the generic version of the
QueryLogger<T> RuntimeLoggerPlain simple interface for logging out runtime information generated by software systems. RuntimeLoggerAccessorProvides an accessor for a
RuntimeLoggerAccessor.RuntimeLoggerMutatorProvides a mutator for a
Class Summary Class Description CompositeLoggerFactoryImpl<T>Specialization and instantiateable (non abstract) implementation of the
CompositeLoggerImpl<T> CompositeQueryLoggerFactoryImpl<T>Specialization and instantiateable (non abstract) implementation of the
CompositeQueryLoggerImpl<T> CompositeTrimLoggerFactoryImpl<T>Specialization and instantiateable (non abstract) implementation of the
CompositeTrimLoggerImpl<T> LoggerUtilityThe Class LoggerUtility. LogPriorityColumnImplImplementation of a
Columninterface for working with
MethodNameColumnImplImplementation of a
Columnfor working with
Stringinstances with the semantics of a method name, being
PartedLoggerImpl<T,P extends T> PartedQueryLoggerImpl<T,P extends T> PartedTrimLoggerImpl<T,P extends T> RuntimeLoggerFactoryImplYou configure your
RuntimeLoggerFactoryImplby providing a "
runtimelogger.ini" file (see "http://www.refcodes.org/refcodes/refcodes-logger") in one of those locations relative to your main class's location: . .
RuntimeLoggerFactorySingleton RuntimeLoggerHeaderThe Class RuntimeLoggerHeader. RuntimeLoggerImpl RuntimeLoggerSingletonThis
RuntimeLoggersingleton configured by a "
runtimelogger-config.xml" file find in one of the several locations relative to your application's base directory: The applications base directory (where your JAR or your classes reside) is taken and a list of directories (as defined in the
Folders.CONFIG_DIRS) relative to this base directory is generated : The actual directories being looked at (in case them exist) are as follows, relative to your applications base directory: ..
SystemLoggerVery plain implementation of the logger interface, mainly used as fallback
Enum Summary Enum Description ColumnLayoutPredefined layouts passed to logger implementation supporting
LoggerFieldDefines default logger
LogPriorityThis enumeration defines the various log priorities to be used by the application logger.
Exception Summary Exception Description IllegalRecordRuntimeExceptionThrown in case the record cannot be logged as a specific implementation might expect some dedicated
Columninstances to be contained in the provided Record.
LoggerInstantiationRuntimeExceptionThrown in case instantiating a
RuntimeLogger) failed, e.g. the
RuntimeLoggerSingletontries to construct a
RuntimeLoggerfrom a bean configuration file (or a SpringRuntimeLoggerSingleton tries to construct a
RuntimeLoggerfrom a bean configuration context file) and fails doing so (due to missing or "wrong" configuration file).
LoggerRuntimeExceptionThe Class LoggerRuntimeException. UnexpectedLogRuntimeExceptionThrown in case some other problems regarding logging occurred, e.g. the data sink (physical system where to log to) experiences problems.