Skip to content
This repository has been archived by the owner on Dec 10, 2021. It is now read-only.

Latest commit

 

History

History
106 lines (92 loc) · 4.77 KB

README.md

File metadata and controls

106 lines (92 loc) · 4.77 KB

Download

Config Options from: org.apache.catalina.valves.AbstractAccessLogValve

Abstract implementation of the Valve interface that generates a web server access log with the detailed line contents matching a configurable pattern. The syntax of the available patterns is similar to that supported by the Apache HTTP Server mod_log_config module.

Patterns for the logged message may include constant text or any of the following replacement strings, for which the corresponding information from the specified Response is substituted:

  • %a - Remote IP address
  • %A - Local IP address
  • %b - Bytes sent, excluding HTTP headers, or '-' if no bytes were sent
  • %B - Bytes sent, excluding HTTP headers
  • %h - Remote host name (or IP address if enableLookups for the connector is false)
  • %H - Request protocol
  • %l - Remote logical username from identd (always returns '-')
  • %m - Request method
  • %p - Local port
  • %q - Query string (prepended with a '?' if it exists, otherwise an empty string
  • %r - First line of the request
  • %s - HTTP status code of the response
  • %S - User session ID
  • %t - Date and time, in Common Log Format format
  • %t{format} - Date and time, in any format supported by SimpleDateFormat
  • %u - Remote user that was authenticated
  • %U - Requested URL path
  • %v - Local server name
  • %D - Time taken to process the request, in millis
  • %T - Time taken to process the request, in seconds
  • %I - current Request thread name (can compare later with stacktraces)

In addition, the caller can specify one of the following aliases for commonly utilized patterns:

  • common - %h %l %u %t "%r" %s %b
  • combined - %h %l %u %t "%r" %s %b "%{Referer}i" "%{User-Agent}i"

There is also support to write information from the cookie, incoming header, the Session or something else in the ServletRequest.
It is modeled after the Apache HTTP Server log configuration syntax:

  • %{xxx}i for incoming headers
  • %{xxx}o for outgoing response headers
  • %{xxx}c for a specific cookie
  • %{xxx}r xxx is an attribute in the ServletRequest
  • %{xxx}s xxx is an attribute in the HttpSession
  • %{xxx}t xxx is an enhanced SimpleDateFormat pattern (see Configuration Reference document for details on supported time patterns)

Conditional logging is also supported. This can be done with the conditionUnless and conditionIf properties. If the value returned from ServletRequest.getAttribute(conditionUnless) yields a non-null value, the logging will be skipped. If the value returned from ServletRequest.getAttribute(conditionIf) yields the null value, the logging will be skipped. The condition attribute is synonym for conditionUnless and is provided for backwards compatibility.

For extended attributes coming from a getAttribute() call, it is you responsibility to ensure there are no newline or control characters.

<Host name="localhost"
                 appBase="webapps"
                 unpackWARs="true"
                 autoDeploy="false">
               <Valve className="de.is24.tomcat.StdoutAccessLogValve"
                      pattern="%h %l %u %t &quot;%r&quot; %s %b"/>
</Host>

Build Status

Howto Release

Lets make a release. For this, we use the maven release plugin from our local dev box.

Make sure you are caught up with #master branch (git fetch/pull). Run mvn release:clean and mvn clean. Now, run the maven release:

mvn release:prepare

This will bump our version in the pom, removing -SNAPSHOT, tag it with the version we say to (use the default, so the regex in travis matches), push commits/tags, and then bump the version and add -SNAPSHOT, making a final commit so the latest version is in git.

Ultimately travis sees this tag, and our after_success tests pass, and a ‘mvn deploy’ occurs, which, with the settings.xml, sends the artifacts into Travis at our repo and package we set up.

After every release you run, do a local mvn release:clean, and git fetch/pull.