On Nov 24, 2011, at 4:06 PM, Denis Gervalle wrote: > On Thu, Nov 24, 2011 at 13:58, Vincent Massol <[email protected]> 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
