[
https://issues.apache.org/jira/browse/LOG4J2-1630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15549230#comment-15549230
]
Gary Gregory commented on LOG4J2-1630:
--------------------------------------
Interesting. This parallels somewhat what I am doing at work with a
CollectionAppender where I need to accumulate and "commit" log events when the
code driving decides it is time.
We might need some sub-tasks for each use case. The simplest to me seems like:
{code:java}
logger.begin();
logger.debug(...);
logger.debug(...);
if (expr) {
logger.commit();
}
else {
logger.rollback();
}
{code}
and then allowing named UOW (the above could default to a default UOW name of
{{""}} like the Root logger name is {{""}}):
{code:java}
logger.begin("UOW1");
logger.debug(...);
logger.begin("UOW2");
logger.debug(...);
if (expr1) {
logger.commit("UOW1");
}
else {
logger.rollback("UOW1");
}
if (expr2) {
logger.commit("UOW2");
}
else {
logger.rollback("UOW2");
}
{code}
Or more OO:
{code:java}
UnitOfWork uow = logger.begin("UOW1");
logger.debug(...);
logger.debug(...);
if (expr) {
logger.commit(uow);
}
else {
logger.rollback(uow);
}
{code}
Then a UOW can have a savepoint (named or not), like a RDBMS/JDBC.
I could also see managing a UOF at the logger context level.
Thoughts?
> 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 either clears the Collection or 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. Log4j can provide a
> reusable and less intrusive way to accomplish this.
> 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: [email protected]
For additional commands, e-mail: [email protected]
