logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remko Popma (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (LOG4J2-1630) Unit of Work Logging
Date Wed, 05 Oct 2016 15:55:20 GMT

     [ https://issues.apache.org/jira/browse/LOG4J2-1630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Remko Popma updated LOG4J2-1630:
--------------------------------
    Description: 
h3. Intent
Provide a way to filter log events, where the decision on whether to discard the message or
actually log them cannot be made until after the application has already logged the message.

h3. Motivation
In many systems, particularly event processing applications, log files contain a lot of repetitive
log messages. Suppose an application needs to do some calculation to decide whether or not
to react to some event, and a lot of detail is logged during this calculation. Imagine that
99% of the time, the application decides to take no action. Once the application arrived at
that conclusion it would be nice if we could go back and undo all the detailed logging and
print a summary instead. When the application _does_ decide to take some action, however,
we _do_ want the detailed log messages. 

A Unit of Work for logging would allow us to group a set of log messages and either discard
them or log them together. (Inspired by Martin Fowler's [Unit of Work|http://martinfowler.com/eaaCatalog/unitOfWork.html]
pattern.)

This should result in log files where a lot of the "uninteresting" logging is filtered out,
significantly reducing the amount of data logged.

Some applications do this in an ad hoc manner, for example by passing a Collection to its
components, where these components can add log message strings to this Collection. When the
discard/retain decision is made, the application then logs the contents of the Collection.
This works, but having to pass the Collection down the component tree is clunky and the result
often omits details like logger name, timestamp and other details that come for free with
normal logging.

h3. How it works
There would need to be some API for the application to mark the _start_ of the unit of work,
and some API to signal whether the log messages that are part of that unit of work need to
be _discarded_ or _logged_ (retained).

Not all logging that occurs after a unit of work was started is part of that unit of work.
The application may want some messages to be logged regardless of whether the unit of work
was discarded or not. There needs to be a flexible way (or multiple ways) to include or exclude
logging statements from the unit of work. 

The application may also designate multiple units of work, which may be sequential, nested
or partially overlapping. Each unit of work may define its own rules for which log messages
are considered included in or excluded from the unit of work.

  was:
h3. Intent
Provide a way to filter log events, where the decision on whether to discard the message or
actually log them cannot be made until after the application has already logged the message.

h3. Motivation
In many systems, particularly event processing applications, log files contain a lot of repetitive
log messages. Suppose an application needs to do some calculation to decide whether or not
to react to some event, and a lot of detail is logged during this calculation. Imagine that
99% of the time, the application decides to take no action. Once the application arrived at
that conclusion it would be nice if we could go back and undo all the detailed logging and
print a summary instead. When the application _does_ decide to take some action, however,
we _do_ want the detailed log messages. 

A Unit of Work for logging would allow us to group a set of log messages and either discard
them or log them together. (Inspired by Martin Fowler's [Unit of Work|http://martinfowler.com/eaaCatalog/unitOfWork.html]
pattern.)

This should result in log files where a lot of the "uninteresting" logging is filtered out,
significantly reducing the amount of data logged.

h3. How it works
There needs to be some API for the application to mark the _start_ of the unit of work, and
some API to signal whether the log messages that are part of that unit of work need to be
_discarded_ or _logged_ (retained).

Not all logging that occurs after a unit of work was started is part of that unit of work.
The application may want some messages to be logged regardless of whether the unit of work
was discarded or not. There needs to be a flexible way (or multiple ways) to include or exclude
logging statements from the unit of work. 

The application may also designate multiple units of work, which may be sequential, nested
or partially overlapping. Each unit of work may define its own rules for which log messages
are considered included in or excluded from the unit of work.


> Unit of Work Logging
> --------------------
>
>                 Key: LOG4J2-1630
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-1630
>             Project: Log4j 2
>          Issue Type: Story
>          Components: API, Core, Filters
>    Affects Versions: 2.7
>            Reporter: Remko Popma
>             Fix For: 2.8
>
>
> h3. Intent
> Provide a way to filter log events, where the decision on whether to discard the message
or actually log them cannot be made until after the application has already logged the message.
> h3. Motivation
> In many systems, particularly event processing applications, log files contain a lot
of repetitive log messages. Suppose an application needs to do some calculation to decide
whether or not to react to some event, and a lot of detail is logged during this calculation.
Imagine that 99% of the time, the application decides to take no action. Once the application
arrived at that conclusion it would be nice if we could go back and undo all the detailed
logging and print a summary instead. When the application _does_ decide to take some action,
however, we _do_ want the detailed log messages. 
> A Unit of Work for logging would allow us to group a set of log messages and either discard
them or log them together. (Inspired by Martin Fowler's [Unit of Work|http://martinfowler.com/eaaCatalog/unitOfWork.html]
pattern.)
> This should result in log files where a lot of the "uninteresting" logging is filtered
out, significantly reducing the amount of data logged.
> Some applications do this in an ad hoc manner, for example by passing a Collection to
its components, where these components can add log message strings to this Collection. When
the discard/retain decision is made, the application then logs the contents of the Collection.
This works, but having to pass the Collection down the component tree is clunky and the result
often omits details like logger name, timestamp and other details that come for free with
normal logging.
> h3. How it works
> There would need to be some API for the application to mark the _start_ of the unit of
work, and some API to signal whether the log messages that are part of that unit of work need
to be _discarded_ or _logged_ (retained).
> Not all logging that occurs after a unit of work was started is part of that unit of
work. The application may want some messages to be logged regardless of whether the unit of
work was discarded or not. There needs to be a flexible way (or multiple ways) to include
or exclude logging statements from the unit of work. 
> The application may also designate multiple units of work, which may be sequential, nested
or partially overlapping. Each unit of work may define its own rules for which log messages
are considered included in or excluded from the unit of work.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message