WW-5630 - Performance Issue SecurityMemberAccess

[brianandle]

No description provided.

[lukaszlenart]

Thanks for tackling WW-5630 — the motivation is solid. SecurityMemberAccess is Scope.PROTOTYPE (StrutsBeanSelectionProvider.java:454), so it's reconstructed on every value-stack creation (~per request), and each construction re-runs the @Inject use* setters → validateClasses → ClassLoader.loadClass(...). Memoizing that is worthwhile, and Caffeine is already a core dependency.

Two blocking issues before merge, both rooted in the cache key:

1. Key on classloader identity, not String.valueOf(classLoader). This can return a Class<?> from the wrong loader (collisions / constant toString()), and those Class objects feed OGNL exclusion/allowlist checks that rely on == — security-adjacent.
2. Static cache holding strong Class<?> values pins classloaders — relevant given the WW-5537 leak work on adjacent branches.

Both are solved together with Caffeine.newBuilder().maximumSize(...).weakKeys().weakValues().build() keyed on the real ClassLoader (e.g. Cache<ClassLoader, Cache<String, Class<?>>>). weakKeys() gives identity equality (fixes #1) and GC-safety (fixes #2). Details inline.

[brianandle]

@lukaszlenart I believe I've resolved all the concerns you raised and added additional UTs as well.

---

Test set: org.apache.struts2.util.ConfigParseUtilTest

Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 s -- in org.apache.struts2.util.ConfigParseUtilTest