Re: [xwiki-devs] [Proposal] Adding the notion of Priority to Event Listeners
On Thu, Nov 24, 2011 at 22:22, Vincent Massol vinc...@massol.net wrote: On Nov 24, 2011, at 8:15 PM, Anca Luca wrote: On 11/24/2011 05:31 PM, Vincent Massol wrote: On Nov 24, 2011, at 4:55 PM, Denis Gervalle wrote: On Thu, Nov 24, 2011 at 16:25, Vincent Massolvinc...@massol.net wrote: On Nov 24, 2011, at 4:06 PM, Denis Gervalle wrote: On Thu, Nov 24, 2011 at 13:58, Vincent Massolvinc...@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 ? Well, I have said +1 anyway, but... 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. Yes it's static dependency vs loose dependency. One is statically typed the other is documentation. But that's the only way I know to not have modules depend on each other. I like the static way of course but what you proposed while it's good for this specific use case doesn't solve all other use cases, which is why I'm ambivalent about it and why I think the generic solution is a bit better (I could be convinced otherwise with enough arguing and if enough devs prefer the non generic way ;)). I sort of agree with Dennis on this one. Numbered priorities always have conflicts, and in order to make sure you place yourself in the proper place (before this stuff, after this other stuff) you need to check (in the code? in a documentation about priority numbers?) the numbers that stuff are using. Or did I understand the proposal wrong and it's not about priority numbers? It's really a good idea BUT, as we've discussed before, numbered priorities are always very tricky, since you can never be sure what it means when you put 100 or 0 or some other number x (what do other listeners declare? will my listener be before or after a certain other listener?). If you can propose a better solution I'm all for it. I just don't know a better solution. FYI I've reviewed
Re: [xwiki-devs] [Proposal] Adding the notion of Priority to Event Listeners
On Thu, Nov 24, 2011 at 1:58 PM, Vincent Massol vinc...@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 Will also allows to finally finish wiki components which was stuck without any way to be called when the database is ready for it to initialize. * 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? +1 Thanks -Vincent ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Proposal] Adding the notion of Priority to Event Listeners
+1 Thanks, Marius On Thu, Nov 24, 2011 at 2:58 PM, Vincent Massol vinc...@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? Thanks -Vincent ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Proposal] Adding the notion of Priority to Event Listeners
On Thu, Nov 24, 2011 at 13:58, Vincent Massol vinc...@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 ? Thanks -Vincent ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Proposal] Adding the notion of Priority to Event Listeners
On Nov 24, 2011, at 4:06 PM, Denis Gervalle wrote: On Thu, Nov 24, 2011 at 13:58, Vincent Massol vinc...@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 ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Proposal] Adding the notion of Priority to Event Listeners
On Thu, Nov 24, 2011 at 16:25, Vincent Massol vinc...@massol.net wrote: On Nov 24, 2011, at 4:06 PM, Denis Gervalle wrote: On Thu, Nov 24, 2011 at 13:58, Vincent Massol vinc...@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 ? Well, I have said +1 anyway, but... 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@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Proposal] Adding the notion of Priority to Event Listeners
On Nov 24, 2011, at 4:55 PM, Denis Gervalle wrote: On Thu, Nov 24, 2011 at 16:25, Vincent Massol vinc...@massol.net wrote: On Nov 24, 2011, at 4:06 PM, Denis Gervalle wrote: On Thu, Nov 24, 2011 at 13:58, Vincent Massol vinc...@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 ? Well, I have said +1 anyway, but... 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. Yes it's static dependency vs loose dependency. One is statically typed the other is documentation. But that's the only way I know to not have modules depend on each other. I like the static way of course but what you proposed while it's good for this specific use case doesn't solve all other use cases, which is why I'm ambivalent about it and why I think the generic solution is a bit better (I could be convinced otherwise with enough arguing and if enough devs prefer the non generic way ;)). Thanks -Vincent 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@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Proposal] Adding the notion of Priority to Event Listeners
On 11/24/2011 05:31 PM, Vincent Massol wrote: On Nov 24, 2011, at 4:55 PM, Denis Gervalle wrote: On Thu, Nov 24, 2011 at 16:25, Vincent Massolvinc...@massol.net wrote: On Nov 24, 2011, at 4:06 PM, Denis Gervalle wrote: On Thu, Nov 24, 2011 at 13:58, Vincent Massolvinc...@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 ? Well, I have said +1 anyway, but... 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. Yes it's static dependency vs loose dependency. One is statically typed the other is documentation. But that's the only way I know to not have modules depend on each other. I like the static way of course but what you proposed while it's good for this specific use case doesn't solve all other use cases, which is why I'm ambivalent about it and why I think the generic solution is a bit better (I could be convinced otherwise with enough arguing and if enough devs prefer the non generic way ;)). I sort of agree with Dennis on this one. Numbered priorities always have conflicts, and in order to make sure you place yourself in the proper place (before this stuff, after this other stuff) you need to check (in the code? in a documentation about priority numbers?) the numbers that stuff are using. Or did I understand the proposal wrong and it's not about priority numbers? It's really a good idea BUT, as we've discussed before, numbered priorities are always very tricky, since you can never be sure what it means when you put 100 or 0 or some other number x (what do other listeners declare? will my listener be before or after a certain other listener?). I would think all the number-based priority levels endup being used as a static list-based priority levels (there are a few well-known values that are used), since you can't really use a continuous interval (you need before this standard listener or after this other standard listener, if we're talking about non-standard listeners, numbers are not much more helpful since you can never know
