Re: update mechanism: tasks to be executed always

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