Re: update mechanism: tasks to be executed always

> On Nov 15, 2007 9:05 PM, Grégory Joseph <dev-list@...>  
> wrote:
>> 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.
>
> should this have been discussed before removing them????
> sorry, but I implemented them for a reason and this was already
> discussed, for me that feature is really needed and I can't understand
> why I should remove it without warning just because you are not
> convinced and without giving an alternative.

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