[toKrause]

Link to jira.

Pull Request Checklist (Author)

Please go through the following checklist before assigning the PR for review:

Ticket & Documentation

• The issue in the ticket is clearly described and the solution is documented.
• Design decisions (if any) are explained.
• The ticket references the correct source and target branches.
• The fixed-version is correctly set in the ticket and matches the PR's target branch (main).

Feature & Improvement Specific Checks

• Instructions on how to test or use the feature are included or linked (e.g. to documentation).
• For UI changes: before & after screenshots are attached.
• New features or migrations are documented.
• Does this change affect existing applications, data, or configurations?
  • Yes: Is a migration required? If yes, describe it.
  • Breaking change is marked in the commit message.

Testing

• I have tested the changes locally.
• The feature behaves as described in the ticket.
• Were existing tests modified?
  • Yes: explain the changes for reviewers.

MCR Conventions & Metadata

• MCR naming conventions are followed
• If the public API has changed:
  • Old API is deprecated or a migration is documented.
  • If not, no action needed.
• Java license headers are added where necessary.
• Javadoc is written for non-self-explanatory classes/methods (Clean Code).
• All configuration options are documented in Javadoc and mycore.properties.
• No default properties are hardcoded — all set via mycore.properties.

Multi-Repo Considerations

• Is an equivalent PR in MIR required?
  • If yes, is it already created?

[sebhofmann]

One more: the record ConfigurationKey in MCRConfiguration2 is unused now that the configuration cache is removed and can be deleted.

[sebhofmann]

Behaviour change for prefix patterns like Values.*: The Javadoc of @MCRRawProperties says all properties starting with the given prefix and ., and the old code filtered with key.startsWith(prefix). Now tree.deeplyNested("Values").toProperties() also contains the value of the node itself under the key "", so Foo.Values=x adds "" -> "x" to the map. Conversely, Foo.Values.Class is now removed by this line, while it used to be included as Class.

This affects e.g. MCRXsonifyTransformer (Namespaces.*) and MCRPersistenceUnitDescriptor (Properties.*). MCRInstantiatorRawPropertiesBasicTest covers neither case.

[toKrause]

I added support for those uncommon configurations and expanded the test class. Exact same test pass under main and this PR branch.

[sebhofmann]

With the CONFIGURATIONS cache gone, every getInstanceOf / getSingleInstanceOf call runs resolveValueClass and thus MCRClassTools.forName again, even if the singleton is already in instanceHolder. For classes from plugin JARs in mycore-home/lib, Class.forName first throws a ClassNotFoundException on every call before the extendedClassLoader is tried. The cache was explicitly reintroduced in MCR-3668 (7d9a135). Is dropping it intended, or should the resolved configuration (or at least the value class) still be cached?

[sebhofmann]

Question: Class is now hidden on every level of the tree (keys(), nested()). A map entry named Class (e.g. Prefix.Map.Class=...) used to be possible and is now silently ignored. If that is intended, it should be documented.

[toKrause]

Fixed by excluding Class properties only when using a tree node to instantiate a class. Additionally, sentinel values are excluded after they are interpreted.