Portal Events

uPortal builds on the Spring ApplicationEvent API for internal eventing of actions within the portal. Events can be listened for by any Spring managed bean in uPortal which implements the ApplicationListener interface.

PortalEvent Data Model

The PortalEvent object extends Spring's ApplicationEvent adding the following base set of data shared by all portal events

serverIdThe server identifier as determined by org.jasig.portal.IPortalInfoProvider.getServerName() generally the host name of the server the portal VM is running on
eventSessionIdA compound token that is unique to each user's session with the portal, can be used to track events for a single user's session lifetime
userNameThe currently authenticated user's userName
timestamp

The timestamp the event was fired

personThe IPerson object of the currently authenticated user. NOTE: This field is only available on freshly fired events, it will be null for events retrieved from the persistent store
sourceThe source that fired the event. NOTE: This field is only available on freshly fired events, it will be null for events retrieved from the persistent store

Adding Portal Events

uPortal event requirements:

  1. Lives in the org.jasig.portal.events package
  2. Extends org.jasig.portal.events.PortalEvent either directly or indirectly
  3. Is either final or abstract
  4. Provides two constructors
    1. A no-argument constructor which is only used when the event is loaded from the persistent store. If the event is finalthis constructor should be private, otherwise if the event is abstract the constructor should be package-private.
    2. A package-private constructor which takes all arguments needed to fulfill the parent event's constructor and populate all additional fields
  5. All fields must be immutable (declared final and care taken not to return a mutable reference from getters)
  6. Any field that can't be handled by Jackson without extra work needs to be appropriately annotated. New events should be added to the JacksonPortalEventTest to verify their Jackson serialization compatibility

Check out other events for examples of toString implementations, each object in the PortalEvent hierarchy should simply append its fields to the parent's toString and final events should append a final "]"

Portal Event Dispatching

To simplify the work in gathering the common data required to create a PortalEvent the IPortalEventFactory interface defines APIs for publishing each type of event. As new events are added new methods should be added to this interface to publish each even type.

PortalEvent Persistence

As a method of gathering statistics about the portal and serving as an audit log uPortal comes with a service that stores all PortalEvents to a database. Events within a uPortal instance are queued and asynchronously flushed to the database once per second.

 

Additional References

 

Having problems with these instructions?

Please send us feedback at uportal-user@lists.ja-sig.org

Add Feedback content box here.....