[
https://issues.apache.org/jira/browse/LOG4J2-476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13860056#comment-13860056
]
Tal Liron commented on LOG4J2-476:
----------------------------------
I understand some of your reasoning but I have to disagree: this should be a
matter of configuration-mode, not runtime-mode. Your solution forces existing
libraries to be refactored in order to support this feature.
I agree that it's expensive, but so is using the includeLocation, which is why
it is explicitly enabled as a toggle in the appender configurations and in
LogEvent.setIncludeLocation. I urge you to reconsider: log4j is used
extensively in distributed applications, and has even gone so for as to include
distributed appenders in 2.0. But without this feature, these distributed
appenders are limited in use.
> Add source host to log event for distributed logging
> ----------------------------------------------------
>
> Key: LOG4J2-476
> URL: https://issues.apache.org/jira/browse/LOG4J2-476
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.0-beta9
> Reporter: Tal Liron
> Priority: Critical
>
> It's absolutely necessary to support this: when logging centrally, you *need*
> to know from where the log message arrived. I've marked the issue as
> critical, because log4j is not very useful without it in distributed
> environments. If you don't know where the log message came from, it's close
> to worthless.
> This applies at least to all classes that inherit from
> AbstractDatabaseAppender, but I think the solution should be more generic:
> developers might create their own appenders that would require this
> information. It can be handled, I think, in the same way as
> LogEvent.setIncludeLocation: allow all loggers to include this information if
> configured to do so.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
