Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 1.3
-
Fix Version/s: 1.3.2
-
Component/s: Core: (other)
-
Labels:None
-
Environment:
Windows XP, jdk 1.5.0_08
-
Similar Issues:None
Description
Using mule 1.3 final we are unable to properly set relative paths in mule endpoints due a strange behavior in how they are handled when the user.dir property is set "manually".
Background: due to the changes in the following commit paths are now resolved as relative to the "user.dir" system property; user.dir is automatically set by the service wrapper when mule is run as a server:
In our case mule is embedded in an existing spring application, loaded as a webapp. Since we need to use relative paths in the configuration we set the user.dir to be the webapp root before loading muleManager calling "System.setProperty("user.dir", root)" directly.
Unfortunately this doesn't make mule resolving paths relative to the new dir: various methods in java.io.File seems to resolve relative paths using the original user.dir if File.getCanonicalFile() is not called and this causes a very strange behavior in Mule.
For example this is what happens on the FileUtils.openDirectory(String directory) method, assuming:
- original user.dir set to "/user1"
- user.dir set using System.setProperty: "/user2"
public static File openDirectory(String directory) throws IOException
{
// here directory is "test"
File dir = new File(directory);
// dir.getAbsolutePath() returns "/user2/test" : ok
if (!dir.exists()) // dir.exists returns false..
// we found that this strangely looks for "/user1/test" also if the user.dir is now set to user2
if (!dir.isDirectory() || !dir.canRead())
// dir1 doesn't exist since isDirectory() looks for "/user1/test" while mkdirs created the correct "/user2/test" dir
... so the new user.dir is used when calling mkdirs(), while the original user dir is used when calling exists(), isDirectory() or canRead(). If the file is obtained using dir.getCanonicalFile() everything work as expected. After changing the first line in the method to:
File dir = new File(directory).getCanonicalFile();
the directory gets always resolved to the same user.dir.
In order to make Mule properly handle relative paths we had to add a getCanonicalFile() call in various mule classes (not sure if could be needed in some more class, this is what we had to fix in order to make our application work):
org.mule.util.FileUtils
org.mule.providers.file.FileMessageAdapter
org.mule.providers.file.FileMessageReceiver
org.mule.providers.file.transformers.FileToByteArray
I am not sure about the cause of this strange behavior in java.io.File, anybody else ever tried to set "user.dir" after the JVM startup? Do anybody see any problem in fixing the above methods/classes as described? I could supply a patch if needed, I would really like to be able to use relative paths without patching Mule 1.3.1 too 
just found out that this is due to a bug already traced in the sun bug database:
http://bugs.sun.com/bugdatabase/view_bug.do;:YfiG?bug_id=4117557
Work Arounds:
File dummy = new File("relativeFileName");
File realFile = new File(dummy.getAbsolutePath());