[
http://jira.jboss.com/jira/browse/JBAS-3433?page=comments#action_12340834 ]
Ralph Apel commented on JBAS-3433:
----------------------------------
In my opinion, the cause of the reported and perhaps other similar issues may be tracked
down to
system/src/main/org/jboss/system/server/ServerConfigImpl.java
Here, several File and URL objects are created without canonicalization. For example, take
the "getServerTempDir()" method, which is the relevant one for the reported
issues:
public File getServerTempDir()
{
if (serverTempDir == null)
{
serverTempDir = getFile(ServerConfig.SERVER_TEMP_DIR);
if (serverTempDir == null)
{
serverTempDir = new File(getServerHomeDir(),
ServerConfig.SERVER_TEMP_DIR_SUFFIX);
System.setProperty(ServerConfig.SERVER_TEMP_DIR, serverTempDir.toString());
}
}
return serverTempDir;
}
In the described cases, this method will simply append SERVER_TEMP_DIR_SUFFIX to the
return value of getServerHomeDir() and proceed without considering canonicalization.
But in the described cases, symlinks involved in serverHomeDir were correctly resolved for
their canonical path. Why?
The corresponding method reads:
public File getServerHomeDir()
{
if (serverHomeDir == null)
{
serverHomeDir = getFile(ServerConfig.SERVER_HOME_DIR);
if (serverHomeDir == null)
{
serverHomeDir = new File(getServerBaseDir(), getServerName());
System.setProperty(ServerConfig.SERVER_HOME_DIR, serverHomeDir.toString());
}
}
return serverHomeDir;
}
The crucial difference lies in the call to getFile(). The getFile method DOES consider
canonicalization, by calling getCanonicalFile() as
private File getFile(final String name)
{
String value = props.getProperty(name, null);
if (value != null)
{
try
{
File f = new File(value);
return f.getCanonicalFile();
}
catch(IOException e)
{
return new File(value);
}
}
return null;
}
In conclusion, for each line of code like
fileVar = new File(args,..);
I would add a line like
fileVar = fileVar.getCanonicalFile();
at least in class
org.jboss.system.server.ServerConfigImpl
Canonical paths enforced inconsistently
---------------------------------------
Key: JBAS-3433
URL:
http://jira.jboss.com/jira/browse/JBAS-3433
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Deployment services
Affects Versions: JBossAS-4.0.4.GA
Environment: Linux/Unix
Reporter: Ralph Apel
Assigned To: Dimitris Andreadis
Attachments: JBAS-3433-Case1.txt, JBAS-3433-Case2.txt, JBAS-3433-Case3.txt,
JBAS-3433-Case4.txt
DeploymentInfo objects are created with file-URLs without previously canonicalizing the
file's path.
If the original URL wasn't canonical (e.g. with Linux/Unix symlinks involved), this
discrepancy leads to failure of at least EjbUtil's resolution of ejb-link:
The URL to be searched for among DeploymentInfos by the MBeanServer is constructed from
the canonicalized path, but the DeploymentInfo which should be found has a
non canonical file URL (i.e. without symlinks resolved).
I have been able to provisionally solve this issue by patching EjbUtil to not invoke
target = Strings.toURL(ourPath);
(which directly or indirectly calls getCanonicalPath()) but a particular code fragment
instead.
This kind of solution surely isn't the right one. IMO, as the DeploymentInfo.url
field is used as a key to the DeploymentInfo collections, this key should be always
unique, i.e. canonicalized.
My suggestion would be to change any DeploymentInfo instantiation AND any search for
DeploymentInfo instances to use canonicalized file URLs.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira