[MAGNOLIA-1345] NPEs when a module tries to load content into a non existing repository Created: 07/Feb/07  Updated: 23/Jan/13  Resolved: 01/Nov/07

Status: Closed
Project: Magnolia
Component/s: None
Affects Version/s: 3.0.1
Fix Version/s: 3.5 RC1

Type: Bug Priority: Major
Reporter: Fabrizio Giustina Assignee: Fabrizio Giustina
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

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   

This happens when DMS is not installed on magnolia and the samples module is.
The samples module has not dependencies on DMS so it tries to load content into the dms repository and a couple of NPE are thrown. In order to properly fix this the samples module should be split making a samples-dms module probably, but checking if a HierarchyManager is non null is absolutely needed.



 Comments   
Comment by Fabrizio Giustina [ 07/Feb/07 ]

closed with revisions 8361 and 8362
When a module tries to load content into a non-existing repository a error log is shown but the bootstrap process is not blocked. This behavior is definitively satisfactory IMHO.

Comment by Magnolia International [ 07/Feb/07 ]

The samples module actually has a dependency on dms (at least in terms of magnolia-module dependencies). Reopening for discussion on the list.

Comment by Fabrizio Giustina [ 07/Feb/07 ]

The DMS dependency in samples is declared as optional (as it should be) so it's not a bug.
IMHO is better to leave this behavior so that the sample module could be used indifferently when the dms module is installed but having it only load content for available repositories.

Comment by Philipp Bracher [ 08/Feb/07 ]

In general: If a dipendency is optional the modul needs to handel the absence of the optional module properly. In this particular case I would advice to move the dms bootstrap files to an other place in the resources. The register methods should check the presence of the workspace and bootstrapp the files afterward. There are helper methods to implement this with ease.

A hack (but a good one) would be to put the files into the path mgnl-boostrap/dms which means that the files are bootstrapped during the registration of the dms only. In case the dms is not present the files are completely ignored.

Comment by Fabrizio Giustina [ 08/Feb/07 ]

> A hack (but a good one) would be to put the files into the path mgnl-boostrap/dms which means that the files are bootstrapped during the registration of the dms only. In case the dms is not present the files are completely ignored.

this could solve another related issue with the workflow module: the workflow module adds some commands into the modules/dms/config path. This means that when magnolia restarts it sees an incomplete module definition and it tries to load a dummy engine class, logging a classNotFound error in the log. This is really annoying since there is no way to cleanly install the workflow module without the dms one.
Moving such bootstrap files to a bootstrap/dms folder is a good solution also for that use case.

Comment by Fabrizio Giustina [ 01/Nov/07 ]

already resolved for 3.1: if a repository doesn't exist import to that repository will be skipped (and logged)

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