[
https://issues.apache.org/jira/browse/WW-5671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukasz Lenart updated WW-5671:
------------------------------
Component/s: Core
> 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
> Components: Core
> Reporter: Lukasz Lenart
> Priority: Major
> 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)
