Stefaan Dutry created WW-4793:
---------------------------------
Summary: Don't add JBossFileManager as a possible FileManager when
not on JBoss
Key: WW-4793
URL: https://issues.apache.org/jira/browse/WW-4793
Project: Struts 2
Issue Type: Improvement
Components: Core
Affects Versions: 2.5.10
Reporter: Stefaan Dutry
Priority: Trivial
When the application starts and there is no FileManager specified as initParam,
the {{JBossFileManager}} gets added.
This results in the check happening everytime a FileManager is requested.
(When turning on logging, i can see it happening 12 times when starting a
simple application)
{code:java|title=org.apache.struts2.dispatcher.Dispatcher}
...
private void init_FileManager() throws ClassNotFoundException {
if (initParams.containsKey(StrutsConstants.STRUTS_FILE_MANAGER)) {
...
} else {
// add any other Struts 2 provided implementations of FileManager
configurationManager.addContainerProvider(new
FileManagerProvider(JBossFileManager.class, "jboss"));
}
...
}
...
{code}
{code:java|title=com.opensymphony.xwork2.util.fs.DefaultFileManagerFactory}
private FileManager lookupFileManager() {
Set<String> names = container.getInstanceNames(FileManager.class);
...
for (FileManager fm : internals) {
if (fm.support()) {
return fm;
}
}
return null;
}
{code}
My suggestion would be to not add it if it's not supported.
I don't know what the best way to do this would be.
The possibility i was thinking of so far involves the following:
* Creating a seperate utility class to check if it can support it
** perhaps a public static innerclass of {{JBossFileManager}} with public
static method(s) to check it?
** or a seperate class (although i think this might be awkward)
* adding a test around adding the JBossFileManager to only do it when it could
be supported.
additional information:
* log messages were noticed by adjusting the log4j2 configuration in the
{{form-processing}} application from {{struts-examples}} and starting it.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
