Develop Reference

Why is Java Logging API not displaying FINE messages?

I am wondering why Java Logging API is not displaying fine, finer, and finest messages.
Let's look at the following code:
logger.setLevel(Level.ALL);
logger.info("Level:" + logger.getLevel());
logger.severe("Some Fatal message%n");
logger.warning("Some WARN message%n");
logger.info("Some INFO message%n");
logger.fine("Some DEBUG message%n");
logger.finer("Some DEBUG message%n");
logger.finest("Some TRACE message%n");
I would expect this to display every log message, since I am specifying LogLevel.ALL in the first line.
However it is omitting the fine messages, this is what I see:
22-08-28 16:37:25.997 INFO [global] Level:ALL
22-08-28 16:37:26.025 SEVERE [global] Some Fatal message
22-08-28 16:37:26.025 WARNING [global] Some WARN message
22-08-28 16:37:26.026 INFO [global] Some INFO message
Why is it skipping the fine, finer, and finest, given that I have the level set to ALL?

You need to additionally set the level on the Handlers. Handlers are the things which take the actual log events and then push them to stdout, in your case.
logger.setLevel(Level.ALL);
for (Handler handler : logger.getParent().getHandlers()) {
handler.setLevel(Level.ALL);
}

How to disable some warnings in Spring Boot

in my app i can upload files (max size is 10MB). I created an exception handler for too big files, but console still shows warning that there was a try to upload too big file:
2020-09-30 01:38:59.306 WARN 2476 --- [nio-8080-exec-3] .m.m.a.ExceptionHandlerExceptionResolver : Resolved [org.springframework.web.multipart.MaxUploadSizeExceededException: Maximum upload size exceeded; nested exception is java.lang.IllegalStateException: org.apache.tomcat.util.http.fileupload.impl.SizeLimitExceededException: the request was rejected because its size (26937892) exceeds the configured maximum (10485760)]
Exception handler:
#ExceptionHandler(MaxUploadSizeExceededException.class)
public void oversizedFilesHandler(MaxUploadSizeExceededException e){
accountService.writeExceptionToFile(e);
}
Is it possible to disable these warnings?

You can achieve that by adding log level to your properties file:
RULE : logging.level.xxxx=LEVEL
where:
LEVEL is one of TRACE, DEBUG, INFO, WARN, ERROR, FATAL, OFF.
xxxx is a package/class.
We apply the rule to your case:
logging.level.org.springframework.web=ERROR
Or even thinner:
logging.level.org.springframework.web.multipart =ERROR
Hence, only ERROR, FATAL and OFF level will be logged to you console.

Custom log level disrupts level highlighting

I'm using log4j 2 with a pattern layout that highlights different log levels. In my code, I specify a custom level. When this level is logged, it's not colored and shows null before the level in the log. Below is my pattern and log snip.
Custom level:
final Level STATS = Level.forName("STATS", 510);
Pattern:
%highlight{%-10.10level}{FATAL=red, ERROR=red, WARN=yellow, INFO=green, DEBUG=blue, TRACE=blue, STATS=red}
Output:
Jul 22 15:36:00 INFO [qtp982337150-23] c.e.class : Logging an info line
Jul 22 15:36:00 nullSTATS [qtp982337150-23] c.e.class : Logging a stats line

You may have found a bug. Please raise this on the Log4j2 JIRA issue tracker.

I found the same problem with log levels from jul.
I filed an issue in jira for that: https://issues.apache.org/jira/browse/LOG4J2-2405
This seems to be the same problem.
UPDATE 2018-10-24:
I have prepared a Pull Request that fixes this problem. Hopefully this will be included in Log4j2 soon.

is it possible to avoid error information in text.INFO file of log4j properties?

