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

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.