enhancement
major
minor
major
minor
major
#29865
Configuration layering: removing a list entry whose key the underlying layers do not (or no longer) define fails the application start
Problem
An application configuration layered onto the configuration of the underlying layers can remove an entry of a keyed list with config:operation="remove":
{{{#!xml <role-rules> <rule id="InheritedRule" config:operation="remove"/> </role-rules> }}}
If the underlying layers do not define an entry with that key, the ConfigurationReader reports an error (IndexedListStorage.remove(): "No corresponding ConfigurationItem found for reference '...'"). This has two consequences:
- An application that removes an inherited entry no longer starts as soon as the underlying project (framework, application module) drops or renames that entry - e.g. after an update of the base project. The removal entry becomes a dangling reference that breaks the start-up instead of being an obsolete no-op.
- A file holding such a removal cannot be read on its own, without the base configuration (e.g. by InAppServiceConfigStore.read()), since the removal always refers to an entry of an empty list there. Tools reading and rewriting such a file (like SecurityDefinitionEditor of the security coverage view, which stores the removal of an inherited role rule as config:operation="remove", see #29782) have to filter the removal entries out before reading.
Proposal
Report a removal of a key that the list does not contain as a warning instead of an error: the entry the removal is meant to drop is not there, so the result is what the removal wants. The coverage view can then rely on the removal surviving an update of the underlying project, and the editor would no longer need to filter removal entries before reading its own file.
Changing this affects the reading of all configurations (ConfigurationReader / IndexedListStorage in com.top_logic.basic), so it should be decided whether a missing key is still to be reported as an error in other contexts (e.g. a typo in a hand-written configuration).
Lösung
- Entfernt ein Eintrag mit config:operation="remove" einen Schlüssel, den die Liste nicht (mehr) enthält, meldet IndexedListStorage.remove() in allen Kontexten eine Warnung (mit Schlüssel und Eigenschaft) statt eines Fehlers und lässt die Liste unverändert. Die Anwendung startet weiter, wenn das darunterliegende Projekt einen entfernten Eintrag streicht oder umbenennt; ein Tippfehler in einer handgeschriebenen Konfiguration erscheint als Warnung im Log. Damit verhalten sich Listen wie Maps, deren Entfernen eines fehlenden Schlüssels schon bisher folgenlos war.
- Positionsangaben (config:position="before"/"after" mit config:reference) auf einen unbekannten Schlüssel bleiben ein Fehler: für "vor einem fehlenden Eintrag einfügen" gibt es kein sinnvolles Ergebnis.
- SecurityDefinitionEditor liest die Ids der Entfernungseinträge weiterhin aus dem Dokument, da es sie beim Zurückschreiben braucht; das Herausnehmen vor dem Lesen vermeidet nur noch die Warnung, nicht mehr einen Fehler.