Konstantin Kolinko wrote:
2010/9/21 Christopher Gross <[email protected]>:
I have an older version of Solr (1.2) running on Tomcat 5.5.25.
How do they perform their logging? Do they use some logging library?
If yes, then you should configure that library.
I added swallowOutput="true" to the solr context file.
swallowOutput works for simple things like System.out.println(), but
it fails in certain more complex cases
E.g., java.util.logging.ConsoleHandler (see your logging.properties)
is created at some early time when the server starts. It remembers a
reference to the original System.out (err) stream and thus is not
affected by swallowOutput.
Note the following line in logging.properties:
.handlers = 1catalina.org.apache.juli.FileHandler,
java.util.logging.ConsoleHandler
It means that if some event is not logged by other handlers, by
default it will be logged both by 1st FileHandler and by
ConsoleHandler. If you remove ConsoleHandler from that line those
events won't be printed to the console (and thus to the catalina.out)
Ah !
(Sorry to the OP, if I barge in uninvited)
The above seems to be exactly what I was missing as information, after Konstantin's
previous answer to one my own logging questions.
If it may help anyone else :
I have a similar issue but a bit different : on my systems (Debian Linux Lenny), the
Tomcat startup script configures Tomcat to be started under jsvc, and redirects the
STDOUT/STDERR of jsvc to the system's SYSLOG.
So I was not getting this application's output into catalina.out, but I was getting all of
it in /var/log/daemon.log. (And I do not have the source of this application to check
exactly what it does).
Even after after creating a META-INF/context.xml file for that application, and adding the
"swallowOutput" attribute to the <Context> element, I am still seeing (not all, but most
of) this application's output in /var/log/daemon.log.
But the above explains why.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]