I am using log4j properties to capture the logs.i wants to remove error info from INFO file.
**
INFO
** file is below:
5:39:02,068 INFO BluSyncLauncher:156 - Application started
05:39:02,080 INFO BluSyncLauncher:586 - Loading UI
05:39:02,263 INFO BackupCrawlDAOImpl:470 - sqlExeception in CREATE_ACTIVITY_TABLEjava.sql.SQLException: [SQLITE_ERROR] SQL error or missing database (duplicate column name: IsFolder)
05:39:02,264 **
ERROR
** BackupActivityHistoryDAOImpl:706 - sqlExeception in CREATE_ACTIVITY_TABLEjava.sql.SQLException: [SQLITE_ERROR] SQL error or missing database (duplicate column name: restartid)
05:39:03,803 INFO BluSyncLauncher:533 - Started crawl (backup)
05:39:03,827 INFO BluSyncLauncher:543 - Starting Activity Timer
05:39:03,860 INFO BluSyncLauncher:557 - Load SystemTrayUI
05:39:10,612 **
ERROR
** BackupPolicyDAOImpl:280 - SQLException while inserting backup policy details
java.sql.SQLException: [SQLITE_CONSTRAINT] Abort due to constraint violation (BACKUP_POLICY.policyGroupName may not be NULL)
at org.sqlite.DB.newSQLException(DB.java:383)
at org.sqlite.DB.newSQLException(DB.java:387)
at org.sqlite.DB.execute(DB.java:342)
at org.sqlite.PrepStmt.execute(PrepStmt.java:65)
at com.parablu.epa.common.dao.BackupPolicyDAOImpl.insertBackupPolicyDetailsToTable(BackupPolicyDAOImpl.java:273)
at com.parablu.epa.common.service.settings.PolicyManagementServerHelper.createGroupPolicyAndChildDetails(PolicyManagementServerHelper.java:306)
at com.parablu.epa.common.service.settings.PolicyManagementServerHelper.loadBackupPolicyElement(PolicyManagementServerHelper.java:245)
at com.parablu.epa.service.backup.LinuxCheckBackupPolicy.checkGroupPolicy(LinuxCheckBackupPolicy.java:140)
at com.parablu.epa.service.alarm.LinuxPolicyRefreshHelper$1.run(LinuxPolicyRefreshHelper.java:55)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)

Loggers may be assigned levels. The set of possible levels, that is:
TRACE,
DEBUG,
INFO,
WARN,
ERROR and
FATAL
are defined in the org.apache.log4j.Level class. Although we do not encourage you to do so,
you may define your own levels by sub-classing the Level class.
Level Inheritance
A logging request is said to be enabled if its level is higher than or equal to the level of its logger. Otherwise, the request is said to be disabled. A logger without an assigned level will inherit one from the hierarchy. This rule is summarized below.
Basic Selection Rule
A log request of level p in a logger with (either assigned or
inherited, whichever is appropriate) level q, is enabled if p >= q.
UPDATE:
In Log4j2 version 2.0.2
If you wish to change the root logger level, do something like this :
LoggerContext ctx = (LoggerContext) LogManager.getContext(false);
Configuration config = ctx.getConfiguration();
LoggerConfig loggerConfig = config.getLoggerConfig(LogManager.ROOT_LOGGER_NAME);
loggerConfig.setLevel(level);
ctx.updateLoggers(); // This causes all Loggers to refetch information from their LoggerConfig.

I get some information from log4j filter
and read the log4j source code. I found it is possible.
Do like this:
appender.File.type=File
appender.File.name=infolog
appender.File.layout.type=PatternLayout
appender.File.layout.pattern=%d %p %C{1.} [%t] %m%n
appender.File.filename=${infologfilename}
#here! add filter named star, type is ThresholdFilter
appender.File.filter.star.type=ThresholdFilter
#level you want to filter
appender.File.filter.star.level=info
#if mathched the level, the log higher then the level will not output
appender.File.filter.star.onMatch=DENY
#if mismathed,output
appender.File.filter.star.onMisMatch=ACCEPT
May be it can help you.
I suggest you to use xml configuration,easy to read and edit.

