Re: update mechanism: tasks to be executed always

>> Ok..  so the 18 million euro question -- will there be a built-in
>> upgrade path for current users of 3.0 -> 3.5?
>
> Yes ;-)
>
>> Will exporting the production website and dropping those files into
>> mangolia 3.5 work?
>
> You take your 3.0 application and stop it, drop the new jars, startup.
> The update UI tells you what to do and will update the system
> accordingly by changing the configuration as smart as possible. So not
> even an export import needed.
>
>>   This sounds like it's going to start being a deal breaker if
>> Magnolia becomes know as a product with no migration/upgrade path.
>
> The issue we discuss here is a feature added in 3.5 and then removed
> in the last second.
>
> The rc1 will be ready for download in some hours! Please test the
> update mechanism so that we can ensure the upgrade path for your
> system ;-)
>
> Philipp Bracher
>
>>
>> --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
>> ----------------------------------------------------------------
>
>
> ----------------------------------------------------------------
> for list details see
> http://documentation.magnolia.info/docs/en/editor/stayupdated.html
> ----------------------------------------------------------------