Hi Greg,

Thank you! Yes this is an unforeseen bug emerged in 2.5.18 and already has 
fixed waiting for 2.5.19 release [1].

Regards

[1] https://issues.apache.org/jira/browse/WW-4974

>-----Original Message-----
>From: Greg Huber <gregh3...@gmail.com>
>Sent: Wednesday, December 26, 2018 12:02 PM
>To: Struts <dev@struts.apache.org>
>Subject: struts.configuration.xml.reload=true always reloads files
>
>struts.configuration.xml.reload=true always reloads files because when
>DefaultFileManager checks the revision it is always null.  The initial @inject 
>seems
>to be out of sequence.
>
>DefaultFileManagerFactory.getFileManager() is called from XWorkConverter
>which instantiates DefaultFileManager first:
>
>(See DefaultFileManagerFactory.getFileManager())
>
>@Inject
>    public void setFileManagerFactory(FileManagerFactory
>fileManagerFactory) {
>        this.fileManager = fileManagerFactory.getFileManager();
>    }
>
>The DefaultFileManager with not monitor the files as reloadingConfigs = false.
>
>com.opensymphony.xwork2.util.fs.DefaultFileManagerFactory is then @injected
>with reloadingConfigs = true.
>
>@Inject(value = StrutsConstants.STRUTS_CONFIGURATION_XML_RELOAD,
>required =
>false)
>    public void setReloadingConfigs(String reloadingConfigs) {
>        this.reloadingConfigs = Boolean.parseBoolean(reloadingConfigs);
>    }
>
>When it checks to reload the files using the revision it will always be null as
>reloadingConfigs = false when initially created in XWorkConverter, so will 
>reload
>the files.
>
>Some testing, and the only way seems to drop the check on reloadingConfigs and
>always monitor the files in DefaultFileManager :
>
>public InputStream loadFile(URL fileUrl) {
>        if (fileUrl == null) {
>            return null;
>        }
>        InputStream is = openFile(fileUrl);
>        //if (reloadingConfigs) {
>            monitorFile(fileUrl);
>        //}
>        return is;
>    }
>
>Adding an @Inject(value =
>StrutsConstants.STRUTS_CONFIGURATION_XML_RELOAD,
>required = false) to DefaultFileManager does not work as its too far down the
>@inject sequence.
>
>Maybe there is a sequence thing for the @inject to do the alter the order and 
>do
>DefaultFileManagerFactory first?
>
>Cheers Greg

Reply via email to