[
https://issues.apache.org/jira/browse/WW-5630?focusedWorklogId=1025108&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1025108
]
ASF GitHub Bot logged work on WW-5630:
--------------------------------------
Author: ASF GitHub Bot
Created on: 14/Jun/26 11:52
Start Date: 14/Jun/26 11:52
Worklog Time Spent: 10m
Work Description: lukaszlenart opened a new pull request, #1741:
URL: https://github.com/apache/struts/pull/1741
Port of #1740 to `support/struts-6-x-x`.
Test-only cleanup of `ConfigParseUtilTest` (added on 6.x via #1736,
cherry-pick of #1721):
- **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 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 newer `core` unit tests (e.g.
`NamedVariablePatternMatcherTest`).
- Also reorders the caffeine imports in `ConfigParseUtil.java` to
alphabetical (matching #1721 on main).
Production caching logic is **unchanged**.
## 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
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Issue Time Tracking
-------------------
Worklog Id: (was: 1025108)
Time Spent: 2h 20m (was: 2h 10m)
> 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: 2h 20m
> 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)
