[jira] [Commented] (LOG4J2-3454) how to force rolling file appender to create a new log file every time when we start the application?
[ https://issues.apache.org/jira/browse/LOG4J2-3454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17532643#comment-17532643 ] Janardhan Naidu commented on LOG4J2-3454: - Hi [~rgoers] I am able to create rolling appenders with the help of configuration builder successfully. So we are good with the reported questions. But, I have a question regarding PatternParser, like in log4j1.x implementation we were extending PatternParser and overriding some of the methods in it. Can you please let me know what is the repacement for the same in log4j2? Thanks Janardhan > how to force rolling file appender to create a new log file every time when > we start the application? > - > > Key: LOG4J2-3454 > URL: https://issues.apache.org/jira/browse/LOG4J2-3454 > Project: Log4j 2 > Issue Type: Question >Affects Versions: 2.17.2 >Reporter: Janardhan Naidu >Priority: Major > > HI Team, > > I am in process of migrating the log4j1 to log4j2, where we are rewriting the > appenders with the help of AbstractAppender Plugin or using the property > file. I have multiple questions regarding this, please help me to resolve the > same. > # how to force rolling file appender to create a new log file every time > when we start the application? here, consider appenders are configured in > property file. > # We are rewriting one of the rollingfileappender using the > abstractappender/abstractfileappender plugin way, But i am unable to find a > method which will get executed before starting of the appender!. in log4j1, > we had a method called *checkEntryConditions.* So what is the equalent api in > log4j2.? FYI, we are overriding this method to set all our configurations > like backup the old logfile, createnew logger, rolling etc.., > # Also, we need to set the ConversionPattern based on the loggername, how we > can achieve this.? in log4j1, we were extending patternLayout and overriding > the format method to do the same. So how we can acheive this using log4j2? > > Thanks > Janardhan -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (LOG4J2-3499) Bridge with log4j2 and log4j configuration cannot load custom appender class due to using lower case key name
[
https://issues.apache.org/jira/browse/LOG4J2-3499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17532598#comment-17532598
]
Piotr Karwasz commented on LOG4J2-3499:
---
It's probably just a typo in your Jira ticket, not your actual configuration,
but
{noformat}
log4j.logger.AppAuditing = _AUDIT_LOG{noformat}
is not a valid logger configuration. The value of this property should start
with the name of a level, e.g. {{"INFO, _AUDIT_LOG"}}.
> Bridge with log4j2 and log4j configuration cannot load custom appender class
> due to using lower case key name
> -
>
> Key: LOG4J2-3499
> URL: https://issues.apache.org/jira/browse/LOG4J2-3499
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.17.2
>Reporter: Xitiz Bhatia
>Assignee: Piotr Karwasz
>Priority: Major
> Labels: bridge, log4j-to-log4j2-bridge, log4j2
>
> Using log4j 1.x to log4j2 bridge with log4j2 2.17.2 and log4j properties, the
> customer appender that was working in log4j stops working. Upon enabling
> log4j debug logging, the message shown when processing the appender is:
> WARN StatusLogger Unable to load plugin class name org.abc.logging.AppAuditor
> with key org.abc.logging.appauditor
>
> It is trying to load the custom appender class as a plugin using the fully
> qualified class name in lower case. It is unable to locate the class. The
> system property log4j.plugin.packages was added to specify the package name
> where the custom appender class is located.
>
> Environment information:
> The log4j.properties file from log 4j 1.x has these entries for this custome
> appender:
> log4j.logger.AppAuditing = _AUDIT_LOG
> log4j.appender._AUDIT_LOG=org.abc.logging.AppAuditor
>
> The custom appender class org.abc.logging.AppAuditor extends from
> AppenderSkeleton and implements the custom append method.
>
> The client class using the custom appender:
> Logger log = Logger.getLogger("AppAuditing");
> log.info(message);
>
> No other changes were made to log4j.properties used with log4j 1.x and all
> steps were completed for log4j 1.x to log4j2 bridge migration. All other
> logging works as expected with the bridge except the custom appender. This
> custom appender AppAuditor also works without any issues in log4j 1.x.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [logging-log4cxx] rm5248 commented on pull request #110: Fixed version number typo
rm5248 commented on PR #110: URL: https://github.com/apache/logging-log4cxx/pull/110#issuecomment-1119158388 thanks for the fix! -- 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-log4cxx] rm5248 merged pull request #110: Fixed version number typo
rm5248 merged PR #110: URL: https://github.com/apache/logging-log4cxx/pull/110 -- 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-3499) Bridge with log4j2 and log4j configuration cannot load custom appender class due to using lower case key name
[
https://issues.apache.org/jira/browse/LOG4J2-3499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17532549#comment-17532549
]
Ralph Goers commented on LOG4J2-3499:
-
If you run with -Dlog4j2.debug=true you should get a lot more information about
what is going on. After the warning about not finding the plugin you should see
a debug message
"Attaching appender named [{}] to appender named [{}]." coming from the
buildAppender method of BuilderManager.
> Bridge with log4j2 and log4j configuration cannot load custom appender class
> due to using lower case key name
> -
>
> Key: LOG4J2-3499
> URL: https://issues.apache.org/jira/browse/LOG4J2-3499
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.17.2
>Reporter: Xitiz Bhatia
>Assignee: Piotr Karwasz
>Priority: Major
> Labels: bridge, log4j-to-log4j2-bridge, log4j2
>
> Using log4j 1.x to log4j2 bridge with log4j2 2.17.2 and log4j properties, the
> customer appender that was working in log4j stops working. Upon enabling
> log4j debug logging, the message shown when processing the appender is:
> WARN StatusLogger Unable to load plugin class name org.abc.logging.AppAuditor
> with key org.abc.logging.appauditor
>
> It is trying to load the custom appender class as a plugin using the fully
> qualified class name in lower case. It is unable to locate the class. The
> system property log4j.plugin.packages was added to specify the package name
> where the custom appender class is located.
>
> Environment information:
> The log4j.properties file from log 4j 1.x has these entries for this custome
> appender:
> log4j.logger.AppAuditing = _AUDIT_LOG
> log4j.appender._AUDIT_LOG=org.abc.logging.AppAuditor
>
> The custom appender class org.abc.logging.AppAuditor extends from
> AppenderSkeleton and implements the custom append method.
>
> The client class using the custom appender:
> Logger log = Logger.getLogger("AppAuditing");
> log.info(message);
>
> No other changes were made to log4j.properties used with log4j 1.x and all
> steps were completed for log4j 1.x to log4j2 bridge migration. All other
> logging works as expected with the bridge except the custom appender. This
> custom appender AppAuditor also works without any issues in log4j 1.x.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (LOG4J2-2956) Using log4j-spring-cloud-config-client and DynamicThresholdFilter cause Could not initialize class org.apache.logging.log4j.core.impl.ContextDataFactoryException
[
https://issues.apache.org/jira/browse/LOG4J2-2956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17532505#comment-17532505
]
ASF subversion and git services commented on LOG4J2-2956:
-
Commit 3ae669455565276e962b34ce5fdf7fd3dc7da3c2 in logging-log4j2's branch
refs/heads/master from Ralph Goers
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=3ae6694555 ]
LOG4J2-2956 - Prevent ContextDataFactory error during startup
> Using log4j-spring-cloud-config-client and DynamicThresholdFilter cause Could
> not initialize class
> org.apache.logging.log4j.core.impl.ContextDataFactoryException
> -
>
> Key: LOG4J2-2956
> URL: https://issues.apache.org/jira/browse/LOG4J2-2956
> Project: Log4j 2
> Issue Type: Bug
> Components: Spring
>Affects Versions: 2.13.3
>Reporter: Rafał Figas
>Priority: Major
> Fix For: 2.18.0
>
>
> Assumptions:
> # Application is a Spring Boot app.
> # {{It is configured to use spring-boot-starter-log4j2}}
> {{There is a log4j2.cfg.xml provided through logging.config property and it
> is working fine. It contains following part:}}
>
> {noformat}
> onMismatch="NEUTRAL">
> INFO
>
>
> {noformat}
> {{However when dependency log4j-spring-cloud-config-client is added
> application does not start with following exception:}}
> {noformat}
> Exception in thread "main" java.lang.NoClassDefFoundError: Could not
> initialize class
> org.apache.logging.log4j.core.impl.ContextDataFactoryException in thread
> "main" java.lang.NoClassDefFoundError: Could not initialize class
> org.apache.logging.log4j.core.impl.ContextDataFactory
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector$ForDefaultThreadContextMap.rawContextData(ThreadContextDataInjector.java:137)
>
> at
> org.apache.logging.log4j.core.filter.DynamicThresholdFilter.currentContextData(DynamicThresholdFilter.java:162)
>
> at
> org.apache.logging.log4j.core.filter.DynamicThresholdFilter.filter(DynamicThresholdFilter.java:152)
> at
> org.apache.logging.log4j.core.Logger$PrivateConfig.filter(Logger.java:609)
> at org.apache.logging.log4j.core.Logger.isEnabled(Logger.java:258) at
> org.apache.logging.log4j.spi.AbstractLogger.isEnabled(AbstractLogger.java:1513)
>
> at
> org.apache.commons.logging.LogAdapter$Log4jLog.isErrorEnabled(LogAdapter.java:175)
> at
> org.springframework.boot.SpringApplication.reportFailure(SpringApplication.java:836)
>
> at
> org.springframework.boot.SpringApplication.handleRunFailure(SpringApplication.java:812)
> at
> org.springframework.boot.SpringApplication.run(SpringApplication.java:325)
> at
> org.springframework.boot.SpringApplication.run(SpringApplication.java:1237)
> at
> org.springframework.boot.SpringApplication.run(SpringApplication.java:1226)
> at
> pl.frati.moray.configserver.ConfigServerApplication.main(ConfigServerApplication.java:12)
> {noformat}
> First of all I have no idea what is missing. Without mentioned dependency
> application startup is correct. Also, removing DynamicThresholdFilter solves
> the problem as well.
> Second of all it seems that exception message is somewhat broken, because it
> does not say anything about what class is missing. I've tried to debug this,
> but class ContextDataFactory is pretty hard to debug. Fix in exception
> message should ease the hunt.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (LOG4J2-2956) Using log4j-spring-cloud-config-client and DynamicThresholdFilter cause Could not initialize class org.apache.logging.log4j.core.impl.ContextDataFactoryException
[
https://issues.apache.org/jira/browse/LOG4J2-2956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers resolved LOG4J2-2956.
-
Fix Version/s: 2.18.0
Resolution: Fixed
> Using log4j-spring-cloud-config-client and DynamicThresholdFilter cause Could
> not initialize class
> org.apache.logging.log4j.core.impl.ContextDataFactoryException
> -
>
> Key: LOG4J2-2956
> URL: https://issues.apache.org/jira/browse/LOG4J2-2956
> Project: Log4j 2
> Issue Type: Bug
> Components: Spring
>Affects Versions: 2.13.3
>Reporter: Rafał Figas
>Priority: Major
> Fix For: 2.18.0
>
>
> Assumptions:
> # Application is a Spring Boot app.
> # {{It is configured to use spring-boot-starter-log4j2}}
> {{There is a log4j2.cfg.xml provided through logging.config property and it
> is working fine. It contains following part:}}
>
> {noformat}
> onMismatch="NEUTRAL">
> INFO
>
>
> {noformat}
> {{However when dependency log4j-spring-cloud-config-client is added
> application does not start with following exception:}}
> {noformat}
> Exception in thread "main" java.lang.NoClassDefFoundError: Could not
> initialize class
> org.apache.logging.log4j.core.impl.ContextDataFactoryException in thread
> "main" java.lang.NoClassDefFoundError: Could not initialize class
> org.apache.logging.log4j.core.impl.ContextDataFactory
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector$ForDefaultThreadContextMap.rawContextData(ThreadContextDataInjector.java:137)
>
> at
> org.apache.logging.log4j.core.filter.DynamicThresholdFilter.currentContextData(DynamicThresholdFilter.java:162)
>
> at
> org.apache.logging.log4j.core.filter.DynamicThresholdFilter.filter(DynamicThresholdFilter.java:152)
> at
> org.apache.logging.log4j.core.Logger$PrivateConfig.filter(Logger.java:609)
> at org.apache.logging.log4j.core.Logger.isEnabled(Logger.java:258) at
> org.apache.logging.log4j.spi.AbstractLogger.isEnabled(AbstractLogger.java:1513)
>
> at
> org.apache.commons.logging.LogAdapter$Log4jLog.isErrorEnabled(LogAdapter.java:175)
> at
> org.springframework.boot.SpringApplication.reportFailure(SpringApplication.java:836)
>
> at
> org.springframework.boot.SpringApplication.handleRunFailure(SpringApplication.java:812)
> at
> org.springframework.boot.SpringApplication.run(SpringApplication.java:325)
> at
> org.springframework.boot.SpringApplication.run(SpringApplication.java:1237)
> at
> org.springframework.boot.SpringApplication.run(SpringApplication.java:1226)
> at
> pl.frati.moray.configserver.ConfigServerApplication.main(ConfigServerApplication.java:12)
> {noformat}
> First of all I have no idea what is missing. Without mentioned dependency
> application startup is correct. Also, removing DynamicThresholdFilter solves
> the problem as well.
> Second of all it seems that exception message is somewhat broken, because it
> does not say anything about what class is missing. I've tried to debug this,
> but class ContextDataFactory is pretty hard to debug. Fix in exception
> message should ease the hunt.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (LOG4J2-2956) Using log4j-spring-cloud-config-client and DynamicThresholdFilter cause Could not initialize class org.apache.logging.log4j.core.impl.ContextDataFactoryException
[
https://issues.apache.org/jira/browse/LOG4J2-2956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17532503#comment-17532503
]
Ralph Goers commented on LOG4J2-2956:
-
I've committed a fix to both branches. Could you please checkout from
release-2.x and see if it fixes the problem for you?
> Using log4j-spring-cloud-config-client and DynamicThresholdFilter cause Could
> not initialize class
> org.apache.logging.log4j.core.impl.ContextDataFactoryException
> -
>
> Key: LOG4J2-2956
> URL: https://issues.apache.org/jira/browse/LOG4J2-2956
> Project: Log4j 2
> Issue Type: Bug
> Components: Spring
>Affects Versions: 2.13.3
>Reporter: Rafał Figas
>Priority: Major
>
> Assumptions:
> # Application is a Spring Boot app.
> # {{It is configured to use spring-boot-starter-log4j2}}
> {{There is a log4j2.cfg.xml provided through logging.config property and it
> is working fine. It contains following part:}}
>
> {noformat}
> onMismatch="NEUTRAL">
> INFO
>
>
> {noformat}
> {{However when dependency log4j-spring-cloud-config-client is added
> application does not start with following exception:}}
> {noformat}
> Exception in thread "main" java.lang.NoClassDefFoundError: Could not
> initialize class
> org.apache.logging.log4j.core.impl.ContextDataFactoryException in thread
> "main" java.lang.NoClassDefFoundError: Could not initialize class
> org.apache.logging.log4j.core.impl.ContextDataFactory
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector$ForDefaultThreadContextMap.rawContextData(ThreadContextDataInjector.java:137)
>
> at
> org.apache.logging.log4j.core.filter.DynamicThresholdFilter.currentContextData(DynamicThresholdFilter.java:162)
>
> at
> org.apache.logging.log4j.core.filter.DynamicThresholdFilter.filter(DynamicThresholdFilter.java:152)
> at
> org.apache.logging.log4j.core.Logger$PrivateConfig.filter(Logger.java:609)
> at org.apache.logging.log4j.core.Logger.isEnabled(Logger.java:258) at
> org.apache.logging.log4j.spi.AbstractLogger.isEnabled(AbstractLogger.java:1513)
>
> at
> org.apache.commons.logging.LogAdapter$Log4jLog.isErrorEnabled(LogAdapter.java:175)
> at
> org.springframework.boot.SpringApplication.reportFailure(SpringApplication.java:836)
>
> at
> org.springframework.boot.SpringApplication.handleRunFailure(SpringApplication.java:812)
> at
> org.springframework.boot.SpringApplication.run(SpringApplication.java:325)
> at
> org.springframework.boot.SpringApplication.run(SpringApplication.java:1237)
> at
> org.springframework.boot.SpringApplication.run(SpringApplication.java:1226)
> at
> pl.frati.moray.configserver.ConfigServerApplication.main(ConfigServerApplication.java:12)
> {noformat}
> First of all I have no idea what is missing. Without mentioned dependency
> application startup is correct. Also, removing DynamicThresholdFilter solves
> the problem as well.
> Second of all it seems that exception message is somewhat broken, because it
> does not say anything about what class is missing. I've tried to debug this,
> but class ContextDataFactory is pretty hard to debug. Fix in exception
> message should ease the hunt.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (LOG4J2-2956) Using log4j-spring-cloud-config-client and DynamicThresholdFilter cause Could not initialize class org.apache.logging.log4j.core.impl.ContextDataFactoryException
[
https://issues.apache.org/jira/browse/LOG4J2-2956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17532405#comment-17532405
]
ASF subversion and git services commented on LOG4J2-2956:
-
Commit 6bc69ab44faf962a4df7801b802ad67fca35a635 in logging-log4j2's branch
refs/heads/release-2.x from Ralph Goers
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=6bc69ab44f ]
LOG4J2-2956 - Prevent ContextDataFactory error during startup
> Using log4j-spring-cloud-config-client and DynamicThresholdFilter cause Could
> not initialize class
> org.apache.logging.log4j.core.impl.ContextDataFactoryException
> -
>
> Key: LOG4J2-2956
> URL: https://issues.apache.org/jira/browse/LOG4J2-2956
> Project: Log4j 2
> Issue Type: Bug
> Components: Spring
>Affects Versions: 2.13.3
>Reporter: Rafał Figas
>Priority: Major
>
> Assumptions:
> # Application is a Spring Boot app.
> # {{It is configured to use spring-boot-starter-log4j2}}
> {{There is a log4j2.cfg.xml provided through logging.config property and it
> is working fine. It contains following part:}}
>
> {noformat}
> onMismatch="NEUTRAL">
> INFO
>
>
> {noformat}
> {{However when dependency log4j-spring-cloud-config-client is added
> application does not start with following exception:}}
> {noformat}
> Exception in thread "main" java.lang.NoClassDefFoundError: Could not
> initialize class
> org.apache.logging.log4j.core.impl.ContextDataFactoryException in thread
> "main" java.lang.NoClassDefFoundError: Could not initialize class
> org.apache.logging.log4j.core.impl.ContextDataFactory
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector$ForDefaultThreadContextMap.rawContextData(ThreadContextDataInjector.java:137)
>
> at
> org.apache.logging.log4j.core.filter.DynamicThresholdFilter.currentContextData(DynamicThresholdFilter.java:162)
>
> at
> org.apache.logging.log4j.core.filter.DynamicThresholdFilter.filter(DynamicThresholdFilter.java:152)
> at
> org.apache.logging.log4j.core.Logger$PrivateConfig.filter(Logger.java:609)
> at org.apache.logging.log4j.core.Logger.isEnabled(Logger.java:258) at
> org.apache.logging.log4j.spi.AbstractLogger.isEnabled(AbstractLogger.java:1513)
>
> at
> org.apache.commons.logging.LogAdapter$Log4jLog.isErrorEnabled(LogAdapter.java:175)
> at
> org.springframework.boot.SpringApplication.reportFailure(SpringApplication.java:836)
>
> at
> org.springframework.boot.SpringApplication.handleRunFailure(SpringApplication.java:812)
> at
> org.springframework.boot.SpringApplication.run(SpringApplication.java:325)
> at
> org.springframework.boot.SpringApplication.run(SpringApplication.java:1237)
> at
> org.springframework.boot.SpringApplication.run(SpringApplication.java:1226)
> at
> pl.frati.moray.configserver.ConfigServerApplication.main(ConfigServerApplication.java:12)
> {noformat}
> First of all I have no idea what is missing. Without mentioned dependency
> application startup is correct. Also, removing DynamicThresholdFilter solves
> the problem as well.
> Second of all it seems that exception message is somewhat broken, because it
> does not say anything about what class is missing. I've tried to debug this,
> but class ContextDataFactory is pretty hard to debug. Fix in exception
> message should ease the hunt.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (LOG4J2-2956) Using log4j-spring-cloud-config-client and DynamicThresholdFilter cause Could not initialize class org.apache.logging.log4j.core.impl.ContextDataFactoryException
[
https://issues.apache.org/jira/browse/LOG4J2-2956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17532404#comment-17532404
]
ASF subversion and git services commented on LOG4J2-2956:
-
Commit 7b236ceb1628dd5d6758d3f323948365d1c59abb in logging-log4j2's branch
refs/heads/master from Ralph Goers
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=7b236ceb16 ]
LOG4J2-2956 - Prevent ContextDataFactory error during startup
> Using log4j-spring-cloud-config-client and DynamicThresholdFilter cause Could
> not initialize class
> org.apache.logging.log4j.core.impl.ContextDataFactoryException
> -
>
> Key: LOG4J2-2956
> URL: https://issues.apache.org/jira/browse/LOG4J2-2956
> Project: Log4j 2
> Issue Type: Bug
> Components: Spring
>Affects Versions: 2.13.3
>Reporter: Rafał Figas
>Priority: Major
>
> Assumptions:
> # Application is a Spring Boot app.
> # {{It is configured to use spring-boot-starter-log4j2}}
> {{There is a log4j2.cfg.xml provided through logging.config property and it
> is working fine. It contains following part:}}
>
> {noformat}
> onMismatch="NEUTRAL">
> INFO
>
>
> {noformat}
> {{However when dependency log4j-spring-cloud-config-client is added
> application does not start with following exception:}}
> {noformat}
> Exception in thread "main" java.lang.NoClassDefFoundError: Could not
> initialize class
> org.apache.logging.log4j.core.impl.ContextDataFactoryException in thread
> "main" java.lang.NoClassDefFoundError: Could not initialize class
> org.apache.logging.log4j.core.impl.ContextDataFactory
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector$ForDefaultThreadContextMap.rawContextData(ThreadContextDataInjector.java:137)
>
> at
> org.apache.logging.log4j.core.filter.DynamicThresholdFilter.currentContextData(DynamicThresholdFilter.java:162)
>
> at
> org.apache.logging.log4j.core.filter.DynamicThresholdFilter.filter(DynamicThresholdFilter.java:152)
> at
> org.apache.logging.log4j.core.Logger$PrivateConfig.filter(Logger.java:609)
> at org.apache.logging.log4j.core.Logger.isEnabled(Logger.java:258) at
> org.apache.logging.log4j.spi.AbstractLogger.isEnabled(AbstractLogger.java:1513)
>
> at
> org.apache.commons.logging.LogAdapter$Log4jLog.isErrorEnabled(LogAdapter.java:175)
> at
> org.springframework.boot.SpringApplication.reportFailure(SpringApplication.java:836)
>
> at
> org.springframework.boot.SpringApplication.handleRunFailure(SpringApplication.java:812)
> at
> org.springframework.boot.SpringApplication.run(SpringApplication.java:325)
> at
> org.springframework.boot.SpringApplication.run(SpringApplication.java:1237)
> at
> org.springframework.boot.SpringApplication.run(SpringApplication.java:1226)
> at
> pl.frati.moray.configserver.ConfigServerApplication.main(ConfigServerApplication.java:12)
> {noformat}
> First of all I have no idea what is missing. Without mentioned dependency
> application startup is correct. Also, removing DynamicThresholdFilter solves
> the problem as well.
> Second of all it seems that exception message is somewhat broken, because it
> does not say anything about what class is missing. I've tried to debug this,
> but class ContextDataFactory is pretty hard to debug. Fix in exception
> message should ease the hunt.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (LOG4J2-3499) Bridge with log4j2 and log4j configuration cannot load custom appender class due to using lower case key name
[
https://issues.apache.org/jira/browse/LOG4J2-3499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17532377#comment-17532377
]
Xitiz Bhatia commented on LOG4J2-3499:
--
[~pkarwasz] Thank you for your response.
The custom appender class org.abc.logging.AppAuditor is processing the log
event message and then saving them into a database table. The appender class
extends from org.apache.log4j.AppenderSkeleton and overrides the
"append(org.apache.log4j.spi.LoggingEvent loggingEvent)" method that gets the
message using loggingEvent.getMessage() and inserts into it into database after
processing it. Unfortunately, I will not be able to share the code of the
custom appender due to licensing issues.
With log4j 1.x, the debugger stops at the debug point on append(logEvent)
however, when using the log4j bridge, the debugger doesn't come to the debug
point on append(logEvent) method in the custom appender causing me to believe
that the appender is never initialized. The only message that I found in the
server logs after adding log4j.debug system property is that it could not load
the plugin class for the key. I am not sure if it is trying to directly
initiate the appender after that.
It makes sense that the log4j bridge may not find the plugin for this custom
appender. Using your suggestions, I will try to use the native JDBC appender
for log4j2 or rewrite it as a custom log4j2 appender.
I wanted to report this in Jira in case there is a bug that someone else may
also have come across that log4j bridge may not be initializing the custom
appenders extending AppenderSkeleton when it fails to find a builder plugin for
it.
If there is any way to provide generate logging for why it is not able to
initialize the custom appender other than using the log4j.debug system
property, then please let me know.
> Bridge with log4j2 and log4j configuration cannot load custom appender class
> due to using lower case key name
> -
>
> Key: LOG4J2-3499
> URL: https://issues.apache.org/jira/browse/LOG4J2-3499
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.17.2
>Reporter: Xitiz Bhatia
>Assignee: Piotr Karwasz
>Priority: Major
> Labels: bridge, log4j-to-log4j2-bridge, log4j2
>
> Using log4j 1.x to log4j2 bridge with log4j2 2.17.2 and log4j properties, the
> customer appender that was working in log4j stops working. Upon enabling
> log4j debug logging, the message shown when processing the appender is:
> WARN StatusLogger Unable to load plugin class name org.abc.logging.AppAuditor
> with key org.abc.logging.appauditor
>
> It is trying to load the custom appender class as a plugin using the fully
> qualified class name in lower case. It is unable to locate the class. The
> system property log4j.plugin.packages was added to specify the package name
> where the custom appender class is located.
>
> Environment information:
> The log4j.properties file from log 4j 1.x has these entries for this custome
> appender:
> log4j.logger.AppAuditing = _AUDIT_LOG
> log4j.appender._AUDIT_LOG=org.abc.logging.AppAuditor
>
> The custom appender class org.abc.logging.AppAuditor extends from
> AppenderSkeleton and implements the custom append method.
>
> The client class using the custom appender:
> Logger log = Logger.getLogger("AppAuditing");
> log.info(message);
>
> No other changes were made to log4j.properties used with log4j 1.x and all
> steps were completed for log4j 1.x to log4j2 bridge migration. All other
> logging works as expected with the bridge except the custom appender. This
> custom appender AppAuditor also works without any issues in log4j 1.x.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (LOG4J2-3497) ConstraintValidator's are not employed by PluginManager
[
https://issues.apache.org/jira/browse/LOG4J2-3497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17532290#comment-17532290
]
Ralph Goers commented on LOG4J2-3497:
-
I don't understand this issue. PluginManager's sole job is to keep track of
Plugins by category. It doesn't instantiate plugin instances so it has no
knowledge of the data used in a specific plugin reference.
> ConstraintValidator's are not employed by PluginManager
> ---
>
> Key: LOG4J2-3497
> URL: https://issues.apache.org/jira/browse/LOG4J2-3497
> Project: Log4j 2
> Issue Type: Bug
> Components: Plugins
>Reporter: Volkan Yazici
>Assignee: Matt Sicker
>Priority: Major
> Fix For: 2.18.0
>
>
> {{ConstraintValidator}}'s are not taken into account when plugins are
> collected via {{PluginManager}}.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (LOG4J2-3496) Support injection via container types
[
https://issues.apache.org/jira/browse/LOG4J2-3496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17532288#comment-17532288
]
Ralph Goers commented on LOG4J2-3496:
-
To be honest I don't see how the injection system can be used with
PatternLayout. PatternParser runs through all the PatternConverter plugins and
adds them to a Map with the pattern converter symbol as the key and the
converter Class as the value. It then parses the pattern and creates a list of
PatternConverters in the order they are specified in the input. If all you are
thinking of doing is the mapping from the plugins into the Map of keys to
converters, well ok. But I don't see a huge amount of value in that.
> Support injection via container types
> -
>
> Key: LOG4J2-3496
> URL: https://issues.apache.org/jira/browse/LOG4J2-3496
> Project: Log4j 2
> Issue Type: New Feature
> Components: Plugins
>Reporter: Volkan Yazici
>Assignee: Matt Sicker
>Priority: Major
> Fix For: 3.0.0
>
>
> Plugin system should support the injection via container types. Since this is
> not currently the case, whenever a, for instance, collection of plugins need
> to be injected (e.g., Pattern and JSON Template Layouts), ad-hoc access to
> {{PluginManager}} or {{PluginUtils}} is needed. This approach has certain
> drawbacks:
> * Duplication of ad-hoc code
> * Not aligned with the way plugins are loaded, that is, via {{@Inject}}
> * Impossible to test
> h3. Container types
> Ideally, the plugin system should support injection via the following
> container types:
> * {{Optional}}
> * {{Collection}}
> * {{Iterable}}
> * {{Set}}
> * {{Stream}}
> * {{List}}
> * {{Map}}
> Above {{P}} denotes the type the plugin is assignable from and {{N}} denotes
> the plugin name.
> h3. Ordering problem
> A {{@PluginOrder}} annotation needs to be introduced to address the following
> corner cases:
> * In the case of {{Optional}}, if there are multiple matches, the first
> one needs to be picked.
> * In the case of collection and map types, elements need to be sorted.
> Sorting can be done in the following way:
> * If one or more of the matches are annotated with {{@PluginOrder}}, they
> will have the precedence and get sorted according to {{@PluginOrder}} values.
> * The rest will be sorted according to their discovery order.
> The order in collection types can be preserved using the following
> implementations:
> * {{Set}} -> {{LinkedHashSet}}
> * {{Map}} -> {{LinkedHashMap}}
> * {{Collection}}, {{Iterable}}, {{Stream}} -> {{List}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (LOG4J2-3498) Timestamp lacks micro and nano second precision on linux
[
https://issues.apache.org/jira/browse/LOG4J2-3498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Tanguay updated LOG4J2-3498:
-
Affects Version/s: 2.17.2
> Timestamp lacks micro and nano second precision on linux
>
>
> Key: LOG4J2-3498
> URL: https://issues.apache.org/jira/browse/LOG4J2-3498
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.17.2
>Reporter: Benjamin Tanguay
>Priority: Minor
>
> Generating a timestamp with micro and nano seconds defined fails when the
> operating system is linux. Instead of having the required precision, the log
> pads the micro and nano seconds with zeros. Testing it between some
> developpers, the code works properly on Windows and Mac and only fails on
> Linux machines.
> Our team has tested this internally and it seems that the problem is linked
> to a bad interaction between Linux and the library. We've tested with
> different JDK versions and vendors and the problem remained the same. The
> problem also works in the same way whether we use a JsonLayout or a
> PatternLayout to output the timestamp in the log.
>
> {*}Expected{*}:
> A timestamp with the form: "timestamp":"2022-05-04T17:53:43.914{*}123456{*}Z"
> {*}Actual{*}:
> A timestamp with the form: "timestamp":"2022-05-04T17:53:43.914{*}00{*}Z"
>
> I created a small project to reproduce the issue. Notice the script demo.sh
> that allows you to build an alpine image, execute the code in docker and
> output the log in the console.
> [https://github.com/BenjaminTanguay/log4j-low-timestamp-precision-linux-demo]
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (LOG4J2-3498) Timestamp lacks micro and nano second precision on linux
[
https://issues.apache.org/jira/browse/LOG4J2-3498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17532239#comment-17532239
]
Benjamin Tanguay commented on LOG4J2-3498:
--
I've updated the library to 2.17.2 in the test project. Results are the same.
The project uses Java 11 to compile but I've run the jar on a Java 18 runtime
and it fails in the same way.
For OS, I've tried a RHEL 8 VM and Alpine via docker. The results are the same
in both cases.
Also, I don't know how the instant is generated in log4j2 but the following
code populates the nano seconds properly on linux (and probably windows as
well):
{code:java}
import java.time.Clock;
import java.time.Duration;
import java.time.Instant;
class NanoTime {
public static void main(String[] args) {
Clock c = Clock.tick(Clock.systemUTC(), Duration.ofNanos(0L));
for (int i = 0; i < 2000; i++) {
Instant instant = c.instant();
System.out.println(instant.toString() + " " + instant.getNano());
}
}
} {code}
> Timestamp lacks micro and nano second precision on linux
>
>
> Key: LOG4J2-3498
> URL: https://issues.apache.org/jira/browse/LOG4J2-3498
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Benjamin Tanguay
>Priority: Minor
>
> Generating a timestamp with micro and nano seconds defined fails when the
> operating system is linux. Instead of having the required precision, the log
> pads the micro and nano seconds with zeros. Testing it between some
> developpers, the code works properly on Windows and Mac and only fails on
> Linux machines.
> Our team has tested this internally and it seems that the problem is linked
> to a bad interaction between Linux and the library. We've tested with
> different JDK versions and vendors and the problem remained the same. The
> problem also works in the same way whether we use a JsonLayout or a
> PatternLayout to output the timestamp in the log.
>
> {*}Expected{*}:
> A timestamp with the form: "timestamp":"2022-05-04T17:53:43.914{*}123456{*}Z"
> {*}Actual{*}:
> A timestamp with the form: "timestamp":"2022-05-04T17:53:43.914{*}00{*}Z"
>
> I created a small project to reproduce the issue. Notice the script demo.sh
> that allows you to build an alpine image, execute the code in docker and
> output the log in the console.
> [https://github.com/BenjaminTanguay/log4j-low-timestamp-precision-linux-demo]
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (LOG4J2-3498) Timestamp lacks micro and nano second precision on linux
[
https://issues.apache.org/jira/browse/LOG4J2-3498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17532219#comment-17532219
]
Gary D. Gregory commented on LOG4J2-3498:
-
It looks like your project uses Java 11 so the JRE should pickup nanos for
Instant instances. This could be some weird combination of OS/JVM.
> Timestamp lacks micro and nano second precision on linux
>
>
> Key: LOG4J2-3498
> URL: https://issues.apache.org/jira/browse/LOG4J2-3498
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Benjamin Tanguay
>Priority: Minor
>
> Generating a timestamp with micro and nano seconds defined fails when the
> operating system is linux. Instead of having the required precision, the log
> pads the micro and nano seconds with zeros. Testing it between some
> developpers, the code works properly on Windows and Mac and only fails on
> Linux machines.
> Our team has tested this internally and it seems that the problem is linked
> to a bad interaction between Linux and the library. We've tested with
> different JDK versions and vendors and the problem remained the same. The
> problem also works in the same way whether we use a JsonLayout or a
> PatternLayout to output the timestamp in the log.
>
> {*}Expected{*}:
> A timestamp with the form: "timestamp":"2022-05-04T17:53:43.914{*}123456{*}Z"
> {*}Actual{*}:
> A timestamp with the form: "timestamp":"2022-05-04T17:53:43.914{*}00{*}Z"
>
> I created a small project to reproduce the issue. Notice the script demo.sh
> that allows you to build an alpine image, execute the code in docker and
> output the log in the console.
> [https://github.com/BenjaminTanguay/log4j-low-timestamp-precision-linux-demo]
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (LOG4J2-3498) Timestamp lacks micro and nano second precision on linux
[
https://issues.apache.org/jira/browse/LOG4J2-3498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17532217#comment-17532217
]
Gary D. Gregory commented on LOG4J2-3498:
-
You should update your test to Log4j 2.17.2 to make it closer to our git
release-2.x branch (might not matter for actual results but its simpler IMO)
> Timestamp lacks micro and nano second precision on linux
>
>
> Key: LOG4J2-3498
> URL: https://issues.apache.org/jira/browse/LOG4J2-3498
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Benjamin Tanguay
>Priority: Minor
>
> Generating a timestamp with micro and nano seconds defined fails when the
> operating system is linux. Instead of having the required precision, the log
> pads the micro and nano seconds with zeros. Testing it between some
> developpers, the code works properly on Windows and Mac and only fails on
> Linux machines.
> Our team has tested this internally and it seems that the problem is linked
> to a bad interaction between Linux and the library. We've tested with
> different JDK versions and vendors and the problem remained the same. The
> problem also works in the same way whether we use a JsonLayout or a
> PatternLayout to output the timestamp in the log.
>
> {*}Expected{*}:
> A timestamp with the form: "timestamp":"2022-05-04T17:53:43.914{*}123456{*}Z"
> {*}Actual{*}:
> A timestamp with the form: "timestamp":"2022-05-04T17:53:43.914{*}00{*}Z"
>
> I created a small project to reproduce the issue. Notice the script demo.sh
> that allows you to build an alpine image, execute the code in docker and
> output the log in the console.
> [https://github.com/BenjaminTanguay/log4j-low-timestamp-precision-linux-demo]
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [logging-log4cxx] jstsddg opened a new pull request, #110: Fixed version number typo
jstsddg opened a new pull request, #110: URL: https://github.com/apache/logging-log4cxx/pull/110 I was confused while searching for the newest version and could not find v0.13.1. To stop others from searching as well, I fixed the type. Thanks for this great library! The version number was mistakenly displayed as `0.13.1` instead of `0.13.0`. -- 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
