Re: update mechanism: tasks to be executed always

> 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
> ----------------------------------------------------------------