[MAGNOLIA-1916] NPE when updating from 3.0.5 due to missing cache voters Created: 03/Dec/07  Updated: 23/Jan/13  Resolved: 05/Dec/07

Status: Closed
Project: Magnolia
Component/s: None
Affects Version/s: 3.5 RC2
Fix Version/s: 3.5 RC3

Type: Bug Priority: Blocker
Reporter: Vivian Steller Assignee: Vivian Steller
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File NPE-when-updating from-3.0.5-due-to-missing-cache-voters.txt    
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

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.



 Comments   
Comment by Fabrizio Giustina [ 03/Dec/07 ]

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

Comment by Vivian Steller [ 05/Dec/07 ]

So, finally, I think (at least for the 3.5 final version) we should definitely revert back to the solution with the startup tasks. In general the MAGNOLIA-1853 issue should not be discussed or changed at all within RCs. Let's please schedule this to the green version (what it actually is).

So, can you roll back the changes to the startup solution then? Thank you, Fabrizio!

Comment by Vivian Steller [ 05/Dec/07 ]

okay, I'll quickly do it...

Comment by Vivian Steller [ 05/Dec/07 ]

solved: reverted back to startup task solution. svn revision for that change is r13392.

Generated at Mon Feb 12 03:31:34 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.