Difference between revisions of "Jetty/Feature/Jetty Logging"
|Line 1:||Line 1:|
| introduction =
| introduction =
Revision as of 21:01, 11 April 2012
Jetty provides it's own logging mechanism that can work one of 3 modes: 1) Logging to directly to StdErr using org.eclipse.jetty.util.log.StdErrLog ; 2) Logging via Slf4j to any configured Slf4j log; 3) Logging to a custom logger written against the jetty API.
With any logging mode, all logged events have a name and a level. The name is a Fully Qualified Class Name (FQCN). The logging framework you choose determines the level. While the meaning of the levels is pretty much the same across logging frameworks, the descriptive identifiers for those levels are different.
Selecting the Log Framework
If Jetty does not discover an slf4j jar on the classpath, then it will use the internal org.eclipse.jetty.util.log.StdErrLog logger. If an slf4j jar is on the classpath, then slf4j configuration mechanisms are used to select the actual logger used (eg logback, java.util.logging, or log4j,can all be used via slf4j).
The logger used may also be controlled by the system property org.eclipse.jetty.util.log.class, which can be set to the classname of an implementation of the jetty Logger API. For an example of a custom Logger, see http://download.eclipse.org/jetty/stable-7/xref/org/eclipse/jetty/util/log/JavaUtilLog.html
Configuring Jetty StdErrLog
If the default Jetty logger is selected, then further System properties may be used to control what event levels are logged and what is the format of those logs.
|<some.package>.LEVEL=<level>||Sets the logging level for all loggers within the some.package java package to the level, which can be INFO, DEBUG, WARN or NONE. For example, -Dorg.eclipse.jetty.http.LEVEL=DEBUG would turn all loggers in the jetty HTTP package to DEBUG level. If a Logging level is specified by more than one system property, then the most specific one is used.|
|org.eclipse.jetty.util.log.IGNORED=<boolean>||If set to true, then exceptions that have been recorded as ignored with the LOG.ignore(throwable) API will be logged with a full stack trace. Otherwise ignored exceptions are either not logged, or logged in summary if the level is debug.|
|org.eclipse.jetty.util.log.stderr.SOURCE=<boolean>||If set to true, then the source filename and line number of the LOG API call are included in the StdErrLog output|
|org.eclipse.jetty.util.log.stderr.LONG=<boolean>||If set to true, then the long form FQCN is used in the StdErrLog output (defaults to false). Otherwise FQCN are abbreviated to the form oejh.SomeClass instead of org.eclipse.jetty.http.SomeClass.|
|org.eclipse.jetty.util.log.DEBUG, org.eclipse.jetty.util.log.stderr.DEBUG, DEBUG (deprecated)||These are deprecated properties that are ignored with a warning if used.|
Changing log level in etc/jetty.xml
<Get class="org.eclipse.jetty.util.log.Log" name="log"> <Call name="setDebugEnabled"> <Arg type="boolean">true</Arg> </Call> </Get>
You can use etc/jetty-logging.xml to take all System.out and System.err output (from any source) and route it to a rolling log file. To do so, include etc/jetty-logging.xml on Jetty startup.
java -jar start.jar etc/jetty-logging.xml
Request logging (AKA access logging), refers to the logging of each request handled by the server. This is a different logging mechanism and in jetty is provided with an implementation of the well-established NCSA log file format. This log file format is standardized so that other tooling can use the information for other reasons.
To enable access logging with Jetty, include the etc/jetty-requestlog.xml on Jetty startup.