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

serverId	The server identifier as determined by org.jasig.portal.IPortalInfoProvider.getServerName() generally the host name of the server the portal VM is running on
eventSessionId	A 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
userName	The currently authenticated user's userName
timestamp	The timestamp the event was fired
person	The 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
source	The 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:

Lives in the org.jasig.portal.events package
Extends org.jasig.portal.events.PortalEvent either directly or indirectly
Is either final or abstract
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
All fields must be immutable (declared final and care taken not to return a mutable reference from getters)
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