Update mechanism improvements
(MAGNOLIA-5529)
|
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | modulemechanism, updatemechanism |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Sub-task | Priority: | Major |
| Reporter: | Magnolia International | Assignee: | Magnolia International |
| Resolution: | Won't Do | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Template: |
|
||||||||
| Date of First Response: | |||||||||
| Description |
|
This is currently implemented through startupTasks, but using the ModuleLifecycle is more relevant, since startup tasks are not related to any given version of a module |
| Comments |
| Comment by Fabrizio Giustina [ 16/Nov/07 ] |
|
this is a list of requirements that are now fulfilled by the current implementation that should be maintained while moving to the ModuleLifecycle interface:
|
| Comment by Magnolia International [ 16/Nov/07 ] |
|
Thanks ! In your sample use case, if the custom module declares a dependency on the cache module, "custom module" will always be started before "cache module". Given that, can you elaborate what would still not be working then ? |
| Comment by Fabrizio Giustina [ 16/Nov/07 ] |
|
> if the custom module declares a dependency on the cache module, "custom module" will always be started before "cache module" mh.. shouldn't this be: "custom module" will always be started AFTER "cache module". |
| Comment by Magnolia International [ 17/Nov/07 ] |
|
> mh.. shouldn't this be: "custom module" will always be started AFTER "cache module". OTOH, (if that's not already the case, it should be), the CacheManager should observe its config and reload on change. (But I agree it's ugly and non-optimal to have it restart - if I'm not wrong though, observation is only triggered after a save, not after operations, which would mean, if we had a single save upon modules startup, that the CacheManager would reload its config only once. Can you elaborate a bit more on your use case: why (based on what?) does your module have to change the cache config at startup (and not during the rest of the lifetime of the app?) Have you had a look at ModuleLifecycleContext.registerModuleObservingComponent(), the start() method of its implementation and how it is used ? Maybe that or a similar callback mechanism could be used to implement what you need. Somehow, this makes me think about The "pre-startup" phase also sounds reasonable, but I'm afraid we'll need a pre-pre-startup phase, a post-startup phase and so on and so forth. |
| Comment by Fabrizio Giustina [ 17/Nov/07 ] |
|
> Can you elaborate a bit more on your use case: why (based on what?) does your module have to change the cache config at startup (and not during the rest of the lifetime of the app?) I have several cases where I need to change the configuration on startup (before that anything is started), mainly for adapting the configuration to different environments, to configure it properly during development, to do a sort of "sanity checks" that assure that you can't completely kill magnolia by simply setting a wrong property in the config jcr. Just as an example, this is are a few things that startup tasks make easy to do. (please note: "make easy". I know you can elaborate several other ways to do them, but this works great and it's also easy and fast to do... you could mess around with tons of bootstrap files maybe, but I can't understand why it should not be easier
Another important use case for me: with several developers working and frequent releases of the application the only viable way to add new configurations is that developers just add them NOT as tasks that needs to be executed for a specific version but as task that need to be executed if something is lacking. For example if somebody adds a filter that is needed by the application starting from a specific point in time (not a release), it needs to be applied at the first svn update or deploy to each environment. |
| Comment by Philipp Bracher [ 20/Nov/07 ] |
|
>The "pre-startup" phase also sounds reasonable, but I'm afraid we'll need a pre-pre-startup phase, a post-startup phase and so on and so forth. I look at it as something similar to running level on unix systems. Having this phases (I still would like to have them for installation too) allows very flexible startup scenarios. Here is a kind of draft example (a bit too many extra phases indeed): What I would like to see is that the ConfigLoader disapeares and is completely mapped into this startup level thingy We might then use the same kind of levels for installation by putting the system in a certain runlevel |
| Comment by Fabrizio Giustina [ 03/Dec/07 ] |
|
Please see my comment in |
| Comment by Michael Mühlebach [ 04/Nov/15 ] |
|
Given the thousands of other issues we have open that are more highly requested, we won't be able to address this issue in the foreseeable future. Instead we will focus on issues with a higher impact, and more votes. |