24 Nov
2011
24 Nov
'11
4:55 p.m.
On Thu, Nov 24, 2011 at 16:25, Vincent Massol <vincent(a)massol.net> wrote:
On Nov 24, 2011, at 4:06 PM, Denis Gervalle wrote:
so
Well, I have said +1 anyway, but...
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 many other use case ?
Yes this is very close to the other solution I
explained above.
Surely.
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.
Well, it depends on the pursued goal. What I mostly dislike in priority
systems, it the management of priorities. When you say that you are
listening on a let says DatabaseStarted event, you clearly explain what you
really need. On the other hand, when you say that you want to be run at
priority 100 of the AppStartedEvent, without another document saying that
starting at 100, database is ready, and ensuring this in the database
module, you do not really know what it means really.
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO