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:
org.apache WARN
org.apache.digester INFO
org.apache.digester.Digester DEBUG
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.