[MAGNOLIA-6593] resource-loader module throws NPE upon clean install when using the empty-webapp Created: 11/Mar/16  Updated: 06/Dec/23  Resolved: 14/Dec/16

Status: Closed
Project: Magnolia
Component/s: resource-loader
Affects Version/s: 5.4.5
Fix Version/s: 5.4.11, 5.5.1

Type: Bug Priority: Neutral
Reporter: Philip Mundt Assignee: Hieu Nguyen Duc
Resolution: Fixed Votes: 1
Labels: support
Remaining Estimate: 0d
Time Spent: 7.75d
Original Estimate: 5d

Attachments: Java Source File SetupModuleRepositoriesTask.java     PNG File could_not_install_or_update_resource-loader_module.png    
Issue Links:
Relates
relates to MAGNOLIA-5634 SecuritySupport will always be null w... Closed
relates to MAGNOLIA-9097 Instances randomly fail to start up o... Closed
relates to MAGNOLIA-9214 Instances randomly fail to start up o... Closed
causality
duplicate
is duplicated by MAGNOLIA-6598 NPE at SetupModuleRepositoriesTask.gr... Closed
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:
Sprint: Saigon 74, Saigon 75
Story Points: 5

 Description   

When using the empy-webapp as foundation for any project, the resource-loader module throws an NPE exception upon install. The actual install is not affected.

Stacktrace:

2016-03-11 16:26:21,050 ERROR info.magnolia.module.InstallContextImpl           : [56/216 tasks - Magnolia Resource Loader (version 5.4.6-SNAPSHOT)]> Could not install or update resource-loader module. Task 'Setup module repositories' failed. (NullPointerException: )
info.magnolia.module.delta.TaskExecutionException: Could not bootstrap workspace: null
	at info.magnolia.module.delta.SetupModuleRepositoriesTask.execute(SetupModuleRepositoriesTask.java:91)
	at info.magnolia.module.ModuleManagerImpl.applyDeltas(ModuleManagerImpl.java:531)
	at info.magnolia.module.ModuleManagerImpl.installOrUpdateModule(ModuleManagerImpl.java:513)
	at info.magnolia.module.ModuleManagerImpl$1.doExec(ModuleManagerImpl.java:288)
	at info.magnolia.context.MgnlContext$VoidOp.exec(MgnlContext.java:421)
	at info.magnolia.context.MgnlContext$VoidOp.exec(MgnlContext.java:418)
	at info.magnolia.context.MgnlContext.doInSystemContext(MgnlContext.java:392)
	at info.magnolia.module.ModuleManagerImpl.performInstallOrUpdate(ModuleManagerImpl.java:282)
	at info.magnolia.module.ui.ModuleManagerWebUI$2.run(ModuleManagerWebUI.java:123)
	at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NullPointerException
	at info.magnolia.module.delta.SetupModuleRepositoriesTask.grantRepositoryToSuperuser(SetupModuleRepositoriesTask.java:99)
	at info.magnolia.module.delta.SetupModuleRepositoriesTask.execute(SetupModuleRepositoriesTask.java:86)
	... 9 more

How to reproduce

Do a clean install using the empty-webapp (and additionally excluding all lang-modules from the webapp).

Source of the problem

During installation SecuritySupport might not yet be available and therefore is replaced with info.magnolia.cms.security.SecuritySupportObservedComponentFactory.InitPhaseSecuritySupportImpl. This implementation doesn't have an InitPhaseRoleManager so giving access to superuser role (as part of the installation of the module) fails, as the returned role manager is null (see info.magnolia.module.delta.SetupModuleRepositoriesTask#grantRepositoryToSuperuser(String) which is part of every DefaultModuleVersionHandler).

Adding such an InitPhaseRoleManager solves the NPE, but also doesn't properly execute the task, i.e. superuser doesn't have explicit access to the resources workspace after the installation (superuser has access to it thought, only the explicit ACL is missing in the role).

Additional info

It is not yet clear which module addition to the webapp solves the problem (by being installed after core and before resources-module) as the problem doesn't seem to be occuring in community-webapp.



 Comments   
Comment by Daniel Kasmeroglu [ 21/Sep/16 ]
  • Might be worth a try: info.magnolia.security:magnolia-security-app

I've checked this scenario now in greater detail and I can confirm that this is caused by a race condition. This issue occurs randomly on a clean install. However if I set a debugging breakpoint at the call of grantRepositoryToSuperuser the setup will be forced to wait there. Continuation after 1-2 seconds then doesn't show any problem.

I've added a patched SetupModuleRepositoriesTask.java which solves my issue (restarted my fresh install 30 times without this issue). This patch does nothing else than calling the grantRepositoryToSuperuser multiple times. I've added it in case someone needs to get this gone.
This is NOT a fix it's just a workaround.

Comment by Mikaël Geljić [ 30/Sep/16 ]

Right, so SecuritySupport is an observed component/bound to an ObservedComponentFactory. Since default implementation is only set in core module bootstraps, we've basically got the install process relying on a deferred observation listener to provide the correct impl to other modules' DefaultModuleVersionHandler/SetupModuleRepositoriesTask.

I'd argue observing components during the install phase is just prone to such mutations and should be delayed until the startup phase.
Meanwhile, since core module provides the default MVH + task for others to use, it should guarantee that once default securitySupport config is bootstrapped, the factory or provider is refreshed immediately to drop the init-phase impl.
Either that, or have the said factory to provide the default SecuritySupportImpl instance by code when no longer in init phase—until observation comes in anyway.

Comment by Will Scheidegger [ 18/Apr/18 ]

I think we ran into the same problem yesterday, but this time when upgrading an EE installation from 5.3.8 zu 5.6.1 (not a clean install). After a restart, everything was fine again. What's the officially suggested procedure in this situation?

Thanks!

Comment by Mikaël Geljić [ 20/Apr/18 ]

Hey Will, hard to say without more info or logs;

This ticket introduced an eager reloading of the SecuritySupport observed component, whenever an install task tries to do something with it and the registered instance is still the init-phase one (the one without a RoleManager). For which module/workspace did the task fail in your case?

If the task executed fine upon restart, I expect the setup to be in proper state; you may double-check the superuser role's ACLs for explicit workspace access.

Generated at Mon Feb 12 04:15:59 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.