[ http://jira.magnolia.info/browse/MAGNOLIA-1853?page=comments#action_15108 ] Fabrizio Giustina commented on MAGNOLIA-1853: ---------------------------------------------
> 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 ;) ): - based on the server.admin flag I usually adapt the default page, permissions for the anonymous user, cache settings - based on a specific enviroment (dirs, environment properties) adapt the cache settings (note, I am using the ehcache impl) - if the server is a production one check and change the password for any user that has been set to its default (don't allow superuser/superuser in any way!) - during development (magnolia.develop=true) reload part of the configuration (bootstrap) at each start - check that a few custom filters are always in the appropriate position (the application will not work at all if they are not placed properly) - sort dialogs, paragraphs and templates in alphabetical order 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. This just works great if you can add a task that simply check if the filter is missing and add it. Easy, quick and robust. Note that this is something I would like to see also in core modules and how I always thought part of the upgrade framework should work, but I know you disagree ;) > ModuleLifecycle : allow usage of the Task api and global save/rollback > ---------------------------------------------------------------------- > > Key: MAGNOLIA-1853 > URL: http://jira.magnolia.info/browse/MAGNOLIA-1853 > Project: Magnolia > Issue Type: Task > Components: core > Reporter: Grégory Joseph > Assigned To: Grégory Joseph > Fix For: Green > > > 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 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia.info/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira ---------------------------------------------------------------- for list details see http://documentation.magnolia.info/docs/en/editor/stayupdated.html ----------------------------------------------------------------
