Probably it is a stupid question - I have to write a library for logging intercepted requests (I used HandlerInterceptorAdapter). Content for request is logged by Slf4j logger in postHandle method. The thing is that when I add this library to other projects logs are not shown when the app is up.
How I have to configure logger to make these logs visible in app?
Related
In my application, I am using SLF4J's Logger for logging. When an error is logged, I am sending a message to another application. The problem is that one of the libraries I use (Slack API) uses the same logger (in class com.slack.api.methods.impl.TeamIdCache), so when it logs an error, my application sends a message that I didn't intend it to send.
How can I disable that library's logger?
You can disable specific logger in your application properties:
logging.level.com.slack.api.methods.impl.TeamIdCache=OFF
See Spring documentation for more information regarding other configuration options and log levels.
Usually my logging is as follows:
private final Logger LOGGER = org.slf4j.LoggerFactory.getLogger(this.getClass());
Question: if I deploy my app as a war to a tomcat webserver, is the logging sync or async by default?
I'm asking because the tomcats logging.properties file defines the AsyncFileHandler throughout, like .handlers = 1catalina.org.apache.juli.AsyncFileHandler.
My question is, if all of my log statements are "passed" to that tomcat async file handler, and then logged async automatically?
Tomcat's logging is irrelevant if you are using a separate logging framework (such as SLF4J) in your web application. The SLF4J docs should tell you what is synchronous and what is asynchronous in that framework.
For the record, Tomcat's internal logging is synchronous until it gets to the AsyncFileHandler where it is buffered and written asynchronously on a separate thread (because writing to the file system is usually the slowest part of the logging call).
I'm trying to essentially configure logging in three places, independently. Ideally, each component that is logging is fully unaware of the others. I'd like to use logback for this, as it seems to have some decent features and performance.
Here are the places from which I would like to log from and to:
Tomcat (7) should log to ${catalina_home}/logs/catalina.out, and should only log Tomcat events (deployments, server startup, etc)
A web application hosted in Tomcat should log to ${catalina_home}/logs/application.log, and should only log application things, like results of request validations or errors
A library that is included in the web application should log to ${catalina_home}/logs/library.log, and should only log things specific to that library, like time it takes to interact with some other web-service or library-specific errors
I know this is probably not the way it would work, but I would think I need to have a logback.xml file for each concern. Actually, I have created them and added to the classpath such that I get a "logback.xml occurs multiple times on the classpath" error.
I can see why I would need to consolidat my application and my library logback configuration to a single logback.xml file, but how would I keep the container logging config separate from the application+library logging config? Adding a logback config file to my application, as well as logback enabling Tomcat as described here, still yields a "multiple logback.xml" error. And, Chapter 9 of the logback user manual, which talks about separation of logging, doesn't really show how to separate the container and applications (just multiple applications), unless I am missing something there.
I am trying a spring MVC application on tomcat server..
I am always getting the error as resource not found(please see the question if you have time)..I think there is some problem with the view resolver..
I want debug this application to know where i am doing wrong...
Is that possible?
I don't know if it is a lame question for senior developers :)
I would set the logging level of DispatcherServlet to DEBUG and see what it says. Spring contains mostly good logging at DEBUG level to tell you what's going on (despite that it's INFO level is nigh-useless).
If DispatcherServlet's logging doesn't say much, try some of the other classes you have configured in your application (do one at a time or you'll get overwhelmed with log messages)
If you are using Eclipse, you can add Tomcat runtime in preferences and add new server in servers view in eclipse. Then you can run the server in debug mode.
Also you can attach source code for jar files(in your case spring jars) in eclipse so that when you debug it will load proper source files.
Enviroment: JSF 2.0, RichFaces 3.3.3, Facelets 1.1.15B1, Spring Framework 3.x, WebFlow 2.1, MyBatis 3.0.1, Oracle 10/11 g backend, SLF4j into Log4j. Well thats probably TMI since my issue is only a logging problem but better to be too thorough than not.
Anyways... I just setup SLF4j & log4j so now all of the internal facelets log msgs are being dumped into log4j & I can actually see them. In addition I setup Tomcat to also dump to log4j instead of it's custom version of JULI. Upon doing this everything appeared to be working great.... until i shut down the app.
Midway through the shutdown process my app started barfing up errors left 'n right because (which makes sense) Tomcat is trying to grab a logger instance AFTER spring has already cleaned up the logger bean.
Anyone familiar with this? I imagine it must be a common problem for anyone who has Tomcat using the non-standard logging mechanism. What is the best way around this?
I thought maybe if I just raised the log level then Tomcat wouldn't even try to log msgs because of the level req.s but the problem occurs when tomcat is trying to retrieve a logger instance so that didn't work.
I would move the Logger higher in the food chain.
I personally never configured log4j with spring relying on its own configuration mechanism (and hunting for where the heck it finds the properties file it is using in the process).
If you can you can opt to completely remove log4j from your war and rely on the log4j in the common tomcat library classpath. Then of course you are at the mercy of the tomcat configuration and you cannot access the log from inside your app, but it is always there during the complete lifecycle of your app.