In fact, it is the standard output (stdout) and standard error (stderr) of tomcat. This is specified in the tomcat startup script. If it is not modified, stdout and stderr will be redirected here. So what we use to print in our application will come here. In addition, if we use other log frameworks in the application and configure output to the Console, it will also appear here. For example, taking logback as an example, if configured, it will be output to the inside.
cataliana.{yyyy-MM-dd}.log and localhost.{yyyy-MM-dd}.log
Both logs are configured (by default, the start script specifies the same two variables). A typical possibility is as follows:
handlers = , ,
.handlers = ,
= INFO
= ${}/logs
= catalina.
= FINE
= ${}/logs
= localhost.
= INFO
=
.[Catalina].[localhost].level = INFO
.[Catalina].[localhost].handlers =
The roughly means that root outputs to catalina and console. The catalina here corresponds to catalina.{yyyy-MM-dd}.log according to the configuration, and the console here will eventually be output. This is why we see that catalina.{yyyy-MM-dd}.log and log are the same.
There is also a localhost in the configuration file. All logname or parent logname is .[Catalina].[localhost] will be output to localhost.{yyyy-MM-dd}.log file. And what does this logname mean? There is a configuration file in tomcat, which has such a fragment:
<Engine name="Catalina" defaultHost="localhost">
<Host name="localhost" appBase="webapps"
unpackWARs="false" autoDeploy="false">
</Host>
</Engine>
We can understand it simply: a Tomcat process corresponds to an Engine. There can be multiple Hosts (Virtual Hosts) under one Engine, and there can be multiple Contexts in a Host. For example, we often deploy applications under ROOT or other directories in webapps, this is Context.
Among them, Engine corresponds to the StandardEngine class in tomcat, Host corresponds to the StandardHost class, and Context corresponds to the StandardContext. These classes are derived from ContainerBase. Some logs related to application code in these classes use the getLogger in ContainerBase, and the logger name of this logger is: .[current container name].[current container name]...
In our webapp, the initialization of listener, filter, and servlet is carried out in the StandardContext. For example, there is an listener in the ROOT that initializes an exception, and the logging log is logger name.[Catalina].[localhost].[/]. Among them, Catalina and localhost are the names of Engine and Host in the above xml fragment, and [/] are the names of StandardContext corresponding to ROOT. Therefore, the logs of listener, filter, and servlet initialization need to be viewed from localhost.{yyyy-MM-dd}.log. For example, now we use Spring. We often use a listener provided by Spring. If the initialization of a certain bean fails to initialize, the entire application will not be started, the exception log at this time is output to localhost, not in it. So sometimes our application cannot be started, and then we look for the log, but in the end we do not locate the root cause, because the log we are looking for is wrong. But sometimes there are logs we want, because some components we use catch the exception themselves and print them. At this time, if these logs happen to be output to console, these logs will also appear in it.
Summarize
To sum up, if there is an error in standard output and standard, all outputs to these two locations will enter. This contains the logs output by tomcat running itself and the logs output to console in the application. catalina.{yyyy-MM-dd}.log is some logs run by tomcat itself, and these logs will also be output to, but the logs output by the application to the console will not be output to catalina.{yyyy-MM-dd}.log. localhost.{yyyy-MM-dd}.log is mainly the log output of unhandled exceptions of the application initialization (listener, filter, servlet) and the unhandled exceptions will eventually cause the application to fail to start.
Finally, let’s think about it. A few log files here are actually not conducive to problem search. Why don’t they just output them? I think tomcat as a general container itself, maybe considering that there are multiple Hosts under Engine, the log of each Host still needs to be output to a different file. In reality, we often have a single container, a single host, or even a Context with only one ROOT.
Generally, log4j is used to divide the business according to the business. For some more important businesses, they will be single-file, which is convenient and easy to locate problems. Others will be called catalina by default.
This is the end of this article about the difference and uses of Tomcat. For more related Tomcat, please search for my previous articles or continue browsing the related articles below. I hope everyone will support me in the future!