When a client has our home webpage loaded, there is a webservice call made every 5 seconds and it returns a large chunk of data. This floods the catalina.out log with the INFO request, it's cookie and other header information, and then the data which the service returns to the client. This makes it difficult to investigate other client actions and webservice issues because this service's logging is in the way. Also, on a given day catalina.out can reach over 15gb
I know it's possible to change the level of logging to ERROR or WARN, but I still want INFO on some of the webservice calls.
Is it possible to stop all logging for this particular webservice, route this particular webservice's logging to another file, remove cookie information from catalina (this takes up a big chunk of unnecessary space), remove other header information from the call?
Not sure if I can think of any other ways, but please let me know if you have any solutions that can help my problem.
log4j-2.6.2 (this is currently logger tomcat uses, but i'll change back to JULI if it will help!)
Oracle Linux Server release 6.7
Please let me know your thoughts and if any more information could be of use.
Thank you very much in advance,
Actually, this is an OK forum for this question - you were asking about catalina.out.
The first thing to realize about catalina.out is that in J2EE, webapps are each responsible for their own logging or lack thereof. Anything that shows up in catalina.out gets there because it's either
A) output by a System.out/System.err print (BAD)
B) output by Tomcat's own logger (NOT the application loggers)
C) Re-routed from an application logger (where the logger destination was stdout or stderr).
Pretty much all Java support libraries use a logger rather than brute-force System.out/err writes, so anything written straight to stdout is most likely a badly-written webapp. In case C, you'll have a webapp writing indirectly to stdout, but you'll notice that the logged message has certain attributes such as severity and time/date that a brute-force print statement wouldn't have.
The common convention when a class wants to log something is that the logger it uses will have the same name as the fully-qualified classname of the class itself. So you might have a logger named "org.apache.digester.Digester". So if I define a logging channel that reports everything from logger "org.apache" at level "INFO", then I'll get a log with lots of info-level messages, both from the Digester and from other org.apache packages as well.
But let's say that in particular you want full debugging for the Digester class itself, and only info-level messages from the other classes in the org.apache.digester package and WARN or higher-level severity from org.apache as a whole. In that case, you would define the target log channel to report:
The same applies to other systems, including org.apache.jersey (or whatever Jersey's package structure is).
This is a characteristic of logging itself, not specific to either Tomcat or to Jersey, so if you want even more info on the subject, ask in our "logging" forum.
Some people, when well-known sources tell them that fire will burn them, don't put their hands in the fire.
Some people, being skeptical, will put their hands in the fire, get burned, and learn not to put their hands in the fire.
And some people, believing that they know better than well-known sources, will claim it's a lie, put their hands in the fire, and continue to scream it's a lie even as their hands burn down to charred stumps.