[ http://jira.magnolia.info/browse/MAGNOLIA-1916?page=comments#action_15269 ] Fabrizio Giustina commented on MAGNOLIA-1916: ---------------------------------------------
This is related to MAGNOLIA-1853 The creation of cache voter was a conditional task executed in the startupTask phase of ModuleVersionHandler. Then it was moved away and hacked using a static method in the AddCacheVoterTask, that I removed in version r13327 (after spending a few hours before understanding that my build wan not working anymore due to the save() added in the AddCacheVoterTask that was breaking installation and update :( ). After reviewing how updates are handled now I am always more in favour of keeping the startupTasks in the module version handler (call them "checkThatEverythingIsOkWithTheCurrentVersion" if startupTasks doesn't sound well in a module version handler). The approach of doing an update/fix the configuration when there is something wrong is easier and more robust than using versions in order to control which task should be run. For example I had to spend a day trying to update a system which was already running a magnolia 3.1 milestone build in order to successfully update to 3.5-rc2 For example I had to deal with errors like: "java.util.LinkedHashMap cannot be cast to info.magnolia.cms.security.IPSecurityManager" since the ip security configuration was changed and it had to be an observed manager. I didn't hat such configuration in 3.1 and the update didn't fix it because 3.1 milestone versions were not handled. I actually rewrote all the standard update tasks for my project by using a "do it if it's not already done" logic, for example: check if the server/IPConfig node already has a "class" property and, if not, bootstrap the ipconfig configuration from file. Do the same for server/rendering/linkResolver, server/URI2RepositoryMapping, etc etc. for me doing this kind of approach vs a version based approach for critical tasks is: -a lot easier to implement - works better with *any* version, handling milestone or custom builds without problems and without any additional effort - helps in fixing problems on existing broken installation - is more fitting also for task like the one already added for the cache module which configured cache in a different way in public/authoring instances: why should that only be executed at install? Why should we need a script to convert an instance between public and author if we already have a flag in the configuration file which can be checked at each restart? The conclusion is that I will be happy to put back the creation of cache voters were it was previously, in startup tasks. :) I am open to discussion, but please consider also the benefits and the reasons in this comment before saying that we don't like something that is called startupTasks in a version handler ;) > NPE when updating from 3.0.5 due to missing cache voters > -------------------------------------------------------- > > Key: MAGNOLIA-1916 > URL: http://jira.magnolia.info/browse/MAGNOLIA-1916 > Project: Magnolia > Issue Type: Bug > Affects Versions: 3.5 RC2 > Reporter: Vivian Steller > Assigned To: Vivian Steller > Priority: Blocker > Fix For: 3.5 RC3 > > Attachments: NPE-when-updating > from-3.0.5-due-to-missing-cache-voters.txt > > > When updating from 3.0.5 right after installing and hitting the "startup > magnolia" button the NPE attached occurs. > This, is bug was accidentally introduced with r13327. -- 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 ----------------------------------------------------------------
