jamesfredley commented on issue #16122: URL: https://github.com/apache/grails-core/issues/16122#issuecomment-5243294166
### Ecosystem impact: narrower than the other two compatibility issues I scanned the released jars of 15 Grails plugins to see how many actually rely on the removed dynamic/map-style `Metadata` accessors, so this can be prioritised against the other findings. Detection note: my first attempt looked for a `grails/util/Metadata` class reference in the constant pool and produced a **false negative on the very plugin in this report** - `ConsoleController` contains the string `app.grails.version` but no `Metadata` class reference, because it obtains the metadata object indirectly rather than through a direct static call. So the reliable signal is the **metadata key string**, not the class reference. The results below use key strings, and they do correctly flag the known-failing plugin. | Plugin | Verdict | |---|---| | `org.grails.plugins:grails-web-console:7.1.0` | **LEGACY KEY** - `ConsoleController.class` contains `app.grails.version` | | `org.grails.plugins:grails-shiro:6.0.0` | weak only - `ShiroGrailsPlugin$_doWithSpring_closure2` references `app.name` / `info.app.` | | `audit-logging:6.0.0`, `grails-elasticsearch:5.1.0`, `grails-logical-delete:3.0.0`, `cache-ehcache:5.0.0-RC1`, `grails-cache-redis:6.0.0-RC1`, `grails-mail:5.0.3`, `grails-export:7.1.0`, `grails-quartz:4.0.1`, `grails-redis:5.0.1`, `sitemesh2:6.2.4`, `database-migration:9.0.0-M3`, `spring-security-core:7.0.0-M3`, `asynchronous-mail:3.1.2` | none | The Shiro result is a useful control: it reads metadata but through the supported accessor, and it loaded and wired correctly on 8.0.0-M5 in the same sweep. So "reads metadata" is not by itself a problem - only the removed dynamic/map-style access is. ### Takeaway Only one plugin in the sample is affected, so this is materially **lower impact** than the other two issues found in the same sweep (#16123 and #16124), and could reasonably be prioritised behind them. Two caveats before treating it as rare: - The heuristic detects literal metadata key strings. Code that builds a key dynamically, or reads a metadata value through some other indirection, would not be caught. - The failure mode remains the concerning part regardless of frequency: it is invisible at compile time and only appears when the code path is exercised at runtime, as a 500 with a `MissingPropertyException` that points at `grails.util.Metadata` rather than at the removal. Given that, documenting the removal in the upgrade guide may be worth doing even if a compatibility shim is judged unnecessary. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
