Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

...

Event Logging Configuration

TODO:

  • how to enable the logger
  • how to configure which events are logged

The default uPortal configuration has the database event logger disabled. To enable it two files need to be edited.

  1. In uportal-impl/src/main/resources/properties/contexts/statsContext.xml uncomment the <ref bean="queueingEventHandler"/> reference in the portalEventMulticaster bean then scroll down and un-comment the entire bottom section in the file. There are specific instructions for doing so in the file.
  2. In uportal-impl/src/main/resources/properties/contexts/schedulerContext.xml uncomment the <ref bean="statsQueueFlushingTask"/> reference in the timerFactory bean then scroll down and un-comment the statsQueueFlushingTask bean.

To configure which events are logged refer to the JavaDocs for the AbstractLimitedSupportEventHandler. The QueueingEventHandler which sits in front of the persisting bean extends AbstractLimitedSupportEventHandler to event filtering can be configured there.

The QueueingEventHandler is used to batch the persist action for better performance and to reduce database IO. The default configuration is to only store events when there are at least 50 in the queue or every 60 seconds, whichever comes first. This configuration should not need to be changed.

Database Tables

The following tables are used to log portal event information.

...

The Hibernate entity mappings for the logged PortalEvents is done in the file uportal-impl/src/main/resources/properties/db/stats/portalEvents.hbm.xml. If you add a new PortalEvent implementation that should be logged to the database it needs to be mapped correctly in this file. Unmapped PortalEvents are ignored by the database logging code.

Reading Events

The Hibernate entity mappings and PortalEvent classes are not designed to be read from the database using Hibernate, only to be a logging facility. Any reporting tools should just use straight SQL as doing large reporting tasks via ORM is not easy and the PortalEvent object model is not designed for such use.