« Return to Thread: Re: update mechanism: tasks to be executed always
Re: update mechanism: tasks to be executed always
by Magnolia - Dev mailing list
::
Rate this Message:
Hi,
Following some internal discussions, we decided to remove this for
the 3.5 release. I was personally unconvinced by the implementation,
given the fact that startup tasks are imho not in their place within
a Module's version handler. They're better off in the
ModuleLifecycle. Also, we've been thinking about introducing multiple
"phases" in the startup process, but for lack of time and
conclusions, we did not.
The only module that was using startup tasks was cache, and I moved
these to CacheModule (which implements ModuleLifecycle), which I
think is much more appropriate. One thing that might be missing is
the global "save/rollback" that the install/update process has. We
could think about reimplementing something similar around the
lifecycle. We could also think about making the Task api useable in
that context.
Please let us know if you have any custom code that suffers from
this. I'll gladly help on this very specific subject, since this is a
last minute and unexpected change. It would also help us understand
better any other potential use case for this.
Cheers,
greg
ps: MAGNOLIA-1801 is where it's at.
On Oct 25, 2007, at 16:48 , Grégory Joseph wrote:
> Back on this subject - since there are similarities with blocking
> tasks as per MAGNOLIA-1767 - I'm refactoring the processStartupTasks
> () method a little to try and remove the current code duplication.
> Fabrizio : was the intention to save after each module's startup
> tasks or only once after all modules? It's not clear since the
> "success" variable is initialized outside the modules' loop and
> there are no testcases ;)
>
> Thx
>
> g
>
> On Aug 23, 2007, at 19:50 , Philipp Bracher wrote:
>
>> Without going into details I do agree to Fabrizio:
>>
>> - a startup task is not an install and not an update task, even if
>> you could use the same mechanism (was not obvious to me ether)
>>
>> - the lifecycle (or phases) for calling start method of the module
>> and startup tasks are not exactly the same because the startup
>> tasks are execute before any of the module is started.
>>
>> I'm sure that other phases will be introduced in future and I can
>> see no harm in that.
>>
>> Philipp Bracher
>>
>>
>> On 22.08.2007, at 20:31, Fabrizio Giustina wrote:
>>
>>> On 8/22/07, Grégory Joseph <dev-list@...> wrote:
>>>>
>>>> On Aug 20, 2007, at 22:42 , Fabrizio Giustina wrote:
>>>> The getDeltas() method can be reimplemented by each and every
>>>> module
>>>> if it needs to.
>>>> (which is where you could potentially always return certain
>>>> deltas if
>>>> you want to systematically run certain tasks at startup - and I see
>>>> you coming with the "i don't want a gui for this" argument, but you
>>>> fixed that already ;) )
>>>
>>> the difference is that normal update task MAY have a gui, sometimes
>>> that's desired and sometimes not so I added a way to turn it off.
>>> Task
>>> that should be executed always must not require a user confirmation.
>>> If we say that everything is controlled by the same configuration
>>> parameter this means that if we adds tasks that should always be
>>> executed we are forced to disable the gui for everything, which
>>> is not
>>> want we want.
>>>
>>>>> and
>>>>> doesn't handle the fact that if this configuration is removed
>>>>> from an
>>>>> existing repository, nobody will ever set it back and the
>>>>> manager will
>>>>> keep throwing its NPE.
>>>>
>>>> This will be the case for each and every piece of configuration
>>>> that's expected to be there by any kind of "manager", right ?
>>>> I'm in favor of sanity checks, but if users mess up their
>>>> configuration, I'd just expect the Magnolia instance to die
>>>> peacefully, not try to resuscitate itself.
>>>
>>> mh... sorry, but I think that keeping magnolia alive is better: we
>>> don't touch anything existing, but if a standard configuration has
>>> been deleted readding it back would not hurt. The only way for
>>> recovering from a similar situation at this moment is re-
>>> bootstrapping
>>> the whole config repository (if you are unable to load
>>> admininterface)
>>> and that's absolutely worst
>>>
>>>> Well, given my comments above. I don't really see the point, since
>>>> this seems to duplicate what is/can be done in
>>>> ModuleLifecycle.start() ?
>>>
>>> a couple of valid reason:
>>> - modulemanager already handles "transactional" update, loading all
>>> the tasks and applying changes only if everything went ok. There
>>> is a
>>> lot of boilerplate code for doing this, what's the point of
>>> replicating this bunch of code in every single module?
>>> - doing that in module manager means also that startup tasks are
>>> executed for all the modules and only after that each module is
>>> started. Doing that in ModuleLifecycle.start() means that you
>>> will run
>>> task/start for each single module: if you have to check a
>>> configuration that is used by another module too (i.e. filters)
>>> that's
>>> not optimal at all.
>>>
>>> please have a look at the current implementation in svn, IMHO it
>>> looks
>>> easy and clean. It's easy for user to add tasks if they want and
>>> nothing changes if you don't need them. The code in module
>>> manager is
>>> clean and there is no added complexity.
>>>
>>> fabrizio
>>>
>>> ----------------------------------------------------------------
>>> for list details see
>>> http://documentation.magnolia.info/docs/en/editor/stayupdated.html
>>> ----------------------------------------------------------------
>>
>>
>> ----------------------------------------------------------------
>> for list details see
>> http://documentation.magnolia.info/docs/en/editor/stayupdated.html
>> ----------------------------------------------------------------
>
>
> ----------------------------------------------------------------
> for list details see
> http://documentation.magnolia.info/docs/en/editor/stayupdated.html
> ----------------------------------------------------------------
----------------------------------------------------------------
for list details see
http://documentation.magnolia.info/docs/en/editor/stayupdated.html
----------------------------------------------------------------
Following some internal discussions, we decided to remove this for
the 3.5 release. I was personally unconvinced by the implementation,
given the fact that startup tasks are imho not in their place within
a Module's version handler. They're better off in the
ModuleLifecycle. Also, we've been thinking about introducing multiple
"phases" in the startup process, but for lack of time and
conclusions, we did not.
The only module that was using startup tasks was cache, and I moved
these to CacheModule (which implements ModuleLifecycle), which I
think is much more appropriate. One thing that might be missing is
the global "save/rollback" that the install/update process has. We
could think about reimplementing something similar around the
lifecycle. We could also think about making the Task api useable in
that context.
Please let us know if you have any custom code that suffers from
this. I'll gladly help on this very specific subject, since this is a
last minute and unexpected change. It would also help us understand
better any other potential use case for this.
Cheers,
greg
ps: MAGNOLIA-1801 is where it's at.
On Oct 25, 2007, at 16:48 , Grégory Joseph wrote:
> Back on this subject - since there are similarities with blocking
> tasks as per MAGNOLIA-1767 - I'm refactoring the processStartupTasks
> () method a little to try and remove the current code duplication.
> Fabrizio : was the intention to save after each module's startup
> tasks or only once after all modules? It's not clear since the
> "success" variable is initialized outside the modules' loop and
> there are no testcases ;)
>
> Thx
>
> g
>
> On Aug 23, 2007, at 19:50 , Philipp Bracher wrote:
>
>> Without going into details I do agree to Fabrizio:
>>
>> - a startup task is not an install and not an update task, even if
>> you could use the same mechanism (was not obvious to me ether)
>>
>> - the lifecycle (or phases) for calling start method of the module
>> and startup tasks are not exactly the same because the startup
>> tasks are execute before any of the module is started.
>>
>> I'm sure that other phases will be introduced in future and I can
>> see no harm in that.
>>
>> Philipp Bracher
>>
>>
>> On 22.08.2007, at 20:31, Fabrizio Giustina wrote:
>>
>>> On 8/22/07, Grégory Joseph <dev-list@...> wrote:
>>>>
>>>> On Aug 20, 2007, at 22:42 , Fabrizio Giustina wrote:
>>>> The getDeltas() method can be reimplemented by each and every
>>>> module
>>>> if it needs to.
>>>> (which is where you could potentially always return certain
>>>> deltas if
>>>> you want to systematically run certain tasks at startup - and I see
>>>> you coming with the "i don't want a gui for this" argument, but you
>>>> fixed that already ;) )
>>>
>>> the difference is that normal update task MAY have a gui, sometimes
>>> that's desired and sometimes not so I added a way to turn it off.
>>> Task
>>> that should be executed always must not require a user confirmation.
>>> If we say that everything is controlled by the same configuration
>>> parameter this means that if we adds tasks that should always be
>>> executed we are forced to disable the gui for everything, which
>>> is not
>>> want we want.
>>>
>>>>> and
>>>>> doesn't handle the fact that if this configuration is removed
>>>>> from an
>>>>> existing repository, nobody will ever set it back and the
>>>>> manager will
>>>>> keep throwing its NPE.
>>>>
>>>> This will be the case for each and every piece of configuration
>>>> that's expected to be there by any kind of "manager", right ?
>>>> I'm in favor of sanity checks, but if users mess up their
>>>> configuration, I'd just expect the Magnolia instance to die
>>>> peacefully, not try to resuscitate itself.
>>>
>>> mh... sorry, but I think that keeping magnolia alive is better: we
>>> don't touch anything existing, but if a standard configuration has
>>> been deleted readding it back would not hurt. The only way for
>>> recovering from a similar situation at this moment is re-
>>> bootstrapping
>>> the whole config repository (if you are unable to load
>>> admininterface)
>>> and that's absolutely worst
>>>
>>>> Well, given my comments above. I don't really see the point, since
>>>> this seems to duplicate what is/can be done in
>>>> ModuleLifecycle.start() ?
>>>
>>> a couple of valid reason:
>>> - modulemanager already handles "transactional" update, loading all
>>> the tasks and applying changes only if everything went ok. There
>>> is a
>>> lot of boilerplate code for doing this, what's the point of
>>> replicating this bunch of code in every single module?
>>> - doing that in module manager means also that startup tasks are
>>> executed for all the modules and only after that each module is
>>> started. Doing that in ModuleLifecycle.start() means that you
>>> will run
>>> task/start for each single module: if you have to check a
>>> configuration that is used by another module too (i.e. filters)
>>> that's
>>> not optimal at all.
>>>
>>> please have a look at the current implementation in svn, IMHO it
>>> looks
>>> easy and clean. It's easy for user to add tasks if they want and
>>> nothing changes if you don't need them. The code in module
>>> manager is
>>> clean and there is no added complexity.
>>>
>>> fabrizio
>>>
>>> ----------------------------------------------------------------
>>> for list details see
>>> http://documentation.magnolia.info/docs/en/editor/stayupdated.html
>>> ----------------------------------------------------------------
>>
>>
>> ----------------------------------------------------------------
>> for list details see
>> http://documentation.magnolia.info/docs/en/editor/stayupdated.html
>> ----------------------------------------------------------------
>
>
> ----------------------------------------------------------------
> for list details see
> http://documentation.magnolia.info/docs/en/editor/stayupdated.html
> ----------------------------------------------------------------
----------------------------------------------------------------
for list details see
http://documentation.magnolia.info/docs/en/editor/stayupdated.html
----------------------------------------------------------------
« Return to Thread: Re: update mechanism: tasks to be executed always
| Free embeddable forum powered by Nabble | Forum Help |
