The roadmap sketches out, in broad terms, what is on the horizon for beet development. If you want to suggest additions or indicate priorities, come visit the mailing lists or development forums.
beet 1.4.0 final: Early January
The final release of 1.4.0 was significantly delayed, due mostly to time spent revamping the build system and working through various compatibility issues discovered in beta testing. This has also significantly pushed out planning for 2.0. Fortunately that's behind us now, and we've got our first release candidate available.
During the extended beta testing period for 1.4.0, we've had some code contributions and developments that point naturally to the next minor release. Specifically:
- Spring 3.0 compatibility. Spring 3.0 was released in December. We'll assess what needs to be done (if anything) for compatibility. Note that compatibility will be the goal; taking advantage of major new features in 3.0 will probably be deferred for beet 2.0.
- Tighter spring-security integration. SteveB posted some code in the tracker that provides better integration with Spring security. Some testing and documentation will be added to vet the contribution for the next release.
- Better application control for event data logging. Some discussion on the forum and in the tracker points to a need for applications to customize <event-data> logging (custom representations for method parameters, etc). This will be present, at least rudimentarily, in 1.4.1.
beet 2.0 alpha
Features requested on the development forum are tending toward the high end -- support for tracking transactions across multiple applications, support for EJB3, non-Spring apps, and so on. So we'll branch for 2.0 development soon.
The following features are under consideration for 2.0. Eventually each of these should have an Issue Tracking number where we can find more detailed discussion:
- Support for tracing distributed call chains across multiple applications, multiple threads in the same application
- EJB3 monitor
- Web Service monitor
- Non-Spring / legacy app monitor
- Runtime configuration changes
- Persistent config changes across system restarts
- Improved configuration schema
- keiker integration
- customizable event storage schema
- configurable event data for method calls (store some parameters but not others, etc)
- migrate to EasyAnt-based build
- Multi-language support (esp. Scala, C#)
- Integrated system resource monitors
- Integrated database traces
A key litmus test for any candidate feature design is whether it meets the ergonomic standards for beet. Specifically, all features should be enabled at runtime (not compile-time). We should only need the addition of jars and minimal configuration to enable monitoring. Additionally, configuration should be centralized as much as possible (e.g. appear alongside other beet config in our Spring config file). Obviously these standards are subject to periodic reevaluation, but deployment simplicity is why beet exists.
beet 2.0 final
There's plenty on the roadmap to keep us busy, but we should constrain the scope to allow for a major release in Q4, hopefully early in the quarter. At this point we can evaluate branching for 3.0 or focusing more on minor releases for the 2.0 / 1.0 series.