Resolve resource links to the controller exposing the domain class

[codeconsole]

A resource link derives its controller from the domain class name, so a controller not named after its domain class is never found:

class PeopleController extends RestfulController<Person> {
    PeopleController() { super(Person) }
}

<g:link resource="${person}">          <%-- targeted "person", which does not exist --%>

DefaultLinkGenerator now keeps a domain-class-to-controller index alongside the existing namespace index, built lazily and guarded by the same artefact-array identity check, so it costs nothing on the common path and rebuilds when the set of controllers changes.

A controller named after the domain class always wins. The index is consulted only when no such controller is registered, so an application following the naming convention is unaffected — including one that has both a plain BookController and a BookRestfulController extends RestfulController<Book>.

A controller's domain class is found by walking its supertypes for a generic type argument the mapping context recognises as a persistent entity. Superclasses and interfaces are both walked, so a base class or a Groovy trait at any depth works, without this class depending on the REST controller hierarchy:

class PeopleController extends RestfulController<Person> {}            // resolved
class WidgetsController extends WidgetControllerBase {}                // resolved through the base
class TagsController implements ResourceHolder<Tag> {}                 // resolved through a trait

A supertype declaring more than one persistent entity is ambiguous and is skipped rather than guessed at, with the walk continuing upwards. If no controller declares the domain class, or more than one does, the link falls back to the domain class name.

Applies only when resource is given a domain instance and GORM is configured; passing a controller name directly (resource: "book") is unchanged.

An association still held as a lazy proxy is rendered from the domain class rather than the instance, to avoid loading it. A domain class passed to the resource attribute resolves through the same rule, so a proxied and a loaded association produce the same href.

[codecov]

Codecov Report

❌ Patch coverage is 88.70968% with 7 lines in your changes missing coverage. Please review.
✅ Project coverage is 54.7733%. Comparing base (c1b532a) to head (4555348).
⚠️ Report is 192 commits behind head on 8.0.x.

Files with missing lines	Patch %	Lines
...org/grails/web/mapping/DefaultLinkGenerator.groovy	88.5246%	2 Missing and 5 partials ⚠️

Additional details and impacted files

@@                Coverage Diff                 @@
##                8.0.x     #16272        +/-   ##
==================================================
+ Coverage     54.7365%   54.7733%   +0.0368%     
- Complexity      20470      20523        +53     
==================================================
  Files            2103       2103                
  Lines          101077     101135        +58     
  Branches        17928      17944        +16     
==================================================
+ Hits            55326      55395        +69     
+ Misses          37876      37863        -13     
- Partials         7875       7877         +2     

Files with missing lines	Coverage Δ
...ls/rest/render/util/AbstractLinkingRenderer.groovy	55.6962% <100.0000%> (ø)
...org/grails/web/mapping/DefaultLinkGenerator.groovy	83.3333% <88.5246%> (+2.6882%)	⬆️

... and 3 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[testlens-app]

✅ All tests passed ✅

🏷️ Commit: 4555348
▶️ Tests: 81061 executed
⚪️ Checks: 91/91 completed

---

Learn more about TestLens at testlens.app/docs.

[jdaugherty]

We should discuss this further on the weekly or mailing list. This assumes all applications use the same design here and it's formalizing something that may not be true for all applications. This is also a major shift, not necessarily a bad one, but it will require another milestone. Thus this should go into 8.1 or later.

[codeconsole]

Agreed — worth the weekly or the mailing list before this goes anywhere. No objection to holding it for a later milestone.

[bito-code-review]

The concern regarding the potential impact of this change on applications that do not follow the assumed naming conventions is noted. Since this introduces a shift in how resource links are resolved, it is reasonable to consider whether this should be targeted for a future milestone like 8.1 to allow for further discussion and validation across different application architectures.