[ 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)