Re: update mechanism: tasks to be executed always

>
> --David
>
> Grégory Joseph wrote:
>> 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
>> ----------------------------------------------------------------
>
>
> --
> David Smith
> Network Operations Supervisor
> Department of Entomology
> Cornell University
> 2132 Comstock Hall
> Ithaca, NY 14853
> Phone: (607) 255-9571
> Fax: (607) 255-0940
>
>
> ----------------------------------------------------------------
> for list details see
> http://documentation.magnolia.info/docs/en/editor/stayupdated.html
> ----------------------------------------------------------------