[
https://issues.apache.org/jira/browse/LOG4J2-2665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16894939#comment-16894939
]
Ralph Goers commented on LOG4J2-2665:
-------------------------------------
I should add that log4j-audit does something sort of like what you are looking
for. With it you create a catalog of events you want audited. They are stored
in git in JSON format. When the build runs a Maven plugin generates the audit
events as interfaces and then the application coder uses those interfaces in
their application when logging. The event catalog is meant to be queried and
provides a service that can retrieve the event definitions. But this only works
with the events defined in the catalog, not arbitrary log messages.
You could do something similar by requiring the engineers to add an annotation
to the class with the descriptions in them, but unfortunately referencing them
from the logging calls would be difficult unless the id is included in the
annotation and used in the logging call or the text is copied to both places -
which is very error prone.
> Incident Response Improvement for Log4J
> ---------------------------------------
>
> Key: LOG4J2-2665
> URL: https://issues.apache.org/jira/browse/LOG4J2-2665
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
> Affects Versions: 2.12.0
> Reporter: Joubin Jabbari
> Priority: Major
>
> Issue:
> Logging something to a file only solves half of the problem. The log needs to
> readable and distinguishable by auditors and responders.
> This is a proposal to add a optional feature for the instantiation and
> compile process of the logger.
>
> # Allow for a description parameter for each log statement.
> # When the description is filled out, log events that correspond to that
> description are given a hash number that match the hash of the description
> # The descriptions of said log are extracted and paired with their hash into
> a "log description file" during the compile process
> Example:
> Previous Logging Method
> {code:java}
> logger.info(user.id + " was able to login")
> {code}
> Proposed change
> {code:java}
> logger.info(user.id + " was able to login", description="This log event
> appears right after every user logs in"){code}
> Log File example
> Previous:
> {code:java}
> user132 was able to login
> {code}
> Proposed:
> {code:java}
> c58868be25f925102364ba7cf15b4fbcca5d3f11: user132 was able to login
> {code}
> Proposed log file description file generated during compile time:
> {code:java}
> c58868be25f925102364ba7cf15b4fbcca5d3f11: This log event appears right after
> every user logs in{code}
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
