Beet records user behavior and performance data for your Spring-based Java application.  It can thus help you to analyze usage patterns and research production performance issues.  Beet requires Spring Framework 2.0 or 2.5.

Visit the Downloads page to grab a copy, take the tutorial, and/or read the Quick Start chapter of the User Guide to enable it in your application.

Beet is freely available to use under the terms of the Mozilla Public License, v1.1.  It was originally developed and contributed to the open source community by Mantis Technology Group, Inc.

Features

  • Record Java method calls, SQL statements, and HTTP requests, or add your own events
  • Simple configuration, zero code modification required
  • Know immediately which user and session caused each event and when
  • JMX performance tracking and administration
  • Record data as XML, compressed binary XML, directly to an RDBMS, or write your own storage
  • Flexible ETL and log manipulation tools for compressed binary XML
  • Low resource overhead, appropriate for production systems


News

Spring 3.0 Compatibility Issues


A few people have written asking about and/or requesting Spring 3.0 compatibility.  There is at least one known issue, being that the <bt:jdbc-persister> tag generates errors during config parsing, there is a defect report that is tracking the issue.  However, <bt:xml-persister> and other config tags have been reported to work.  Spring 3.0 has not been extensively regression tested with beet, so this may not be the only issue you encounter.  However, it is the only issue reported so far.

"Official" 3.0 support will not be a feature of 1.4.0, however it will be the first priority for 1.4.1.  Fortunately, it sounds like it is possible to use beet with Spring 3.0, you will just need some workarounds.  The workaround for the <bt:jdbc-persister> bug is to not use the <bt:jdbc-persister> tag, but create an equivalent <bean> definition like so:

<bt:manager application="testTracking"
track-method-expression="execution(* com.mtgi.analytics.aop..*Tracked(..))"
persister="jdbcPersister">
</bt:manager>

<bean id="jdbcPersister" class="com.mtgi.analytics.JdbcBehaviorEventPersisterImpl">
    <property name="dataSource" ref="myDataSource"/>
</bean>

That's more-or-less what the <bt:jdbc-persister> tag is really doing under the hood anyway.

1.4.0 RC1 released!

It's been a long wait, but RC1 is finally available for download.  If no major problems are found, this will be blessed as 1.4.0.

The major difference between RC1 and the betas is in packaging.  You no longer need two downloads (core and utils) to make beet useful; all components are packaged together.  Check out our Downloads page or visit the SourceForge downloads area to grab yourself a copy.  I'll be watching the forums closely for any issues, so don't be shy with reports.

There are a few minor bugfixes and enhancements since the last beta:

Enhancements:

  • beet-core 2810502: record times with nanosecond accuracy
  • beet-core 2794524: bt:manager/enabled attribute, so that tracking can be toggled in an external properies file
  • beet-core 2794532: beet-web.jar added to distribution, for easier EAR deployments
  • beet-core 2794532: maven repository has sources and javadocs

Bugfixes:

  • beet-core 2832049: deploy latest XSD to project site, fix schema URI inconsistencies
  • beet-core 2824858: fix runtime compatibility with spring-test
  • beet-core 2790194: batch event ID lookup, to improve JDBC persister performance
  • beet-core 2806458: fix runtime compatibility with spring-security 2.0

 

beet in the wild

Wanted to drop a quick pointer to Jettro's thoughtful blog post on our humble framework.  He really understands what we're trying to do here, and has identified a few issues that will be resolved for RC1.

On the subject of RC1, it's obviously behind schedule.  Not for nothing, though; this past weekend saw many developments on the build front which should help get us there.  More to come; browse our issue tracker to get a sense for what remains to be done.

happy new year

and new decade too.  We're still kicking, testing the long, long delayed RC1.

The major difference between beta3 and rc1 is in packaging.  The previous packaging model, in which beet-core and beet-utils were separate distributions, was too complicated; two distributions, two platforms, three archive formats created a wall of files on the download site.  And really, neither package was much use without the other.  I've also taken the minor step of renaming the main artifact, beet.jar, to beet-core.jar, for general consistency.  Unfortunately the packaging change has really held up the release process, since there's a lot of regression testing to be done in the tutorial and documentation.

If you've got any wishlist items or pet peeves with the way beet is packaged or documented, please swing by the forum and let us know before the door closes on the release.

beet RC1 on its way

Update 05 Jul 2009

All of the originally identified issues for RC1 have been resolved on trunk, though after some discussion one additional issue has been promoted for RC1:

  • issue 2810502:  switch measurement from milliseconds to nanosecond

This will push the RC build at least out into this week.


It's been a long spell without any news (with apologies to pragnesh, who's contributed a great wealth of ideas on our dev forum), but things have been busy over here.  I've joined the EasyAnt project team, with the intent of ultimately replacing our semi-functional Ant/Ivy system with a more robust build.  This is a ways into the future, probably in the 2.0 timeframe for beet.  This week focus has returned to the near-term 1.4.0 release.

We've fixed a couple of issues identified in the last beta, with the following mostly administrative issues needing to be resolved for the release:

  • issue 2794532:  better support for EAR deployments
  • issue 2794528:  source/javadoc artifacts in maven repository
  • issue 2794524:  global "enabled" parameter for easier administrative control of deployments
  • issue 2809943:  fix build ivyrep to use maven naming conventions
Once all of these issues are resolved, we'll make a release candidate build.  If we can survive two weeks in RC status without any critical compatibility or regressions discovered, we'll finally promote the build to release status.