[
https://issues.apache.org/jira/browse/LOG4J2-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14972440#comment-14972440
]
Remko Popma commented on LOG4J2-1162:
-------------------------------------
Now that the ContextSelector idea has proven itself, would it not be fair to
ask applications that want a single LoggerContext to use the
BasicContextSelector?
Is there a use case where an application wants to use two LoggerContexts? Like,
it mostly uses the LoggerContext from the default ClassLoaderContextSelector
but occasionally needs to *also* use a different LoggerContext stored in
ContextAnchor.THREAD_CONTEXT? I can't imagine a use case for this, but this is
possible, actually easy to do by mistake... I did it wrong quite a few times,
perhaps our users are even more prone to do it wrong.
In addition, at the moment all ContextSelectors in essence need to support
BasicContextSelector behavior in addition to their own behavior, which seems
unnecessarily complex.
> Memory-mapped file appender creates null-padded files.
> ------------------------------------------------------
>
> Key: LOG4J2-1162
> URL: https://issues.apache.org/jira/browse/LOG4J2-1162
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
> Affects Versions: 2.4.1
> Environment: Apache Maven 3.3.3
> (7994120775791599e205a5524ec3e0dfe41d4a06; 2015-04-22T04:57:37-07:00)
> Maven home: C:\Java\apache-maven-3.3.3\bin\..
> Java version: 1.7.0_79, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_79\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
> Reporter: Gary Gregory
> Fix For: 2.5
>
>
> Memory-mapped file appender creates null-padded files.
> If configured my app like this:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <!-- Copyright 2014-2015 Rocket Software, Inc. All rights reserved. -->
> <Configuration status="WARN" monitorInterval="5">
> <Appenders>
> <Console name="Console" target="SYSTEM_OUT">
> <PatternLayout noConsoleNoAnsi="true"
> pattern="%style{%d}{white} %highlight{%-5level}{TRACE=white}
> %style{[%t][%logger]}{white} %highlight{%msg%n%throwable}{TRACE=white}" />
> </Console>
> <RollingRandomAccessFile name="RollingFile" append="false"
> fileName="/test/dv/logs/dv.log-OFF"
>
> filePattern="/test/dv/logs/$${date:yyyy-MM}/dv-%d{yyyy-MM-dd}-%i.log.gz">
> <PatternLayout>
> <Pattern>%d %-5level [%t][%logger] %msg%n%throwable</Pattern>
> </PatternLayout>
> <Policies>
> <SizeBasedTriggeringPolicy size="100 MB" />
> </Policies>
> </RollingRandomAccessFile>
> <MemoryMappedFile name="MemMapFile" append="false"
> fileName="/test/dv/logs/dv.log">
> <PatternLayout>
> <Pattern>%d %-5level [%t][%logger] %msg%n%throwable</Pattern>
> </PatternLayout>
> </MemoryMappedFile>
> </Appenders>
> <Loggers>
> <Root level="trace">
> <!-- <AppenderRef ref="Console" /> -->
> <!-- <AppenderRef ref="RollingFile" /> -->
> <AppenderRef ref="MemMapFile" />
> </Root>
> <Logger name="javax.management" level="INFO" />
> <Logger name="sun.rmi" level="INFO" />
> <Logger name="com.rs.dv.util.LoggerEnvironmentReporter" level="OFF" />
> </Loggers>
> <!-- Filters -->
> <Filters>
> <!-- SQL only -->
> <!-- <MarkerFilter marker="DV.SQL" onMatch="ACCEPT" onMismatch="DENY" />
> <MarkerFilter marker="DV.SQL.QUERY" onMatch="ACCEPT"
> onMismatch="DENY" /> <MarkerFilter marker="DV.SQL.UPDATE"
> onMatch="ACCEPT" onMismatch="DENY" /> -->
> <!-- No buffer hex dumps -->
> <!-- <MarkerFilter marker="DV.BUFFER" onMatch="DENY" onMismatch="NEUTRAL"
> /> -->
> </Filters>
> </Configuration>
> {code}
> After the app runs, I have a 32 MB log file, with the later 2/3 of the file,
> all null bytes.
> Clearly, we need to limit what we write out.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
