[
https://issues.apache.org/jira/browse/WW-5286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17798121#comment-17798121
]
Kusal Kithul-Godage commented on WW-5286:
-----------------------------------------
I'm closing this card as this change would likely introduce unnecessary
complexity to the Struts codebase.
I've instead found a simple workaround that allows beans to survive the Guice
reload.
In our case, we specifically needed the VelocityManager to survive - by using
the existing extension point and using a lazy-load delegating pattern we were
able to achieve this without issue. It of course comes with the caveat that
stale configuration may persist in the VelocityManager even after a reload().
> Allow XWork configuration reloading at any time
> -----------------------------------------------
>
> Key: WW-5286
> URL: https://issues.apache.org/jira/browse/WW-5286
> Project: Struts 2
> Issue Type: Improvement
> Components: Core
> Affects Versions: 6.1.1
> Reporter: Kusal Kithul-Godage
> Priority: Minor
> Fix For: 7.0.0
>
>
> Currently, if a
> {{com.opensymphony.xwork2.config.ConfigurationManager#reload}}
> or
> {{com.opensymphony.xwork2.config.ConfigurationManager#reloadProviders}}
> are triggered, any Struts requests that are in the process of being served,
> or commence serving during the reload, will malfunction.
> To make reloading the container configuration safe at any time, the reload
> should wait until any commenced requests are finished serving, and should not
> commence serving any new requests until the container reload is complete.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
