I have simplified tomcat's logging properties to just this:
handlers = java.util.logging.ConsoleHandler
java.util.logging.ConsoleHandler.level = FINE
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
java.util.logging.SimpleFormatter.format=%1$tF %1$TT.%1tL [::] %4$s %3$s %5$s %n
org.springframework.aop.framework.CglibAopProxy.level = ERROR
My issue is that the last line seems to be completely ignored and I keep seeing logs like this:
2018-05-09 10:40:33.159 [::] INFO org.springframework.aop.framework.CglibAopProxy
I am absolutely sure it comes from this logger thanks to the log format I set in the logging.properties.
My issue is that the last line seems to be completely ignored...
It is ignored because ERROR fails to be parsed as valid level. Per the docs:
Valid values are integers between Integer.MIN_VALUE and Integer.MAX_VALUE, and all known level names. Known names are the levels defined by this class (e.g., FINE, FINER, FINEST), or created by this class with appropriate package access, or new levels defined or created by subclasses.
Change your logging line to one of the valid levels that is higher than INFO. Choose one of the following log lines:
org.springframework.aop.framework.CglibAopProxy.level = OFF
org.springframework.aop.framework.CglibAopProxy.level = SEVERE
org.springframework.aop.framework.CglibAopProxy.level = WARNING
Having an issue getting filters to work with Log4j 2 (2.4 and 2.6). Previously I had custom filters using logback and XML configuration like . Decided it would be reasonable to use the ConfigurationBuilder instead.
Just to give a simple example:
ConfigurationBuilder< BuiltConfiguration > builder =
ConfigurationBuilderFactory.newConfigurationBuilder();
builder.setConfigurationName("TestLogger");
AppenderComponentBuilder appenderBuilder = builder.newAppender("file", "FILE")
.addAttribute("fileName", "C:\\client_test.log").addAttribute("append", false).add(builder.newFilter("LevelRangeFilter", Filter.Result.ACCEPT, Filter.Result.NEUTRAL).
addAttribute("minLevel", Level.INFO).addAttribute("maxLevel", Level.INFO));
appenderBuilder.add(builder.newLayout("PatternLayout").addAttribute("pattern", "%msg%n%throwable"));
builder.add(appenderBuilder);
builder.add(builder.newLogger("TestLogger", Level.INFO)
.add(builder.newAppenderRef("file"))
.addAttribute("additivity", false));
LoggerContext logctx = Configurator.initialize(builder.build());
logFile = logctx.getLogger( "TestLogger" );
Excuse my ignorance, I am fairly new to the Java config for log4j!
If I initialize the context (just the current class I'm in):
LoggerContext logctx = Configurator.initialize(builder.build());
logFile = logctx.getLogger( "TestLogger" );
and try:
logFile.info("Info level logging");
logFile.error("Error level logging");
I see both of these outputs. I thought with the LevelRangeFilter with a range of INFO->INFO I would only see the info log levels ?
Realistically what I want is to have different appenders based on the log level (as I have with the logback xml configuration).
I've found it difficult to follow the documentation - trying to determine the various plugins and attributes to be used with the various component builders and just the general concepts.
The LevelRangeFilter seemed to fit the bill - where I could add different appenders as newAppenderRef to the build and write them out on to different files based on a tight range.
Any thoughts ?
Thanks!
c
Solved it. Used this for reference: https://logging.apache.org/log4j/2.x/log4j-core/apidocs/index.html
I had my mismatch set to NEUTRAL instead of DENY. Putting deny in cut the bad ranges out of the logs. So I was able to split the logs with two appenders using this filter as so:
AppenderComponentBuilder appenderBuilderInfo = builder.newAppender("fileInfo", "FILE")
.addAttribute("fileName", "C:\\client_info.log").addAttribute("append", false).add(builder.newFilter("LevelRangeFilter", Filter.Result.ACCEPT, Filter.Result.DENY)
.addAttribute("minLevel", Level.INFO).addAttribute("maxLevel", Level.INFO));
AppenderComponentBuilder appenderBuilderError = builder.newAppender("fileError", "FILE")
.addAttribute("fileName", "C:\\client_error.log").addAttribute("append", false).add(builder.newFilter("LevelRangeFilter", Filter.Result.ACCEPT, Filter.Result.DENY)
.addAttribute("minLevel", Level.ERROR).addAttribute("maxLevel", Level.ERROR));
appenderBuilderInfo.add(builder.newLayout("PatternLayout").addAttribute("pattern", "%msg%n%throwable"));
appenderBuilderError.add(builder.newLayout("PatternLayout").addAttribute("pattern", "%msg%n%throwable"));
builder.add(appenderBuilderInfo);
builder.add(appenderBuilderError);
builder.add(builder.newLogger("TestLogger", Level.INFO)
.add(builder.newAppenderRef("fileInfo"))
.addAttribute("additivity", false)
.add(builder.newAppenderRef("fileError"))
.addAttribute("additivity", false));
I need to set maxfile size for my application but currently i am using Dropwizard core version 0.8.4 and its file appender does not support this feature.
So I approached like below by writing a custom appender as updating to latest dropwizard(which support my need) version not an option right now.
private void initLogging(Configuration configuration) throws JoranException {
final File logDir = new File("/tmp/enforcer");
final File logFile = new File(logDir, "wallet.log");
final LoggerContext loggerContext = (LoggerContext) LoggerFactory.getILoggerFactory();
RollingFileAppender<ILoggingEvent> rollingFileAppender = new RollingFileAppender<ILoggingEvent>();
rollingFileAppender.setFile(logFile.getAbsolutePath());
rollingFileAppender.setName("com.documents4j.logger.server.file");
rollingFileAppender.setContext(loggerContext);
FixedWindowRollingPolicy fixedWindowRollingPolicy = new FixedWindowRollingPolicy();
fixedWindowRollingPolicy.setFileNamePattern(logFile.getAbsolutePath() +"%i.gz");
fixedWindowRollingPolicy.setMaxIndex(7);
fixedWindowRollingPolicy.setContext(loggerContext);
fixedWindowRollingPolicy.setParent(rollingFileAppender);
fixedWindowRollingPolicy.start();
SizeBasedTriggeringPolicy<ILoggingEvent> sizeBasedTriggeringPolicy = new SizeBasedTriggeringPolicy<ILoggingEvent>();
sizeBasedTriggeringPolicy.setMaxFileSize("2KB");
sizeBasedTriggeringPolicy.setContext(loggerContext);
sizeBasedTriggeringPolicy.start();
rollingFileAppender.setRollingPolicy(fixedWindowRollingPolicy);
rollingFileAppender.setTriggeringPolicy(sizeBasedTriggeringPolicy);
rollingFileAppender.start();
System.out.println("Logging: The log is written to " + logFile);
final ch.qos.logback.classic.Logger log = loggerContext.getLogger(Logger.ROOT_LOGGER_NAME);
log.setLevel(Level.DEBUG);
log.addAppender(rollingFileAppender);
}
#Override
public void run(Configuration configuration, Environment environment) throws Exception
{
initLogging(configuration);
}
My yaml file config is
logging:
level: INFO
org.springframework.retry.support.RetryTemplate: DEBUG
appenders:
- type: file
currentLogFilename: /tmp/enforcer.log
threshold: ALL
archive: true
archivedLogFilenamePattern: /tmp/enforcer-%d.log
archivedFileCount: 5
timeZone: UTC
logFormat: '%-5level [%date{yyyy-MM-dd HH:mm:ss,SSS}] [%X{realdocRequestId}] %logger{15}: %m%n'
Now when i run my application i noticed, even though custom log file (/tmp/enforcer/wallet.log) is created in the particular directory but actual log is not dumped i.e. wallet.log file size is 0 kb where as the log file configured in yaml is created and size is certain kb and goes on increasing as log event is generated.
I am not able figure out what is wrong im doing, help will be appreciated.
your logger doesn't log anything because you never set an encoder to it. Set a breakpoint in:
OutputStreamAppender#start() and you will see that there is no encoder.
It will work once you add:
LayoutWrappingEncoder<ILoggingEvent> layoutEncoder = new LayoutWrappingEncoder<>();
DropwizardLayout formatter = new DropwizardLayout(loggerContext, TimeZone.getDefault());
formatter.setPattern("[%level] [%h] %d{yyyy-MM-dd'T'HH:mm:ss.SSS'Z', UTC} [%thread] [%logger] %msg%n");
layoutEncoder.setLayout(formatter);
formatter.start();
rollingFileAppender.setEncoder(layoutEncoder);
Of course you can define whichever format you like (and formatter).
But keep in mind that this is a fairly hacky example of what you try to achieve. You now have 2 points in code where you configure logging (DW and your own). You have yaml configured logging as well as your own. I recommend investing a bit of work and adding a proper AppenderFactory that you can use.
Hope that helps,
Artur
I'm trying to programmatically configure LogBack's RollingFileAppender (ch.qos.logback.core.rolling.RollingFileAppender) and it doesn't seem to be working. When I'm using FileAppender, everything seems to be working fine with exact same configuration (less policies/trigger) so I'm guessing it's not a permission issue. I tried commenting out all policy configuration and that didn't help either. Below is my sample code, with some hard-coded values. Also, there's no error at all what so ever. When I debug the LogBack source code, I didn't see anything that could have gone wrong.
Any hint is appreciative. I need to get this working without a configuration file since that's a restriction in my organization. I'm testing this out on a MacBook.
Logger logger = (Logger)LoggerFactory.getLogger(applicationName);
LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory();
lc.reset();
RollingFileAppender<ILoggingEvent> fileAppender =
new RollingFileAppender<ILoggingEvent>();
fileAppender.setAppend(true);
fileAppender.setFile("/Users/Jack/Desktop/logs/" + applicationName + ".log");
fileAppender.setContext(lc);
SizeBasedTriggeringPolicy<ILoggingEvent> rPolicy =
new SizeBasedTriggeringPolicy<ILoggingEvent>("20MB");
fileAppender.setTriggeringPolicy(rPolicy);
TimeBasedRollingPolicy<ILoggingEvent> tPolicy =
new TimeBasedRollingPolicy<ILoggingEvent>();
tPolicy.setFileNamePattern("/archive/" + applicationName + ".%d");
tPolicy.setMaxHistory(180);
tPolicy.setParent(fileAppender);
tPolicy.setContext(lc);
PatternLayout pl = new PatternLayout();
pl.setPattern("%d %5p %t [%c:%L] %m%n)");
pl.setContext(lc);
pl.start();
fileAppender.setLayout(pl);
fileAppender.start();
logger.addAppender(fileAppender);
logger.setLevel(Level.DEBUG);
logger.debug("Test message");
The key issues are as follow:
RollingFileAppender must have RollingPolicy
RollingFileAppender requires PatternLayoutEncoder instead of PatternEncoder
RollingPolicy must also be started or certain properties will be null
What made this very difficult to figure out is that I couldn't figure out how to make BasicStatusManager print out error message. I ended up having to use the following code to print everything out.
for(Status status : logger.getLoggerContext().getStatusManager().getCopyOfStatusList()){
System.out.println(status.getOrigin() + " - " + status.getMessage());
}
There is a separate thread going on as mentioned in the comment above on why LogBack log messages are not printing out. I also have an email thread going on with Nabble. Will post the solution in that thread as soon as I or someone can figure this out.
The JavaDocs for java.util.logging.Level state:
The levels in descending order are:
SEVERE (highest value)
WARNING
INFO
CONFIG
FINE
FINER
FINEST (lowest value)
Source
import java.util.logging.*;
class LoggingLevelsBlunder {
public static void main(String[] args) {
Logger logger = Logger.getAnonymousLogger();
logger.setLevel(Level.FINER);
System.out.println("Logging level is: " + logger.getLevel());
for (int ii=0; ii<3; ii++) {
logger.log(Level.FINE, ii + " " + (ii*ii));
logger.log(Level.INFO, ii + " " + (ii*ii));
}
}
}
Output
Logging level is: FINER
Jun 11, 2011 9:39:23 PM LoggingLevelsBlunder main
INFO: 0 0
Jun 11, 2011 9:39:24 PM LoggingLevelsBlunder main
INFO: 1 1
Jun 11, 2011 9:39:24 PM LoggingLevelsBlunder main
INFO: 2 4
Press any key to continue . . .
Problem statement
My example sets the Level to FINER, so I was expecting to see 2 messages for each loop. Instead I see a single message for each loop (the Level.FINE messages are missing).
Question
What needs changing in order to see the FINE (, FINER or FINEST) output?
Update (solution)
Thanks to Vineet Reynolds' answer, this version works according to my expectation. It displays 3 x INFO messages, & 3 x FINE messages.
import java.util.logging.*;
class LoggingLevelsBlunder {
public static void main(String[] args) {
Logger logger = Logger.getAnonymousLogger();
// LOG this level to the log
logger.setLevel(Level.FINER);
ConsoleHandler handler = new ConsoleHandler();
// PUBLISH this level
handler.setLevel(Level.FINER);
logger.addHandler(handler);
System.out.println("Logging level is: " + logger.getLevel());
for (int ii=0; ii<3; ii++) {
logger.log(Level.FINE, ii + " " + (ii*ii));
logger.log(Level.INFO, ii + " " + (ii*ii));
}
}
}
Loggers only log the message, i.e. they create the log records (or logging requests). They do not publish the messages to the destinations, which is taken care of by the Handlers. Setting the level of a logger, only causes it to create log records matching that level or higher.
You might be using a ConsoleHandler (I couldn't infer where your output is System.err or a file, but I would assume that it is the former), which defaults to publishing log records of the level Level.INFO. You will have to configure this handler, to publish log records of level Level.FINER and higher, for the desired outcome.
I would recommend reading the Java Logging Overview guide, in order to understand the underlying design. The guide covers the difference between the concept of a Logger and a Handler.
Editing the handler level
1. Using the Configuration file
The java.util.logging properties file (by default, this is the logging.properties file in JRE_HOME/lib) can be modified to change the default level of the ConsoleHandler:
java.util.logging.ConsoleHandler.level = FINER
2. Creating handlers at runtime
This is not recommended, for it would result in overriding the global configuration. Using this throughout your code base will result in a possibly unmanageable logger configuration.
Handler consoleHandler = new ConsoleHandler();
consoleHandler.setLevel(Level.FINER);
Logger.getAnonymousLogger().addHandler(consoleHandler);
The Why
java.util.logging has a root logger that defaults to Level.INFO, and a ConsoleHandler attached to it that also defaults to Level.INFO.
FINE is lower than INFO, so fine messages are not displayed by default.
Solution 1
Create a logger for your whole application, e.g. from your package name or use Logger.getGlobal(), and hook your own ConsoleLogger to it.
Then either ask root logger to shut up (to avoid duplicate output of higher level messages), or ask your logger to not forward logs to root.
public static final Logger applog = Logger.getGlobal();
...
// Create and set handler
Handler systemOut = new ConsoleHandler();
systemOut.setLevel( Level.ALL );
applog.addHandler( systemOut );
applog.setLevel( Level.ALL );
// Prevent logs from processed by default Console handler.
applog.setUseParentHandlers( false ); // Solution 1
Logger.getLogger("").setLevel( Level.OFF ); // Solution 2
Solution 2
Alternatively, you may lower the root logger's bar.
You can set them by code:
Logger rootLog = Logger.getLogger("");
rootLog.setLevel( Level.FINE );
rootLog.getHandlers()[0].setLevel( Level.FINE ); // Default console handler
Or with logging configuration file, if you are using it:
.level = FINE
java.util.logging.ConsoleHandler.level = FINE
By lowering the global level, you may start seeing messages from core libraries, such as from some Swing or JavaFX components.
In this case you may set a Filter on the root logger to filter out messages not from your program.
WHY
As mentioned by #Sheepy, the reason why it doesn't work is that java.util.logging.Logger has a root logger that defaults to Level.INFO, and the ConsoleHandler attached to that root logger also defaults to Level.INFO. Therefore, in order to see the FINE (, FINER or FINEST) output, you need to set the default value of the root logger and its ConsoleHandler to Level.FINE as follows:
Logger.getLogger("").setLevel(Level.FINE);
Logger.getLogger("").getHandlers()[0].setLevel(Level.FINE);
The problem of your Update (solution)
As mentioned by #mins, you will have the messages printed twice on the console for INFO and above: first by the anonymous logger, then by its parent, the root logger which also has a ConsoleHandler set to INFO by default. To disable the root logger, you need to add this line of code: logger.setUseParentHandlers(false);
There are other ways to prevent logs from being processed by default Console handler of the root logger mentioned by #Sheepy, e.g.:
Logger.getLogger("").getHandlers()[0].setLevel( Level.OFF );
But Logger.getLogger("").setLevel( Level.OFF ); won't work because it only blocks the message passed directly to the root logger, not the message comes from a child logger. To illustrate how the Logger Hierarchy works, I draw the following diagram:
public void setLevel(Level newLevel) set the log level specifying which message levels will be logged by this logger. Message levels lower than this value will be discarded. The level value Level.OFF can be used to turn off logging. If the new level is null, it means that this node should inherit its level from its nearest ancestor with a specific (non-null) level value.
why is my java logging not working
provides a jar file that will help you work out why your logging in not working as expected.
It gives you a complete dump of what loggers and handlers have been installed and what levels are set and at which level in the logging hierarchy.
Tried other variants, this can be proper
Logger logger = Logger.getLogger(MyClass.class.getName());
Level level = Level.ALL;
for(Handler h : java.util.logging.Logger.getLogger("").getHandlers())
h.setLevel(level);
logger.setLevel(level);
// this must be shown
logger.fine("fine");
logger.info("info");
I found my actual problem and it was not mentioned in any answer: some of my unit-tests were causing logging initialization code to be run multiple times within the same test suite, messing up the logging on the later tests.
This solution appears better to me, regarding maintainability and design for change:
Create the logging property file embedding it in the resource project folder, to be included in the jar file:
# Logging
handlers = java.util.logging.ConsoleHandler
.level = ALL
# Console Logging
java.util.logging.ConsoleHandler.level = ALL
Load the property file from code:
public static java.net.URL retrieveURLOfJarResource(String resourceName) {
return Thread.currentThread().getContextClassLoader().getResource(resourceName);
}
public synchronized void initializeLogger() {
try (InputStream is = retrieveURLOfJarResource("logging.properties").openStream()) {
LogManager.getLogManager().readConfiguration(is);
} catch (IOException e) {
// ...
}
}
To change the logcat level:
adb shell setprop log.tag.<YOUR_LOG_TAG> <LEVEL>
For example:
C:\Users\my_name\AppData\Local\Android\Sdk\platform-tools\adb.exe shell setprop log.tag.com.mycompany.myapp VERBOSE
Here is why this works for Logger:
The root logger, which is the parent of your logger, is using an internal logging handler com.android.internal.logging.AndroidHandler. This handler in its publish method is checking Log.isLoggable and writing to Log.
Note about <YOUR_LOG_TAG>:
Basically this is the name of your Logger. For global Logger it is Logger.GLOBAL_LOGGER_NAME. For anonymous logger it is "null". Tag is limited to 23 characters.
AndroidHandler does a transformation from the logger name to the tag:
private static String loggerNameToTag(String loggerName) {
// Anonymous logger.
if (loggerName == null) {
return "null";
}
int length = loggerName.length();
if (length <= 23) {
return loggerName;
}
int lastPeriod = loggerName.lastIndexOf(".");
return length - (lastPeriod + 1) <= 23
? loggerName.substring(lastPeriod + 1)
: loggerName.substring(loggerName.length() - 23);
}