Article Index
Tutorial
Part 1: Tutorial Setup
Part 2: Install Beet
Part 3: Examine the data
Part 4: JMX Administration
Part 4 Continued: Performance Statistics
Part 5: Log analysis with beet-util
Following Up
All Pages

This is a multi-part tutorial, which will take you through:

  1. Installing beet in an existing Spring web application.
  2. Administering beet from a JMX console
  3. Processing beet logs with the beet-utils command line package

For this tutorial we assume:

  1. You already have a working instance of the Java 6 SDK installed
  2. You have administrative privileges on your system, such that you can install and run server software
  3. You are familiar with Java-based web application development in general (Servlet 2.4 and up), and Spring-based applications in particular (Spring 2 and up).
  4. You are comfortable with Java 5+ language features and SDK tools.
The User Guide (available at http://beet.sourceforge.net and in any beet release package) contains full instructions for configuring beet, with many options, details, and examples not covered here.  This document will take you through the installation on a very simple application before you decide to dive in on your own.

Part 1:  Tutorial Setup

Before we get to installing beet, we first need a target Spring application.  We have a simple 3-tier "hello-world" style web application built on of the following components:

  • JSP 2.0 pages for the view
  • Spring WebMVC 2.5.6 for the controller
  • Spring 2.5.6 for the middle tier
  • Hibernate 3.2 for data access
  • HSQLDB 1.8 for our in-memory SQL data store

The tutorial involves installing this application in a clean Tomcat 6 server, verifying that it works, and then adding beet.

Step 1: Install Tomcat 6

Tomcat 6 is available for download here.  For the purposes of this tutorial, all you need to do is download one of the Tomcat archives (at time of this writing, apache-tomcat-6.0.18.zip or .tar.gz) and unpack it. From here forward we'll refer to the directory where you unpacked the archive as [TOMCAT].

To verify your installation, start the server by executing [TOMCAT]/bin/startup.bat (Windows) or [TOMCAT]/bin/startup.sh (*nix).  Point your browser at http://localhost:8080/ and you should see a default index page for your server.

Stop your server by executing [TOMCAT]/bin/shutdown before proceeding.

Step 2: Install the tutorial app

Download beet-hello.war. Copy it into the [TOMCAT]/webapps directory.  Start the Tomcat server.

Verify the installation by pointing your browser at http://localhost:8080/beet-hello.  You should see a page that looks like this:

beet-hello front page

Take a minute to familiarize yourself with the app (there's only one page):

  1. Click the 'create' button to insert some data.
  2. Click a few 'delete' buttons to remove some of the rows.
  3. Enter text into the two form fields at the bottom of the page, and click the 'update' button.
  4. Click the 'clear' button to clear all data.

Stop the Tomcat server before proceeding.


Part 2:  Install Beet

Installation is basically two steps:  dropping in the libraries, and minor edits to the Spring configuration.  We'll break the latter part down into very small steps for clarity.

Step 1:  Add beet and dependencies to the application's lib directory

Download a beet release package from SourceForge.  This tutorial requires 1.4 RC1 or higher.  Unpack the archive.  This will create a package directory called beet-[version]/.

From the beet package directory, copy the file beet-core.jar and all of the jars from lib/ into the [TOMCAT]/webapps/beet-hello/WEB-INF/lib.

Step 2:  Activate HTTP request behavior tracking

Open the file [TOMCAT]/webapps/beet-hello/WEB-INF/beet-hello-servlet.xml in your favorite text or XML document editor.  You should see something that starts like this:

<beans xmlns="http://www.springframework.org/schema/beans" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemalocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">

<!-- BEGIN APPLICATION LAYER BEANS -->
<bean class="org.springframework.beans.factory.annotation.RequiredAnnotationBeanPostProcessor"></bean>

<!-- dao layer -->
<bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource">
... snip ...

Add the highlighted code as below:

<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:bt="http://beet.sourceforge.net/schema/bt/1.1"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://beet.sourceforge.net/schema/bt/1.1 http://beet.sourceforge.net/schema/bt/mtgi-bt-1.1.xsd">

<bt:manager application="beet-hello">
<bt:http-requests parameters="command"/>
</bt:manager>

... snip ...

We've now configured HTTP request tracking.  This wouldn't be terribly useful in itself (you already get access logging with Tomcat), so

Step 2:  Activate Java Method call tracking

For this we just have to add the track-method-expression attribute to bt:manager:

 <beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:bt="http://beet.sourceforge.net/schema/bt/1.1"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://beet.sourceforge.net/schema/bt/1.1 http://beet.sourceforge.net/schema/bt/mtgi-bt-1.1.xsd">

<bt:manager application="beet-hello"
track-method-expression="execution(* com.mtgi.analytics.example.service..*(..))">
<bt:http-requests parameters="command"/>
</bt:manager>

This expression identifies "all methods of all classes in the com.mtgi.analytics.example.service package".  So now for each HTTP request, we'll know how much processing time was used executing methods in this package.  To get more detail, 

Step 3:  Activate JDBC Statement tracking

We add the bt:tracking-manager attribute to any data source we want to track:

<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:bt="http://beet.sourceforge.net/schema/bt/1.1"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://beet.sourceforge.net/schema/bt/1.1 http://beet.sourceforge.net/schema/bt/mtgi-bt-1.1.xsd">

<bt:manager application="beet-hello"
track-method-expression="execution(* com.mtgi.analytics.example.service..*(..))">
<bt:http-requests parameters="command"/>
</bt:manager>

<!-- BEGIN APPLICATION LAYER BEANS -->
<bean class="org.springframework.beans.factory.annotation.RequiredAnnotationBeanPostProcessor"/>

<!-- dao layer -->
<bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource"
bt:tracking-manager="defaultTrackingManager">
<property name="dataSourceName" value="helloData"/>
<property name="driverClass" value="org.hsqldb.jdbcDriver"/>
<property name="jdbcUrl" value="jdbc:hsqldb:mem:helloData"/>
<property name="maxPoolSize" value="2"/>
<property name="maxIdleTime" value="30"/>
</bean>

In our application we are using a c3p0 connection-pooling DataSource, but any implementation of javax.sql.DataSource can use the bt:tracking-manager attribute.

At this point we've added the monitoring we want (HTTP, methods, SQL), but we'll make a few final adjustments so that the log output is easy to read:

Step 4: Plain text logging in the [TOMCAT]/logs directory

The default binary log format is good for production, but for our tutorial we'll switch to plain text XML logging, and put the log in a sensible location relative to the Tomcat install.

<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:bt="http://beet.sourceforge.net/schema/bt/1.1"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://beet.sourceforge.net/schema/bt/1.1 http://beet.sourceforge.net/schema/bt/mtgi-bt-1.1.xsd">

<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"/>

<bt:manager application="beet-hello" flush-schedule="0/30 * * * * ?"
track-method-expression="execution(* com.mtgi.analytics.example.service..*(..))">
<bt:xml-persister binary="false" compress="false" file="${catalina.home}/logs/beet-hello-perf.xml"/>
<bt:http-requests parameters="command"/>
</bt:manager>

The Spring utility class PropertyPlaceHolderConfigurer lets us use system properties like ${catalina.home} to locate the Tomcat root directory.

The flush-schedule attribute is a cron expression that schedules beet log flushes every 30 seconds; the default of 5 minutes is good for production but a little inconvenient for our tutorial. 

Finally, bt:xml-persister switches off binary XML and compression, so our log will be plain old UTF8 XML, and specifies an easy-to-locate log file location of [TOMCAT]/logs/beet-hello-perf.xml.


Part 3: Examine the data

Start your Tomcat server back up.  Wait about 30 seconds to 1 minute, and then open up [TOMCAT]/logs/beet-hello-perf.xml.  You should already see some data (formatted here for legibility):

<event id="6dc8bd6c-c63c-4ecc-803c-9a1bc7dcf4c7"><type>jdbc</type><name>executeUpdate</name>
<application>beet-hello</application><start>2009-04-23T12:40:03.547-07:00</start><duration-ns>0</duration-ns>
<event-data><sql>drop table HelloData if exists</sql></event-data>
</event>
<event id="a3085baf-49a0-4a5b-90c1-d210e4524786"><type>jdbc</type><name>executeUpdate</name>
<application>beet-hello</application><start>2009-04-23T12:40:03.547-07:00</start><duration-ns>0</duration-ns>
<event-data><sql>create table HelloData (id bigint generated by default as identity (start with 1), AField varchar(255), anotherField varchar(255), primary key (id))</sql></event-data>
</event>

We're using the Hibernate "schema create" feature to create our backend database at system startup.  Hibernate used the Spring dataSource bean for data access, so those statements were logged.

Point your browser again at http://localhost:8080/beet-hello. As before, click 'create', delete some records, add some records.  Wait at least another 30 seconds, and revisit the beet log.  It should have a host of new data.   Here's some data for a single press of the 'delete' button, again formatted for legibility:

<event id="244f5f4e-21d0-4044-b71f-ba39bb96cfbd" parent-id="778e4a40-48a8-4386-b93c-72e322663a90">
<type>jdbc</type><name>executeBatch</name><application>beet-hello</application>
<start>2009-04-23T13:50:37.625-07:00</start><duration-ns>0</duration-ns>
<session-id>53FAB2406DB3CFAE8BD4201D6DD60D73</session-id>
<event-data><sql>delete from HelloData where id=?</sql>
<batch><parameters><param>1</param></parameters></batch>
</event-data>
</event>
<event id="778e4a40-48a8-4386-b93c-72e322663a90" parent-id="9d2f5856-193f-4fe7-a7d5-51b5a355e4cf">
<type>method</type><name>com.mtgi.analytics.example.service.HelloService.delete</name><application>beet-hello</application>
<start>2009-04-23T13:50:37.531-07:00</start><duration-ns>109</duration-ns>
<session-id>53FAB2406DB3CFAE8BD4201D6DD60D73</session-id>
<event-data><parameters><param>{object}</param></parameters><result/></event-data>
</event>
<event id="a80fa0c7-5902-4905-a785-8a7420d98b67" parent-id="607e7fb6-6c11-4c54-ae25-a2aac1ab9336">
<type>jdbc</type><name>executeQuery</name><application>beet-hello</application>
<start>2009-04-23T13:50:37.640-07:00</start><duration-ns>0</duration-ns>
<session-id>53FAB2406DB3CFAE8BD4201D6DD60D73</session-id>
<event-data><sql>select hellodata0_.id as id0_, hellodata0_.AField as AField0_, hellodata0_.anotherField as anotherF3_0_ from HelloData hellodata0_ order by hellodata0_.id</sql></event-data>
</event>
<event id="607e7fb6-6c11-4c54-ae25-a2aac1ab9336" parent-id="9d2f5856-193f-4fe7-a7d5-51b5a355e4cf">
<type>method</type><name>com.mtgi.analytics.example.service.HelloService.list</name><application>beet-hello</application>
<start>2009-04-23T13:50:37.640-07:00</start><duration-ns>0</duration-ns>
<session-id>53FAB2406DB3CFAE8BD4201D6DD60D73</session-id>
<event-data><parameters><param>id</param></parameters>
<result type="java.util.ArrayList">{object}</result></event-data>
</event>
<event id="9d2f5856-193f-4fe7-a7d5-51b5a355e4cf">
<type>http-request</type><name>/beet-hello/</name><application>beet-hello</application>
<start>2009-04-23T13:50:37.515-07:00</start><duration-ns>157</duration-ns>
<event-data uri="/beet-hello/" protocol="HTTP/1.1" method="POST" remote-address="127.0.0.1" remote-host="127.0.0.1">
<parameters><param name="command"><value>delete</value></param></parameters>
</event-data>
</event>

A few things are worth calling out:

  1. Each event has a globally unique ID (the "id" attribute), and if it is a nested event, a parent ID. 

    For example, the first event is the SQL statement "delete from HelloData where id=?" with parent-id="778e4a40-48a8-4386-b93c-72e322663a90".  Further down the log we can find the parent event, which was the method call "com.mtgi.analytics.example.service.HelloService.delete".

  2. Events are persisted in the order in which they are completed, so child events appear before parent events.  Therefore the root of all these events, the "http-request" event with name "/beet-hello/", appears at the bottom of the log snippet.

  3. Each event is identified by type, name, and application.  All of our events are in the "beet-hello" application.  We have three types of events, "method", "jdbc", and "http-request".  The meaning of name depends on type. 
    1. The name for "method" events is "package.class.methodName". 
    2. The name for "http-request" events is "/context-relative-uri". 
    3. The name for "jdbc" events is the JDBC Statement method used to execute the SQL, e.g. "executeBatch", "executeQuery", etc.  The actual SQL statement can be found in the nested <event-data> element.

Part 4:  JMX Administration

Beet provides some basic diagnostic information to any JMX console.  For this tutorial we'll be using jconsole, which comes standard with any Java 6 SDK installation.

Step 1:  Enable JMX on your Tomcat server

We will configure your Tomcat server for unauthenticated JMX access.  Never do this on a production system!  For obvious reasons it is a huge security risk.  When you want to enable JMX on your production server, read both the Tomcat monitoring instructions and Sun's administration guide to protect against unauthorized access.  On to business:

Stop your server if it is running.  Open your [TOMCAT]/bin/startup script in a text editor, and insert the following text near the top:

Windows users:

set JAVA_OPTS=-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=12345 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false 

*nix users:

JAVA_OPTS=-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=12345 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false 

Step 2:  Activate Beet's JMX support

Once again open our spring configuration file beet-hello-servlet.xml in a text editor, and add the register-mbeans attribute to <bt:manager>:

<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:bt="http://beet.sourceforge.net/schema/bt/1.1"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://beet.sourceforge.net/schema/bt/1.1 http://beet.sourceforge.net/schema/bt/mtgi-bt-1.1.xsd">

<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"/>

<bt:manager application="beet-hello" register-mbeans="true" flush-schedule="0/30 * * * * ?"
track-method-expression="execution(* com.mtgi.analytics.example.service..*(..))">
<bt:xml-persister binary="false" compress="false" file="${catalina.home}/logs/beet-hello-perf.xml"/>
<bt:http-requests parameters="command"/>
</bt:manager>
This is a shorthand way to export Beet's MBeans using Spring's powerful JMX support.  You can alternatively use standard Spring JMX MBean detection if you want more control over how the MBeans are registered.  See the Spring User Guide for more detailed information about how this works.

Step 3:  Connect with jconsole

Start your Tomcat server.  Once it is up and running, fire up a jconsole process.  jconsole is usually located in [JAVA SDK HOME]/bin/jconsole.  You should see something that looks like this:

jconsole login screen

Select the Remote Process radio button.  Enter localhost:12345 in the first text field.  Do not enter anything for username or password; click Connect.  Once connected to your server, select the MBeans tab.  Expand the tree nodes for beet-hello, com.mtgi.analytics, and then defaultTrackingManager.  You should see something like this:

jconsole mbeans tree

The BeetManager bean can be used to

  • resume or suspend beet monitoring (via the resume and suspend operations),
  • see how many unlogged events are in memory (via the EventsPendingFlush attribute), and optionally
  • flush these events to the log via the flush operation.

The BeetLog bean can be used to

  • View the size of the current log file via the FileSize attribute
  • View and change the log compression and format settings via the Binary and Compress attributes
  • Force an ahead-of-schedule log rotation view that rotateLog operation.

Part 5 of the tutorial will use some of these controls to change the logging format.  Before that, we'll explore monitoring your application's performance from a JMX console.


Part 4 Continued:  Performance Statistics in JConsole

Step 1:  Enable Statistics MBeans

Once again stop your Tomcat server. Open beet-hello-servlet.xml for editing:

<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:bt="http://beet.sourceforge.net/schema/bt/1.1"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://beet.sourceforge.net/schema/bt/1.1 http://beet.sourceforge.net/schema/bt/mtgi-bt-1.1.xsd">

<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"/>

<bt:manager application="beet-hello" register-mbeans="true" flush-schedule="0/30 * * * * ?"
track-method-expression="execution(* com.mtgi.analytics.example.service..*(..))">
<bt:persister-chain>
<bt:xml-persister binary="false" compress="false" file="${catalina.home}/logs/beet-hello-perf.xml"/>
<bt:mbean-persister/>
</bt:persister-chain>
<bt:http-requests parameters="command"/>
</bt:manager>

We've done two things:

  1. <bt:persister-chain> allows us to send behavior events to multiple persister instances.  So we're still writing to the XML log, but we're also sending event data to a new persister type:
  2. <bt:mbean-persister> aggregates event statistics in MBeans so that you can monitor your application from a JMX client. 

Step 2:  Use the application

Start the Tomcat server.  As before, point your browser at http://localhost:8080/beet-hello and create some data in the test application.

Step 3:  Examine Statistics in JConsole

When you navigate to our beet-hello domain in JConsole, you'll see there are some new MBeans available:

Statistics MBeans in JConsole

The attributes of the /beet-hello/ MBean describe aggregate performance statistics for requests against that URI.  But more significantly, we can drill down into Java method calls invoked during request processing, and further into JDBC SQL statements executed during those methods.

You'll notice that /beet-hello is rather coarse-grained; our application has several discrete actions (create, delete, update, clear) but only one URI provides all of them.  We'll refine our event tracking to group events according to key request parameter values.

Step 4:  Refine event groupings

Stop your server and edit beet-hello-servlet.xml:

<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:bt="http://beet.sourceforge.net/schema/bt/1.1"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://beet.sourceforge.net/schema/bt/1.1 http://beet.sourceforge.net/schema/bt/mtgi-bt-1.1.xsd">

<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"/>

<bt:manager application="beet-hello" register-mbeans="true" flush-schedule="0/30 * * * * ?"
track-method-expression="execution(* com.mtgi.analytics.example.service..*(..))">
<bt:persister-chain>
<bt:xml-persister binary="false" compress="false" file="${catalina.home}/logs/beet-hello-perf.xml"/>
<bt:mbean-persister/>
</bt:persister-chain>
<bt:http-requests name-parameters="command" uri-pattern="/beet-hello/?" />
</bt:manager>

Now after interacting with your application and viewing the results in JConsole, things are a little different:

Refined Statistics MBeans

The name-parameters attribute allowed us to divide events based on the value of the "command" parameter, an HTTP post parameter identifying the action taken by the user on each request.  For more complicated applications we could add more parameters here, separated by commas.

The uri-pattern attribute is a regular expression identifying which requests interest us.  This filtered out statistics for static resources like png images and CSS files.  You can specify multiple uri-patterns as nested elements, see the User's Guide for more information.


Part 5:  Log analysis with beet-utils

The beet-utils command line utilities are primarily for the default compressed binary log format. Thus far in the tutorial we've been working with plain text logging, so first we'll use the JMX console to switch back to the default behavior.

For this tutorial we assume you have the command line utility zcat installed on your system.  For Windows users this means Cygwin or a similar *nix-like utilities package.  If you don't have zcat, you can still try the tutorial, but skip the part in Step 2 that tells you to enable Compression.

Step 1:  Verify beet-utils setup

Open your favorite command interpreter (e.g. Cygwin or cmd on Windows, xterm on *nix) and change into your beet installation directory.  Test the installation by running "java -jar beet-utils.jar".  You should see a terse usage message:

beet utils usage message

Leave the terminal window open.

Step 2:  Use jconsole to change logging format

Connect to Tomcat with jconsole and examine the beet-hello/com.mtgi.analytics/defaultTrackingManager/BeetLog mbean as described in Part 4 of the tutorial.  Select the Attributes node under BeetLog and change both Binary and Compress attributes to true:

beet log settings in jconsole

Since we're changing the log format, these changes only take effect after the next log rotation.  By default this happens every night at midnight.  If you are like me and doing this tutorial late at night, you can wait.  Otherwise, select the Operations node under BeetLog:

beet log operations in jconsole

Click the rotateLog button; you should see a window indicating the name of the newly archived log file.

beet rotateLog result

Use a filesystem browser to examine the [TOMCAT]\logs directory.  You should see both the newly archived log file (named like beet-hello-perf.xml.TIMESTAMP), and the new current log file, beet-hello-perf.bxml.gz.  The file extension has been changed to .bxml.gz to reflect the new format.

Step 3:  Click around beet-hello

Once again point your browser at http://localhost:8080/beet-hello. Click around on create, delete, update, clear buttons.  Let the app know that you are there.

Step 4:  Use jconsole to flush any in-memory events

Back in jconsole, select the Operations node under beet-hello/com.mtgi.analytics/defaultTrackingManager/BeetManager.  Click the flush button to force any accumulated events to be written to the log. 

BeetManager operations in jconsole

The result window indicates the number of events flushed to the log.  Because early in the tutorial we configured our flush interval very low (30 seconds), this will likely be 0, unless your window-changing and mouse-clicking skills are unusually well-honed.

Again use the BeetLog.rotateLog operation to rotate our log.  This should create a new log named beet-hello-perf.bxml.gz.[TIMESTAMP] to use in the following steps. 

Step 5:  Convert the current log to other formats

Back in your command prompt window, you can convert the log to various formats using the beet-utils jar.  Try the following commands:

> zcat [TOMCAT]/logs/beet-hello-perf.bxml.gz.[TIMESTAMP] | java -jar beet-utils.jar -tool xml

> zcat [TOMCAT]/logs/beet-hello-perf.bxml.gz.[TIMESTAMP] | java -jar beet-utils.jar -tool csv

> zcat [TOMCAT]/logs/beet-hello-perf.bxml.gz.[TIMESTAMP] | java -jar beet-utils.jar -tool xslt -format text -split event -xsl sql/etl/insert-events.xsl

Where of course you should replace [TOMCAT] with your Tomcat install directory, [TIMESTAMP] with the actual file extension, and use '\' instead of '/' if you are a Windows user.  The last example, which applies a custom XSLT stylesheet to the event data, is a powerful way to customize event log processing.  The provided XSL produces the same output as the '-tool csv' variant, but you can obviously customize its behavior.


Following Up

You now have a basic understanding of how to install beet, control its behavior, and work with the default logging formats.  Some activities not covered in this tutorial that you can pursue with the User Guide:

  • persist events directly to a relational database instead of log files
  • efficiently bulk load log file data to an Oracle database
  • filter http-request logging by URI
  • change log rotation and flush schedules
  • control thread pool and schedule implementations used by beet
  • integrate event logging with your custom authentication methods

The following reference materials are also likely to be useful to you:

  • The Spring User Guide for more information about configuring Spring beans, Spring JMX and AOP support, and authoring your own Spring configuration tags (like <bt:manager>)
  • The Tomcat Manual for insight into administering a production Tomcat server, though often Google helps about as much
  • Sun's jconsole documentation
Good luck.