[MGNLPUR-165] Configuration resolver should use SiteManager Created: 20/Jan/16  Updated: 01/Feb/16  Resolved: 20/Jan/16

Status: Closed
Project: Magnolia Public User Registration
Component/s: multisite
Affects Version/s: 2.5.1
Fix Version/s: 2.5.2

Type: Bug Priority: Neutral
Reporter: Roman Kovařík Assignee: Roman Kovařík
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0d
Time Spent: 4.75h
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:
Sprint: Kromeriz 28
Story Points: 1

 Description   

The configuration is resolved from the current URI. To be precise, the first path segment of the URI is used to find a matching config name which will be returned.

If the URI doesn't contain such a valid name – which is tha case when a site uses a domain + mapping with a handlePrefix – the correct configuration is not resolved.

Travel Demo uses a custom config named travel:

Suggested solutions

  1. Deprecate DefaultConfigurationResolver and use the info.magnolia.module.site.SiteManager by default to resolve the config
    • Might break clients installation because their config resolution might rely on old one
  2. Maintain the old ConfigurationResolver and a new one (info.magnolia.module.publicuserregistration.configuration.DelegatingConfigurationResolver) that is aware of both resolver
    • Maintains backwards compat.


 Comments   
Comment by Philip Mundt [ 20/Jan/16 ]

If I'm not mistaken, this will limit the usage of those configs in an CE instance to only one, if a site is configured!?
I see the problem, but wonder whether there is another approach (i.e. using the root node's path – which was done before but in a broken way by determining it from the URL and not the aggregation state's mainContentNode)!

Generated at Mon Feb 12 06:43:42 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.