[
https://issues.apache.org/jira/browse/WW-5173?focusedWorklogId=784834&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-784834
]
ASF GitHub Bot logged work on WW-5173:
--------------------------------------
Author: ASF GitHub Bot
Created on: 25/Jun/22 21:21
Start Date: 25/Jun/22 21:21
Worklog Time Spent: 10m
Work Description: JCgH4164838Gh792C124B5 commented on PR #573:
URL: https://github.com/apache/struts/pull/573#issuecomment-1166363454
Hello @yasserzamani . Thanks for taking a look and providing feedback. 😄
I will attempt to respond to your question for more detail on the container
construction still using the default implementations. The information is based
on stepping through breakpoints using a sample application with a custom
expression cache factory configured.
The `Dispatcher` `init()` method container/configuration loading seems to
happen in two phases. Both phases invoke `DefaultConfiguration` methods, the
first pass-through calling `createBootstrapContainer()`, and then a second
pass-through calling `reloadConatiner()`.
For the "bootstrap" container, the `OgnlUtil` instance created has the
default cache factory instances injected, but those factories do not have any
configuration parameters set (just the default state, without injection) at
that point. Next, for the "reloaded" container, the `OgnlUtil` instance
created has the default factory instances injected, but this time with the
parameters that were set in configuration (size, LRU mode).
In neither case is the custom cache factory dependency recognized as being
present to be injected. In the test application, when
`container.getInstance(ExpressionCacheFactory.class,
container.getInstance(String.class,
StrutsConstants.STRUTS_OGNL_EXPRESSION_CACHE_FACTORY))` is called within an
action, it then returns the custom cache factory ... but the container has to
construct the instance at that point (being the first call generating the
custom factory instance).
So, the custom factory instance appears to be wired-up correctly, but
something is still missing. Maybe a `ContainerProvider` of some sort is needed
to allow for "early-binding" of something like this, or maybe something else,
but so far nothing I have tried has allowed for a custom cache factory
(expression, beaninfo) to be injected into the `OgnlUtil` singleton instance.
I am not sure what else to try at this point, something in my understanding
of the mechanism seems to be missing ... 😞
Issue Time Tracking
-------------------
Worklog Id: (was: 784834)
Time Spent: 40m (was: 0.5h)
> Implement additional OGNL cache configuration controls
> ------------------------------------------------------
>
> Key: WW-5173
> URL: https://issues.apache.org/jira/browse/WW-5173
> Project: Struts 2
> Issue Type: Improvement
> Components: Core
> Affects Versions: 6.0.0
> Reporter: James Chaplin
> Priority: Minor
> Fix For: 6.0.1
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> With Struts 2.6, there may be an opportunity to introduce some additional
> OGNL cache configuration capabilities. One idea is to provide an cache size
> control, and a toggle for an LRU cache mode. These configuration controls
> could be applied to the expression cache and BeanInfo caches independently.
> The new properties could be optional, with the framework using a standard
> default cache if the properties are not provided.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
