[jira] [Created] (WW-5671) Rename the OgnlCache abstraction to a neutral name now that it backs non-OGNL caches

["Lukasz Lenart (Jira)" <ji...@apache.org>]

Lukasz Lenart created WW-5671:
---------------------------------

             Summary: Rename the OgnlCache abstraction to a neutral name now that it backs non-OGNL caches
                 Key: WW-5671
                 URL: https://issues.apache.org/jira/browse/WW-5671
             Project: Struts 2
          Issue Type: Improvement
            Reporter: Lukasz Lenart
             Fix For: 7.4.0


Follow-up to WW-5668.

{{org.apache.struts2.ognl.OgnlCache}} and its factory started life as an OGNL-specific concern: caching parsed expressions and BeanInfo objects. It has since become the framework's general-purpose bounded-cache abstraction -- it also backs the proxy-detection cache, and as of WW-5668 the localized-text provider caches in {{org.apache.struts2.text}}.

The name and package no longer describe what it is. A developer reading {{AbstractLocalizedTextProvider}} now finds its resource-bundle cache typed as an {{OgnlCache}}, which suggests an OGNL relationship that does not exist. The same applies to the configuration constants that select an implementation.

Rename the abstraction to something neutral -- e.g. {{StrutsCache}} -- and move it out of the {{ognl}} package, so that the type describes a bounded, evicting cache rather than an OGNL detail. {{OgnlCacheFactory}}, {{DefaultOgnlCacheFactory}}, {{CacheType}} and the three implementations follow.

h2. Scope / acceptance
* The abstraction, its factory and its implementations carry a name that does not imply OGNL, and live outside the {{ognl}} package.
* All call sites are updated: OGNL expression and BeanInfo caches, proxy-detection cache, localized-text provider caches.
* Existing configuration constants and property names keep working; the OGNL-specific settings ({{struts.ognl.expressionCacheType}} and friends) are naming for a specific cache, not for the abstraction, and are out of scope here.
* The public types are part of the released API, so a minor release must keep the old names available as deprecated aliases delegating to the new ones. If a clean break is preferred instead, this should move to 8.0.0.
* No behavioural change.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)