In question Filter unwanted INFO-Messages from Logger it is proposed to disable unwanted SOAP INFO logging by raising the respective log level to WARNING like so:
// Disable SOAP-internal INFO logging
Logger.getLogger("javax.enterprise.resource.webservices.jaxws.server").setLevel(Level.WARNING)
URL url = new URL("http://localhost:9999/ws/SoapControl?wsdl");
QName qname = new QName("http://example.ch/", "SoapControlImplService");
Service service = Service.create(url, qname);
SoapControl soapControl = service.getPort(SoapControl.class); // Unwanted logging happens here
This usually works, but unfortunately not all the time, i.e. the behavior is not deterministic.
Any ideas? Thanks!
Looks like you might be running into garbage collection of loggers. Pin the soap logger with a static final reference or you can add an entry into your logging.properties file to control the level on demand. Every time the logger is recreated the log level is read from the properties file.
Related
Here is a long question for you Log4j2 gurus.
I have a service that:
has very strict performance requirements
is instrumented with a lot of logging calls using log4j2.
A typical call is gated, like:
if ( LOG.isInfoEnabled() ) {
LOG.info("everything's fine");
}
Because of the number of log messages and the performance needs, the service will generally run with logging set to WARN (i.e., not many messages).
However, I have been asked to build in a parameter to the service call that, if given, will cause it to:
Temporarily increase the logging level to whatever was requested in the parameter (e.g., INFO or TRACE)
Add a WriterAppender to capture the logging in a PrintWriter.
Append the PrintWriter log data to the request response.
It seems clear, due to the gating I put around each logging call, that I need to actually increase the logging level temporarily, like this:
LoggerContext ctx = (LoggerContext) LogManager.getContext(false);
Configuration cfg = ctx.getConfiguration();
LoggerConfig loggerCfg = cfg.getLoggerConfig("com.mycompany.scm");
loggerCfg.setLevel(logLevel);
.. other code to add `WriterAppender` ...
ctx.updateLoggers();
But I have an immediate problem with that, in that it causes the logging to ALSO go the log file of the service. That might not be the end of the world, but I'd like to avoid that, if possible.
I did that by having the default logging go through appenders that filter by level, so that even if logging is turned on, it won't write any messages more detailed than are wanted in the default log file. (Like this, from my .properties file):
appenders=scm_warn, scm_info
appender.scm_warn.type = Console
appender.scm_warn.name = SCM_WARN
appender.scm_warn.layout.type = PatternLayout
appender.scm_warn.layout.pattern = %d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n
appender.scm_warn.filter.threshold.type = ThresholdFilter
appender.scm_warn.filter.threshold.level = warn
appender.scm_info.type = Console
appender.scm_info.name = SCM_INFO
appender.scm_info.layout.type = PatternLayout
appender.scm_info.layout.pattern = %d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n
appender.scm_info.filter.threshold.type = ThresholdFilter
appender.scm_info.filter.threshold.level = info
loggers = coreConfigurator
logger.coreConfigurator.name = com.mycompany.scm
logger.coreConfigurator.level = warn
logger.coreConfigurator.additivity = false # do not let configurator log messages get processed by client application's parent or root logger.
logger.coreConfigurator.appenderRefs = core
logger.coreConfigurator.appenderRef.core.ref = SCM_WARN
... that way, even if the logging level gets increased, the extra messages will not go to the main log file (I only want them to go to my PrintWriter).
And now, the question!
How can I temporarily increase the log level (like I try to do in the code above) for the current thread only?
If there are three (3) simultaneous calls to the service, I...
... want each added Appender to only write log messages generated by the thread that created the Appender.
... want each added Appender to be removed after the request that added it finishes.
... want the logging level to get reset back to what it was, as long as there are no other requests with this logging parameter turned on still in process.
Ideally, I think it sounds like I want each thread to have a completely separate logging context. Is that possible? Any thoughts on how to do all this?
You could potentially use a custom Context Selector to have a different context per thread, but that's probably cause issues when multiple threads want to write to the same log file, so likely not a viable option.
The alternative is to write a custom Appender, that uses a ThreadLocal to store the StringWriter. If a StringWriter has not been established for the thread, the appended will skip logging. This custom Appender should be added in the Log4J config file, so it's always there and receiving log entries.
That way you enable logging for a particular thread by creating and assigning a StringWriter to the ThreadLocal, run the code, then clear the ThreadLocal and get the logged information from the StringWriter. Since there initially is no StringWriter for any thread, the appender will do nothing, so shouldn't affect performance in any noticeable way.
You'd still have to do the level-escalation you're already doing, with filters on the other appenders.
You could:
access to class logger and change the log level (as you suggested):
LogManager.getLogger(Class.forName("your.class.package")).setLevel(Level.FATAL);
use a different logger; just configure two different loggers.
I am trying to enable logging for the below class in Confluence:
https://bitbucket.org/mryall/confluence-siteminder-authenticator/src/142de32b6be86321c9791df5dfced607314ed17d/src/main/java/com/atlassian/confluence/authenticator/siteminder/SiteMinderAuthenticator.java?at=default&fileviewer=file-view-default&_ga=2.161258619.735769127.1516003521-2111736425.1515526840
E.g. I know this line:
#SuppressWarnings("unchecked")
public Principal getUser(final HttpServletRequest request, HttpServletResponse response) {
log.info("Starting SiteMinder Authentication for: {}", request.getRequestURI());
Principal loggedInUser = getUserFromSession(request);
if (loggedInUser != null) {
log.debug("{} is already logged in.", loggedInUser.getName());
return loggedInUser;
}
is executed but nothing is written to catalina.out. In log4j.properties I have:
log4j.rootLogger=DEBUG, confluencelog, errorlog
log4j.appender.confluencelog=com.atlassian.confluence.logging.ConfluenceHomeLogAppender
Any ideas why nothing is printed to catalina.out from the above class?
Confluence manual says:
In order to unify logging across different application servers, Confluence uses the atlassian-confluence.log as its primary log, not the application server log.
Once the initial startup sequence is complete, all logging will be to <confluence-home>/logs/atlassian-confluence.log. For example: c:/confluence/data/logs/atlassian-confluence.log.
So look for your entries from that file, not catalina.out.
Your rootLogger level is WARN. It doesn't print lower level logs like INFO, DEBUG
You can set it to DEBUG which covers INFO level.
log4j.rootLogger=DEBUG, confluencelog, errorlog
But it will print a lot including these two.
>log.info("Starting SiteMinder Authentication for: {}", request.getRequestURI());,
>log.debug("{} is already logged in.", loggedInUser.getName());
The best solution is to set package log level to DEBUG. You can add a line into your log4j.properties
log4j.logger.com.atlassian.confluence.authenticator.siteminder=DEBUG, confluencelog
We have a webserver and multiple users log in to it. We generally put log level to ERROR or INFO level. But sometimes, for debugging purpose, we need to see logs. There is one way to set it at runtime, but this process is not so good in case of loads of traffic. Important logs will be missed and also we don't know for how much time we need to keep it that way. I have written a wrapper in log4j v1.2, which just ignores the level check if userid belongs to some TestUsersList. So, it opens all logs for a particular user[a thread] only. A snippet is below-
public void trace(Object message) {
Object diagValue = MDC.get(LoggerConstants.IS_ANALYZER_NUMBER);
if (valueToMatch.equals(diagValue)) { // Some condition to check test number
forcedLog(FQCN, Level.TRACE, message, null);
return;
}
if (repository.isDisabled(Level.TRACE_INT))
return;
if (Level.TRACE.isGreaterOrEqual(this.getEffectiveLevel()))
forcedLog(FQCN, Level.TRACE, message, null);
}
But now I have moved to log4j2, I don't want to write this wrapper again. Is there any inbuilt functionality which log4j2 provides for this?
This can be done with filters. Add a logger to the configuration that logs all the messages you want, then add a ThreadContextMapFilter that has a KeyValuePair for each user you want to log.
Then put the user ids in the Thread Context within the code.
Google App Engine Java uses java.util.logging to create logging messages. I want to modify the log messages, that are displayed in Developers Console - Monitoring - Logs. The idea is to add some additional output like username without putting it in each log message manually:
log.info("user action");
should result in an logging output like
user "testuser": user action
Therefore I created an own Formatter:
public class TestFormatter extends Formatter {
#Override
public String format(LogRecord record) {
// find out username..
return "user " + username + ": " + record.getMessage();
}
}
Setting this as formatter for the ConsoleHandler in the logging.properties has not effekt:
java.util.logging.ConsoleHandler.formatter = com.example.guestbook.TestFormatter
When deploying it in on the local machine, and trying to add it programmatically like this:
Logger rootLogger = Logger.getLogger("");
Handler[] handlers = rootLogger.getHandlers();
log.info("Handler[] size: " + handlers.length);
for(Handler h : handlers) {
log.info(h.toString());
h.setFormatter(new TestFormatter());
}
I get 2 handler, one ConsoleHandler and one DevLogHandler. But setting the formatter results in the fact that no further logs are displayed. On GAE instead I get 0 handler.
When trying to acces Logger.getGlobal() instead of Logger.getLogger(""), I get 0 Handler on the local instance and a SecurityException: No permission to modify global on GAE. This exception already arises when trying to get the list of Handlers.
Now my question: Is there a way to modify the logs of developer console in such a way? If yes, how?
As I reply I got in the past from a Google ticket I opened for a similar question
I would discourage tampering with the Loggers/Handlers used
internally by GAE.
Besides that, the Global Logger cannot be customized, you can try to it with a Logger with a custom name
i have an issue, i want to change the logging level of log4j at runtime, i have tried many things with log4j.properties file, i have also tried to written a code which after particular time again reads the properties file and again configure the logger.
but the problem is, i want to change the logging level to DEBUG for one API call, and then when that call is completed, the logger should again change to the previous value..
please help..
Calling the Logger.setLevel method with the desired Level can alter a Logger's output level at runtime.
The following is an example which demonstrates its usage:
Logger logger = Logger.getLogger("myLogger");
logger.addAppender(new ConsoleAppender(new SimpleLayout()));
System.out.println("*** The current level will be INFO");
logger.setLevel(Level.INFO);
logger.warn("Only INFO and higher will appear");
logger.info("Only INFO and higher will appear");
logger.debug("Only INFO and higher will appear");
System.out.println("*** Changing level to DEBUG");
// remember the previous level
Level previousLevel = logger.getLevel();
logger.setLevel(Level.DEBUG);
logger.warn("DEBUG and higher will appear");
logger.info("DEBUG and higher will appear");
logger.debug("DEBUG and higher will appear");
System.out.println("*** Changing level back to previous level");
// revert to previous level
logger.setLevel(previousLevel);
logger.warn("Only INFO and higher will appear");
logger.info("Only INFO and higher will appear");
logger.debug("Only INFO and higher will appear");
The above outputs:
*** The current level will be INFO
WARN - Only INFO and higher will appear
INFO - Only INFO and higher will appear
*** Changing level to DEBUG
WARN - DEBUG and higher will appear
INFO - DEBUG and higher will appear
DEBUG - DEBUG and higher will appear
*** Changing level back to previous level
WARN - Only INFO and higher will appear
INFO - Only INFO and higher will appear
The above demonstrates how to change the level of one Logger named myLogger, but if the levels of all the loggers in the current repository should be changed, then the setLevel method on the root logger obtained by Logger.getRootLogger should be called to change the levels on all the child loggers.
The log level of a logger can be changed by calling setLevel as described by #coobird. However, there is a catch!
When you call getLogger(name), the logging library will return you an existing Logger object if possible. If two or more threads request a logger with the same name, they will get the same object. If one of the threads calls setLevel, this will change the logger level for all of the others. That can lead to unexpected behavior.
If you really need to do this kind of thing, a better approach would be to create a logger with a different name for the case where you want to logging at a different level.
However, I'm not convinced of the wisdom of the application calling setLevel at all. The setLevel method is about filtering the log messages, and you should not be wresting control of logging filtering away from the user / deployer.
I think it makes sense to call setLevel if a server has a "Controller" thread. That way, you can dynamically change logging level at runtime to debug an issue, and change it back when you are done.
But I don't know what happens when it is called from a separate thread.
setLevel method is there only for java.util.logging.Logger and not for org.apache.logging.log4j.Logger
This is how we set log level in apache log4j
org.apache.logging.log4j.core.LoggerContext
ctx = (LoggerContext) LogManager.getContext(false);
org.apache.logging.log4j.core.config.Configuration
conf = ctx.getConfiguration();
conf.getLoggerConfig(LogManager.ROOT_LOGGER_NAME).setLevel(Level.DEBUG);
ctx.updateLoggers(conf);
If you are using Spring Boot (1.5+), you can use logger endpoint to POST desired logging level.