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.