[jira] [Commented] (LOG4J2-3371) Log Injection Vulnerability exists in Log4j2 default configuration
[
https://issues.apache.org/jira/browse/LOG4J2-3371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489986#comment-17489986
]
4ra1n commented on LOG4J2-3371:
---
At your convenience, would you please let me know what you think of this?
Recently, I found some similar problems in auditing other projects which using
log4j.
For example, in Apache Shiro, Shiro PMC suggested that I report the problem to
log4j.
As a well-known java project at the same level as the spring framework, it may
be a good way to refer to the solution of the spring framework.
I haven't received a reply for many days.
Do you think this is a low-risk security vulnerability? Or do you think it's
not a security issue?
Will further actions be taken, such as patch release and CVE?
> Log Injection Vulnerability exists in Log4j2 default configuration
> --
>
> Key: LOG4J2-3371
> URL: https://issues.apache.org/jira/browse/LOG4J2-3371
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.17.1
>Reporter: 4ra1n
>Assignee: Ralph Goers
>Priority: Major
>
> For information about log injection, refer to OWASP:
> [https://owasp.org/www-community/attacks/Log_Injection]
>
> Some time ago, the spring framework revealed two CVE vulnerabilities related
> to log injection: CVE-2021-22096 and CVE-2021-22060:
> [https://tanzu.vmware.com/security/cve-2021-22096]
> [https://tanzu.vmware.com/security/cve-2021-22060]
> Their fix is to filter the log content, such as not allowing line seprators
>
> Some time ago, I found a log injection vulnerability in other Apache project,
> which use log4j2. Although the vulnerability is effective and can be
> triggered, they think I should report the problem to Apahce Log4j and prevent
> such log injection vulnerability under the default configuration
>
> code(under the default configuration)
> {code:java}
> public static void main(String[] args) {
>Logger logger = LogManager.getLogger(Main.class);
>logger.info("test\n00:00:00.000 [main] ERROR com.text.Class -
> xxx\nxxx");
> } {code}
>
> output(under the default configuration)
> {code:java}
> 09:47:34.190 [main] INFO com.example.Main - test
> 00:00:00.000 [main] ERROR com.text.Class - xxx
> xxx {code}
> On the exploitation of vulnerabilities: for example, add some confused logs,
> such as forged IP, forged classes, forged error reports and exceptions, which
> brings trouble to the operation and maintenance personnel and auditors.
> Further, if there is an internal log analysis platform, and the xxx is
> wrapped by the script tag, that is, JavaScript code, the platform reading the
> log may have XSS vulnerabilities.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3394) The 'rootLogger=${sys:root.logger:-INFO,console}' does not work
[
https://issues.apache.org/jira/browse/LOG4J2-3394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489967#comment-17489967
]
Duo Zhang commented on LOG4J2-3394:
---
So waht is the current prefered approach?
For me, I'm OK with [~rgoers]'s approach to modify PropertiesConfiguration and
only support the feature for properties file, as it is enough for hadoop and
hbase.
Thanks.
> The 'rootLogger=${sys:root.logger:-INFO,console}' does not work
> ---
>
> Key: LOG4J2-3394
> URL: https://issues.apache.org/jira/browse/LOG4J2-3394
> Project: Log4j 2
> Issue Type: Bug
> Components: Configuration
>Reporter: Duo Zhang
>Priority: Major
> Attachments: log4j2.err, log4j2.properties
>
>
> Tried the new feature introduced in LOG4J2-3341 in hbase.
> https://github.com/apache/hbase/pull/4096
> I built a tarball and try to start a standalone hbase instance locally, but
> log4j2 failed to load the system properties of rootLogger.
> Will upload the config and error output.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j2] dependabot[bot] opened a new pull request #748: Bump docker-maven-plugin from 0.33.0 to 0.39.0
dependabot[bot] opened a new pull request #748: URL: https://github.com/apache/logging-log4j2/pull/748 Bumps [docker-maven-plugin](https://github.com/fabric8io/docker-maven-plugin) from 0.33.0 to 0.39.0. Release notes Sourced from https://github.com/fabric8io/docker-maven-plugin/releases";>docker-maven-plugin's releases. 0.39.0 (2022-02-06) Cleanup dangling images as a result of image tagging, auto-pulling a base image, or auto-pulling a cacheFrom image (https://github-redirect.dependabot.com/fabric8io/docker-maven-plugin/pull/1513";>#1513) https://github.com/rkhmelichek";>@rkhmelichek Fix logic bug to remove dangling images in BuildService (https://github-redirect.dependabot.com/fabric8io/docker-maven-plugin/pull/1522";>1522) https://github.com/rkhmelichek";>@rkhmelichek skipPom is ignored by "push" goal (https://github-redirect.dependabot.com/fabric8io/docker-maven-plugin/issues/1482";>1482) https://github.com/rohanKanojia";>@rohanKanojia Enable Create Image (pull) HTTP API option (https://github-redirect.dependabot.com/fabric8io/docker-maven-plugin/issues/1516";>#1516) https://github.com/rohanKanojia";>@rohanKanojia Add docs about docker:build network config (https://github-redirect.dependabot.com/fabric8io/docker-maven-plugin/pull/1523";>1523) https://github.com/bellackn";>@bellackn Update to jnr-unixsocket 0.38.17 (Fixes for Apple M1) (https://github-redirect.dependabot.com/fabric8io/docker-maven-plugin/pull/1521";>1521) https://github.com/bkrenger";>@bkrenger v0.38.1 (2021-12-18) Update to jnr-unixsocket 0.38.14 to solve UnsatisfiedLinkError on Apple M1 (https://github-redirect.dependabot.com/fabric8io/docker-maven-plugin/pull/1507";>#1257) https://github.com/henningn";>@henningn Revert "Only push the latest tag if no other tags where specified in jib mode. This can break your build, if you rely on the automatic latest tag." (https://github-redirect.dependabot.com/fabric8io/docker-maven-plugin/pull/1510";>#1510) https://github.com/Postremus";>@Postremus Revert "Only push the latest tag if no other tags where specified in docker mode. This can break your build, if you rely on the automatic latest tag." (https://github-redirect.dependabot.com/fabric8io/docker-maven-plugin/pull/1509";>#1509) https://github.com/Postremus";>@Postremus 0.38.0 (2021-11-09) Allow replacement in tags. Added a new replacement %T which always adds a timestamp. (https://github-redirect.dependabot.com/fabric8io/docker-maven-plugin/pull/1491";>#1491) Only push the latest tag if no other tags where specified in docker mode. This can break your build, if you rely on the automatic latest tag. (https://github-redirect.dependabot.com/fabric8io/docker-maven-plugin/pull/1496";>#1496) Only push the latest tag if no other tags where specified in jib mode. This can break your build, if you rely on the automatic latest tag. (https://github-redirect.dependabot.com/fabric8io/docker-maven-plugin/pull/1498";>#1498) Deprecate entrypoint parameter inconfiguration (https://github-redirect.dependabot.com/fabric8io/docker-maven-plugin/pull/1488";>1488) Add support for executeStopOnVMShutdown flag in docker:stop goal to stop containers after build completion (https://github-redirect.dependabot.com/fabric8io/docker-maven-plugin/pull/1492";>1492) Add support for multiple ARGS defined as a part of docker imageTag string (https://github-redirect.dependabot.com/fabric8io/docker-maven-plugin/issues/1430";>1430) Thanks a lot to our contributors :heart: : https://github.com/Xyaren";>@Xyaren https://github.com/Postremus";>@Postremus https://github.com/energister";>@energister https://github.com/balazs-zsoldos";>@balazs-zsoldos https://github.com/gauee";>@gauee v0.37.0 (2021-08-15) Fix stop mojo by taking container name pattern into account (https://github-redirect.dependabot.com/fabric8io/docker-maven-plugin/issues/1168";>#1168) Wait for request.abort to finish before calling is.close() (https://github-redirect.dependabot.com/fabric8io/docker-maven-plugin/issues/1103";>#1103) Thanks a lot to our contributors :heart: : https://github.com/ncelerier";>@ncelerier https://github.com/j3t";>@j3t v0.36.1 (2021-06-27) Fix multi-stage builds when an image refers to another image named/aliased up in the Dockerfile (https://github-redirect.dependabot.com/fabric8io/docker-maven-plugin/issues/1443";>1443) Revert part of https://github-redirect.dependabot.com/fabric8io/docker-maven-plugin/issues/965";>#965 in LogRequestor (https://github-redirect.dependabot.com/fabric8io/docker-maven-plugin/pull/1480";>1480) v0.36.0 CI builds with Maven Wrapper to ensure that Maven Wrapper files and configuration are correct (https://github-redirect.dependabot.com/fabric8io/docker-maven-plugin/issues/1450";>1450) Using properties in image configuration
[jira] [Commented] (LOG4J2-3399) Release date for 2.17.2
[ https://issues.apache.org/jira/browse/LOG4J2-3399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489859#comment-17489859 ] Steve Souza commented on LOG4J2-3399: - Will do... > Release date for 2.17.2 > --- > > Key: LOG4J2-3399 > URL: https://issues.apache.org/jira/browse/LOG4J2-3399 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.17.1 >Reporter: Steve Souza >Priority: Major > > We are trying to get rid of log4j 1.x usage in various products by using the > log4j2 bridge. One of the products is Pentaho spoon. The Pentaho vendor is > working on their code to get rid of log4j 1.x dependencies, but they don't > expect that to be until june. > To solve the problem more immediately we tried the log4j2 bridge version > 2.17.1. However, an exception is thrown (LogLog class not found) when > Pentaho spoon startsup. LogLog was added in the 2.17.2-SNAPSHOT release and > I was able to successfully run Pentaho spoon with it! > However, my security team will surely ask me when the full-blown log4j 2.17.2 > will be fully released before they accept this solution. Does anyone know > the date or approximate date for the release of 2.17.2? If we don't get this > patch we may have to shut Pentaho down. > Thanks! -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3399) Release date for 2.17.2
[ https://issues.apache.org/jira/browse/LOG4J2-3399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489856#comment-17489856 ] Gary D. Gregory commented on LOG4J2-3399: - A better place for this query is the user's mailing list. > Release date for 2.17.2 > --- > > Key: LOG4J2-3399 > URL: https://issues.apache.org/jira/browse/LOG4J2-3399 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.17.1 >Reporter: Steve Souza >Priority: Major > > We are trying to get rid of log4j 1.x usage in various products by using the > log4j2 bridge. One of the products is Pentaho spoon. The Pentaho vendor is > working on their code to get rid of log4j 1.x dependencies, but they don't > expect that to be until june. > To solve the problem more immediately we tried the log4j2 bridge version > 2.17.1. However, an exception is thrown (LogLog class not found) when > Pentaho spoon startsup. LogLog was added in the 2.17.2-SNAPSHOT release and > I was able to successfully run Pentaho spoon with it! > However, my security team will surely ask me when the full-blown log4j 2.17.2 > will be fully released before they accept this solution. Does anyone know > the date or approximate date for the release of 2.17.2? If we don't get this > patch we may have to shut Pentaho down. > Thanks! -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (LOG4J2-3399) Release date for 2.17.2
Steve Souza created LOG4J2-3399: --- Summary: Release date for 2.17.2 Key: LOG4J2-3399 URL: https://issues.apache.org/jira/browse/LOG4J2-3399 Project: Log4j 2 Issue Type: Bug Affects Versions: 2.17.1 Reporter: Steve Souza We are trying to get rid of log4j 1.x usage in various products by using the log4j2 bridge. One of the products is Pentaho spoon. The Pentaho vendor is working on their code to get rid of log4j 1.x dependencies, but they don't expect that to be until june. To solve the problem more immediately we tried the log4j2 bridge version 2.17.1. However, an exception is thrown (LogLog class not found) when Pentaho spoon startsup. LogLog was added in the 2.17.2-SNAPSHOT release and I was able to successfully run Pentaho spoon with it! However, my security team will surely ask me when the full-blown log4j 2.17.2 will be fully released before they accept this solution. Does anyone know the date or approximate date for the release of 2.17.2? If we don't get this patch we may have to shut Pentaho down. Thanks! -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (LOG4J2-2486) AbstractConfiguration - Allow to disable ScriptManager
[
https://issues.apache.org/jira/browse/LOG4J2-2486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers resolved LOG4J2-2486.
-
Fix Version/s: 2.17.2
Resolution: Fixed
Log4j now requires the scripting languages to be allowed to be specified as a
system property. If no languages are specified the ScriptManager is not started.
> AbstractConfiguration - Allow to disable ScriptManager
> --
>
> Key: LOG4J2-2486
> URL: https://issues.apache.org/jira/browse/LOG4J2-2486
> Project: Log4j 2
> Issue Type: Improvement
> Components: Configurators, Core
>Affects Versions: 2.11.1
>Reporter: Sebastian
>Assignee: Ralph Goers
>Priority: Minor
> Fix For: 2.17.2
>
>
> I don't use any of the scripting features. Nevertheless, these are always
> initialized when Log4j2 is initialized (see AbstractConfiguration ->
> initialize method). Although the component seems to be optional (see below).
> Therefore I'd wish there was an option to disable this feature.
> At the moment, the initialize method will always _try_ to instantiate
> ScriptManager. As the ScriptEngineManager used inside is not available on
> Android (see issue LOG4J2-1920), this initialization is fault-tolerant using
> try-catch: If it's not available, just leave the member "scriptManager" null
> and avoid to use it later in the code (null checks). So Log4j2 seems to work
> without this as well. See the relevant initialization code snippet from
> AbstractConfiguration:
> {code:java}
> @Override
> public void initialize() {
> LOGGER.debug(Version.getProductString() + " initializing
> configuration {}", this);
> subst.setConfiguration(this);
> try {
> scriptManager = new ScriptManager(this, watchManager);
> } catch (final LinkageError | Exception e) {
> // LOG4J2-1920 ScriptEngineManager is not available in Android
> LOGGER.info("Cannot initialize scripting support because this JRE
> does not support it.", e);
> }
> // ...
> {code}
> I'd like to be able to use Log4j2 without having it initialize the
> ScriptManager mandatorily.
> So it would be nice if I could enforce the scripting-less Android mode. ;)
> As I use programmatic configuration using the builder, a setter in the
> ConfigurationBuilder would be great! Example:
> {code:java}
> void setEnableScriptingManager( boolean enableScriptingManager );
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j2] jvz commented on pull request #745: [LOG4J2-3362] Adds a SmtpManager compatible with Jakarta EE 9
jvz commented on pull request #745: URL: https://github.com/apache/logging-log4j2/pull/745#issuecomment-1034062599 I think as long as the maintenance burden is low enough, we can keep support for the old APIs indefinitely. Our Java baseline there is 11, so not as aggressive as Spring's baseline. That is a good point, though. -- 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 edited a comment on pull request #745: [LOG4J2-3362] Adds a SmtpManager compatible with Jakarta EE 9
ppkarwasz edited a comment on pull request #745: URL: https://github.com/apache/logging-log4j2/pull/745#issuecomment-1034024340 @jvz: is there any sense in using `javax.*` in the 3.0 release? Spring Boot 6.0 with a baseline of Java 17 and Jakarta EE 9 is due at the end of this year. How many people are eager to upgrade to Log4j 3.x, but keep an old Spring version? -- 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 pull request #745: [LOG4J2-3362] Adds a SmtpManager compatible with Jakarta EE 9
ppkarwasz commented on pull request #745: URL: https://github.com/apache/logging-log4j2/pull/745#issuecomment-1034024340 @jvz: is there any sense in using `javax.*` in the 3.0 release? Spring Boot 6.0 with a baseline of Java 17 and Jakarta EE 9 is due at the end of this year. -- 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-3391) Add optional additional fields to NoSQLAppender
[ https://issues.apache.org/jira/browse/LOG4J2-3391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489646#comment-17489646 ] ASF subversion and git services commented on LOG4J2-3391: - Commit 9a290307c1fb136dee0cd2ab9ec90b6b5f312ebb in logging-log4j2's branch refs/heads/release-2.x from Gary Gregory [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=9a29030 ] [LOG4J2-3391] Add optional additional fields to NoSQLAppender. Use a document instead of an array. > Add optional additional fields to NoSQLAppender > --- > > Key: LOG4J2-3391 > URL: https://issues.apache.org/jira/browse/LOG4J2-3391 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Reporter: Omer U >Assignee: Gary D. Gregory >Priority: Major > Fix For: 2.17.2 > > > Additional fields cannot be added to NoSQLAppender logs. > I wasn't able to way a find of attaching fields application server hostname > or a simple tag like application server name. > Only way of adding custom information seems to be ThreadContext -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (LOG4J2-3398) Typo on homepage
Tilman Hausherr created LOG4J2-3398: --- Summary: Typo on homepage Key: LOG4J2-3398 URL: https://issues.apache.org/jira/browse/LOG4J2-3398 Project: Log4j 2 Issue Type: Documentation Components: Documentation Reporter: Tilman Hausherr h3. [https://logging.apache.org/log4j/2.x/manual/configuration.html] h3. Archhitecture (two "h") -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (LOG4J2-3398) Typo on website
[ https://issues.apache.org/jira/browse/LOG4J2-3398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tilman Hausherr updated LOG4J2-3398: Summary: Typo on website (was: Typo on homepage) > Typo on website > --- > > Key: LOG4J2-3398 > URL: https://issues.apache.org/jira/browse/LOG4J2-3398 > Project: Log4j 2 > Issue Type: Documentation > Components: Documentation >Reporter: Tilman Hausherr >Priority: Trivial > > h3. [https://logging.apache.org/log4j/2.x/manual/configuration.html] > h3. Archhitecture (two "h") -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3317) After 2.17.1 upgarde, Route appenders with dynamic file writing are not working .
[
https://issues.apache.org/jira/browse/LOG4J2-3317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489558#comment-17489558
]
Carter Kozak commented on LOG4J2-3317:
--
Test coverage is the best option.
For what it's worth, I believe we do have similar types of tests, and fully
expect that case to work – our restriction is upon the evaluation of results of
a lookup e.g. {{{}$\{spring.application.name{ returning a lookup itself,
not lookups that are written to evaluate upon the result of another as you have
described (the difference is subtle, but in your case it's obvious that
{{lower}} is expected to be evaluated upon the result of the spring lookup, so
we allow it.
> After 2.17.1 upgarde, Route appenders with dynamic file writing are not
> working .
> --
>
> Key: LOG4J2-3317
> URL: https://issues.apache.org/jira/browse/LOG4J2-3317
> Project: Log4j 2
> Issue Type: Bug
> Environment: spring boot log4j2.
> deployed on wildfly server.
>Reporter: Srinivasa Babu
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.17.2
>
>
> Hello Sir,
> With log4j2 2.13.3 , Route appenders with context pattern checks for dynamic
> file writing are working fine. After 2.17.1 the functionality is broken.
> I have upgraded to 2.17.1 and our java code, I am setting the ROUTINGKEY in
> threadcontext map. Also i set the system properties,
> log4j2.enableJndiLookup, log4j2.enableJndiJms, and
> log4j2.enableJndiContextSelector to true for all said tags after 2.17.1
> upgrade.
> When I check output file, its not writing the logs to Route File what we
> specify but general RollingFile logger appenders are working fine. Please let
> me know if you have faced this issue or any mitigation plan? Please let me
> know if you want any logs and i will share those if there is any specific
> procedure given.
>
> Calling the below Route from Async logging.
> here my example xml used the same as given in log4j2 documentaion.
>
> filePattern="./logs/${date:-MM}/default-%d\{-MM-dd}-%i.log.gz">
>
> %d\{ISO8601} [%t] %p %c\{3} - %m%n
>
>
>
>
>
>
>
>
> fileName="logs/other-${ctx:ROUTINGKEY}.log"
> filePattern="./logs/${date:-MM}/${ctx:ROUTINGKEY}{-}other{-}%d\{-MM-dd}-%i.log.gz">
>
> %d\{ISO8601} [%t] %p %c\{3} - %m%n
>
>
>
>
>
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3317) After 2.17.1 upgarde, Route appenders with dynamic file writing are not working .
[
https://issues.apache.org/jira/browse/LOG4J2-3317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489469#comment-17489469
]
Gary D. Gregory commented on LOG4J2-3317:
-
Sounds like we better have a unit test that covers that use case, then you
won't have to worry about it from commit to commit, release to release.
> After 2.17.1 upgarde, Route appenders with dynamic file writing are not
> working .
> --
>
> Key: LOG4J2-3317
> URL: https://issues.apache.org/jira/browse/LOG4J2-3317
> Project: Log4j 2
> Issue Type: Bug
> Environment: spring boot log4j2.
> deployed on wildfly server.
>Reporter: Srinivasa Babu
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.17.2
>
>
> Hello Sir,
> With log4j2 2.13.3 , Route appenders with context pattern checks for dynamic
> file writing are working fine. After 2.17.1 the functionality is broken.
> I have upgraded to 2.17.1 and our java code, I am setting the ROUTINGKEY in
> threadcontext map. Also i set the system properties,
> log4j2.enableJndiLookup, log4j2.enableJndiJms, and
> log4j2.enableJndiContextSelector to true for all said tags after 2.17.1
> upgrade.
> When I check output file, its not writing the logs to Route File what we
> specify but general RollingFile logger appenders are working fine. Please let
> me know if you have faced this issue or any mitigation plan? Please let me
> know if you want any logs and i will share those if there is any specific
> procedure given.
>
> Calling the below Route from Async logging.
> here my example xml used the same as given in log4j2 documentaion.
>
> filePattern="./logs/${date:-MM}/default-%d\{-MM-dd}-%i.log.gz">
>
> %d\{ISO8601} [%t] %p %c\{3} - %m%n
>
>
>
>
>
>
>
>
> fileName="logs/other-${ctx:ROUTINGKEY}.log"
> filePattern="./logs/${date:-MM}/${ctx:ROUTINGKEY}{-}other{-}%d\{-MM-dd}-%i.log.gz">
>
> %d\{ISO8601} [%t] %p %c\{3} - %m%n
>
>
>
>
>
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
