On Nov 24, 2011, at 4:06 PM, Denis Gervalle wrote:
On Thu, Nov 24, 2011 at 13:58, Vincent Massol
<vincent(a)massol.net> wrote:
Hi devs,
Summary:
========
I'd like to add the notion of Priority to Event Listeners. The reason is
that in some cases it's important that some listeners execute before others.
The problem at hand:
=================
Here's a typical use case: When receiving the ApplicationStartedEvent, we
have lot of code that needs to initialize. Initialization order is
important (you can compare it to run levels in OS): for example some init
must happen after the Database initialization has happened.
Note that another solution exists for this use case: some initializations
could introduce their own events (such as a DatabaseStartedEvent) and other
init could listen on those events instead of the generic
ApplicationStartedEvent. However I can see several drawbacks to this:
* it's less generic than the priority solution
* it means creating more events
* but more importantly it means that modules will have strong dependencies
(at maven level) on each other whereas it's not necessary and shouldn't be
the case. In our example use case: it means that inits that must happen
after database is started will need to depend on oldcore (which is where DB
is started ATM)
Proposal:
========
* Don't break backward compat in Observation module
* Introduce a PrioritizedEventListener interface that adds a getPriority()
method
* Modify ObservationManager implementation to take into account priorities
* In order to make it simple I propose to have only a single priority per
Listener and not a priority per event supported by a given listener
General Context
=============
To give some context here's what I'd like to do on the medium term:
* Step 1: Introduce notion of priority in EventListeners
* Step 2: Refactor XWiki init to use an EventListener on AppStarted with
low priority
* Step 3: Refactor wiki macros to use an EventListener on AppStarted with
priority value lower than at step2
* Step 4: Write an EventListener for the new UI Extensions with a priority
value higher than the one of step2 <-- this is the initial goal that led
me to make this proposal ;)
WDYT?
Sounds good if not overkill for the goal.
An simpler alternative would be to have more than a single AppStarted
event, like there is more than one starting level in Linux.
Let say one level before XWiki, the one during, the one after ? is there so
many other use case ?
Yes this is very close to the other solution I explained above.
But it's far less generic and introduces knowing stuff you don't really need to
know. For me it's a "poorman" implementation of priorities.
I don't know about other use cases right now but I can imagine a lot of them (for
example, some extensions that needs open office to be initialized, etc). We need to
remember that we're developing a platform and not just for XE's needs. The extra
amount of work is negligible IMO not to do it (btw I have a working version locally
already, I just need to fine tune it a bit for improved performance maybe).
Thanks
-Vincent