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)

Reply via email to