Proposal to Deprecate IStatsRecorder

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

• ApplicationEventPublisher

• ApplicationEvent

• ApplicationListener

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

• Use AspectJ to completely decouple event handling aspects from the portal core:

  Initial, brainstorm with the following infrastructure: - Abstract aspect to capture the the event handling protocol - Subaspects for each type of event This will be a true modular and non-intrusive solution completely decoupled from the core. Could even be compiled into a reusable aspect library and applied to the uP core as needed (LTW, etc.) public abstract aspect AbstractPortalEventHandler { abstract pointcut eventBoundary(Object eventSource); after(Object eventSource) : eventBoundary(eventSource) { handleEvent(eventSource); } protected abstract void handleEvent(Object eventSource); } ... and then have subaspects like: public aspect XxxPortalEventHandler extends AbstractPortalEventHandler {...}

   

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.