Log4j logs decreases application performance?

Does logging decreases application performance?
and how to restrict display-tags logs to be printed in log files?
eg. my log file has below logs
[2012-06-20 15:52:06,290] org.displaytag.tags.TableTag isFirstIteration 684 - [data] first iteration=true (row number=1)
[2012-06-20 15:52:06,290] org.displaytag.tags.TableTag isFirstIteration 684 - [data] first iteration=true (row number=1)
[2012-06-20 15:52:06,290] org.displaytag.tags.TableTag isFirstIteration 684 - [data] first iteration=true (row number=1)
[2012-06-20 15:52:06,290] org.displaytag.tags.TableTag isFirstIteration 684 - [data] first iteration=true (row number=1)
why the above is in log file?
log.properties file
# Log4j configuration file.
log4j.rootCategory=DEBUG, A1
# Available levels are DEBUG, INFO, WARN, ERROR, FATAL
#
# A1 is a ConsoleAppender
#
log4j.appender.A1 = org.apache.log4j.RollingFileAppender
log4j.appender.A1.File = C:/LogInfo/logfile.log
log4j.appender.A1.MaxFileSize = 100MB
log4j.appender.A1.MaxBackupIndex=50
log4j.appender.A1.layout = org.apache.log4j.PatternLayout
log4j.appender.A1.append = true
log4j.appender.A1.layout.ConversionPattern = [%d] %C %M %L - %m%n
log4j.appender.A1.Threshold = DEBUG
how to stop (org.displaytag.tags.TableTag) these kind of logs to be printed in log files

Does logging decreases application performance?
Yes. How much it does depends on a number of factors; see below.
and how to restrict display-tags logs to be printed in log files?
By changing the ConversionPattern in the logging properties
why the above is in log file?
Because:
somewhere in the code is a call to a Logger method (probably debug(String)) with that message, and
your logging properties set the logging Threshold to DEBUG for the appender.
To improve performance:
change the ConversionPattern to use less expensive date/time formatting, and (more importantly) avoid 'C', 'F', 'L' and 'M' because they are particularly expensive.
change the logging Threshold to INFO or WARNING or ERROR to reduce the amount of logging,
put the Logger.debug(...) call inside an if statement that checks that debug logging is enabled. This saves the cost of assembling the log message in cases where it won't be needed; see In log4j, does checking isDebugEnabled before logging improve performance?.
with log4j version 2 (log4j2), there are overloads that on the logging methods that take a format and parameters. These reduce the overhead when a logging at a level that is disabled.
look also at logback and log4j 2.0.
You can also throttle logging at the Logger level ... as described in the log4j documentation. In fact, the documentation answers most of the questions that you asked, and has a lot of detail on the topics of logging performance and logging configuration.

Short answer: yes, it decreases application performance as it uses some CPU cycles and other resources (memory, etc).
See also this question : log4j performance

Logging can be 30% of you cpu time or more. In terms of jitter, it as large (and more often) than your GC delays.
A simple way to reduce overhead is to use the Pattern to turn off where you are logging each message from. In your case this is %C %M and %L as it has to take a stack trace (of the entier stack) to get this information.

Yes they do. That's why you should only log an error or something that must absolutely be logged. You can also log information helpful for debugging in the debug channel so it won't affect production performance.

how about?
log4j.category.org.displaytag.tags.TableTag=ERROR, A1

You can restrict junk logs like this.
Set the root logger as INFO so that unnecessary debug logs won't come and fill up your log file.
log4j.rootCategory=INFO, A1
If you want specific class or package to give out DEBUG logs you can do it like this.
log4j.logger.org.hibernate.event.def.DefaultLoadEventListener=DEBUG,A1
The above will print DEBUG level logs from the class DefaultLoadEventListener in your log file along with other INFO level logs.