Warning
This is currently in DRAFT status
Abstract
This document proposes a moderate improvement to the uPortal 2 codebase in that it recommends the deprecation of the IStatsRecorder interface (and its default implementations) and replacement with a much more flexible system based on the Spring ApplicationEventPublisher and Event Listeners.
Classes and Interfaces to be familiar with:
Spring Classes
Known Issues with Current IStatsRecorder
As implemented, the current IStatsRecorder interface has numerous limitations which decrease its usefulness.
- Hard-coded event types - The IStatsRecorder interface identifies several different types of stats (I'll call them "events" to be more general). However, these are the only events that the IStatsRecorder interface can handle. Identifying a new (potentially local event) requires changes to the IStatsRecorder interface.
- Hard-coded event parameters - The IStatsRecorder interface also denotes which parameters are passed with a recorded event. Since this is hard-coded, adding new parameters again requires modifications to the interface.
- Code duplication - Because events are implemented as methods on the IStatsRecorder interface, this limits the code sharing that can occur for recording stats.
- Required to "handle" all events - Even if you're not interested in an event, you're required to at least acknowledge its existance by generating a stub method.
Incremental Improvements offered by this Patch
- Only required to handle events you wish to handle -only register an "EventHandler" for an event you wish to do something about
- Easily "handle" an event in multiple ways by plugging in one or more EventHandlers for an event
- Easil add new events to handle by publishing a new event (i.e. create Portlet Events which the traditional IStatsRecorder doesn't handle)
- The events to handle becomes a configuration issue rather than a code issue
- Moves "plumbing" code into Spring configuration files
- Allows you to easily leverage Spring components in events handling (i.e. access to Spring managed objects, datasources, etc.)
Possible Issues with New Approach
- Generation of more objects (the number of objects is still pretty small)
Future Potential Improvements
- Removal of "EventsPublishing" from uPortal core code base and into AOP advices as EventsPublishing is a cross-cutting concern
What's Currently Included in the Patch
- Modifications to core code base to call Spring Events Publisher instead of StatsRecorder
- Addition of EventListener to capture PortalEvents
- All StatsRecorder methods have been mapped to appropriate PortalEvent
- ThreadedEventListener to mimic ThreadPool StatsRecorder
- SimpleEventListener for when threads are not needed (probably most cases)
- IStatsRecorderEventHandlerAdapter to convert a current StatsRecorder implementation to be used with the new system
- LoggingEventHandler to mimic behavior of LoggingStatsRecorder
- PrintingEventHandler to mimic behavior of PrintingStatsRecorder
NOTE: This patch was created from HEAD a couple of weeks ago. Its also slightly overzealous in its removal of classes that would probably most benefit from deprecation.