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
- 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.
- 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.