[
https://issues.apache.org/jira/browse/WW-5630?focusedWorklogId=1025103&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1025103
]
ASF GitHub Bot logged work on WW-5630:
--------------------------------------
Author: ASF GitHub Bot
Created on: 14/Jun/26 09:13
Start Date: 14/Jun/26 09:13
Worklog Time Spent: 10m
Work Description: lukaszlenart opened a new pull request, #1740:
URL: https://github.com/apache/struts/pull/1740
## Summary
Test-only cleanup of `ConfigParseUtilTest`, which was added in #1721 (the
class-validation caching introduced for
[WW-5630](https://issues.apache.org/jira/browse/WW-5630)). The production
caching logic in `ConfigParseUtil` is **unchanged** — this only improves the
test.
- **Collapse redundancy**: 12 overlapping cache tests → 5 focused ones
(single-loader caching, per-loader isolation incl. the same-`toString()` case,
outer-size bound, inner-size bound, and the negative/not-cached case).
- **Drop the ~80-entry literal**: the inner-cache size-bound test now
generates synthetic class names in a loop bounded by the per-loader limit (read
via the existing helper) instead of hardcoding a giant JDK class-name array.
- **Remove unnecessary reflection**: the three behavioral tests assert via
load counts only. Reflection is retained solely in the two size-bound tests,
where Caffeine exposes no public seam for `estimatedSize()`.
- **JUnit 3 → JUnit 4**: `@Test`/`@Before`/`@After` with static
`org.junit.Assert.*`, matching the convention of the newest standalone unit
tests in `core` (e.g. `ContainerHolderTest`, `NamedVariablePatternMatcherTest`).
Net: 90 insertions / 183 deletions, 12 tests → 5.
Fixes [WW-5630](https://issues.apache.org/jira/browse/WW-5630) test-quality
follow-up.
## Test Plan
- [x] `./mvnw -pl core clean test -Dtest=ConfigParseUtilTest` → `Tests run:
5, Failures: 0, Errors: 0, Skipped: 0`
- [x] `./mvnw -pl core apache-rat:check` → BUILD SUCCESS (license headers)
- [x] `core/src/main/java/org/apache/struts2/util/ConfigParseUtil.java`
unchanged
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Issue Time Tracking
-------------------
Worklog Id: (was: 1025103)
Time Spent: 1h 40m (was: 1.5h)
> Performance Issue SecurityMemberAccess
> --------------------------------------
>
> Key: WW-5630
> URL: https://issues.apache.org/jira/browse/WW-5630
> Project: Struts 2
> Issue Type: Bug
> Components: Value Stack
> Environment: Payara 7
> Reporter: Jose Miguel
> Priority: Major
> Fix For: 6.11.0, 7.2.0
>
> Attachments: image-2026-05-20-16-37-00-000.png
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> The Security hardening introduced some performance issues in a system
> multibranch (payara) where one single action is used to process thousand of
> files per minute. The action is using exctly same calls, parameters, and
> classes every call.
> Every call is loading classes, so, blocks the ClassLoader as can be seen in
> JDK Mission Control.
> There's no way to avoid this issue, played with several confi parameters,
> with no luck.
> Checking code, is not cached, it's suggested to cache The validation of
> classes, to avoid validate again and again the same class. the classes
> mostly validated again and again are: java.lang.Process
> org.apache.struts2.ActionContext
> java.lang.Runtime
> java.lang.Thread
> java.lang.ThreadLocal
>
> public static Set<Class<?>> validateClasses(Set<String> classNames,
> ClassLoader validatingClassLoader) throws ConfigurationException {
> Set<Class<?>> classes = new HashSet<>();
> for (String className : classNames) {
> try {
> classes.add(validatingClassLoader.loadClass(className));
> } catch (ClassNotFoundException e) {
> throw new ConfigurationException("Cannot load class for exclusion/exemption
> configuration: " + className, e);
> }
> }
> return classes;
> }
>
> !image-2026-05-20-16-37-00-000.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
