Improve Events API

The Dev Story :
=========

Messages :
---------------
I want to easily send a message into the Nuxeo message bus.
For creating a message, I want to have only one class envelop (not 3!).
This message should be able to store :

• automatically set
• user
• date
• set manually
• an event id
• an optional source document location (repo/ref)
• an optional comment
• customizable
• a HashMap

Producing :
--------------
Message producing should be transactionnal when possible (JMS):
=> if I produce a message in a method that fails and make the transaction rollback , the message should not be sent
(true for a deployement in JEE container)

Message producer should be a simple static helper.

It should be easy to use this producer to send my message on a custom Topic or on a custom Queue.

Audit :
--------
These messages should be easily pluggable into Audit system (see XXX).

Listening to events :
--------------------------
For async listeners, I would like to be able to reuse a base class that does the dirty work :

• plug into JMS to get the message
• opens a JAAS session
• opens a JTA transaction if needed
• open a CoreSession

This base class should be avalaible in 2 flavors :

• MDB base class
• plain JMS Listener base class

Core Events :
-----------------
CoreEvents should be bridged to JMS.
This bridge should :

• be transactional : don't send me event tied to uncomited documents
• remove duplicated messages withing a given transaction: create + modify + modify = create

Design notes :
========

MDB, JMS and clustering :
---------------------------------
Current, async message processing in handled by dedicated MDB.
We should probably only have one MDB that dispatch events to Nuxeo Event Handlers :l

• this would make deployment in non JEE/JMS environment possible
• this would allow to easily handle custering for MDB (ie : desactivate one note for example)

Sync vs Async :
--------------------
We should have only 2 types of handlers :

• onEvent :
• always synchonous
• can interact with currently modified doc
  = current CoreListener model
• onEventAfter :
• sync or async depending on deployment options
• triggered after commit
  = current MDB/JMS model