MyEclipse remote debugging and where does it think it is doing file access?

[Clayton Cramer]

I am starting to use MyEclipse to do remote debugging of a Tomcat7 application. It seems to work quite well...with one peculiar behavior.

The remote Tomcat7 application is running under Linux; MyEclipse is running on my PC. The problematic Java class attempts to open a file, and it is SUPPOSED to open it on the server. The problematic method is:

    public synchronized String getFileContents(String filePath)
        throws IOException {
        StringBuffer s = new StringBuffer();

        if (filePath.length() > 0) {
            File file = new File(filePath);
            System.out.println("file.exists=" + file.exists() + "; file.canRead=" + file.canRead());
            if (file.exists() && file.canRead()) {
                RandomAccessFile raf = new RandomAccessFile(file, "r");

                while (raf.getFilePointer() < raf.length()) {
                    s.append(raf.readLine() + "\n");
                }

                raf.close();
            } else {
                throw new IOException("File [" + filePath +
                    "] does not exist or can't be read");
            }
        }

        return s.toString();
    }

The problem is that file.exists() and file.canRead() are both returning false for a filePath that exists, and is readable. Curiously, when it executes File file = new File(filePath); , all the forward slashes in filePath are now \\, as though it thinks it is opening the file under Windows, and in the calling method, File.separator is \\, not /. I don't think this is just a matter of MyEclipse misdisplaying the file separators, because the File method is claiming that the file does not exist. Is there perhaps something that needs to be set somewhere to tell MyEclipse that when remote debugging, all file references are also remote?

[Anthony Roberts]

I haven't used remote debugging but, as Tomcat is actually running the code on the remote system, it will not be treating it as a Windows file. The debug client being on a Windows system will not affect that. It might affect the display of file paths, though. If the filePath parameter has forward slashes, then it will still have forward slashes when the "new File(filePath)" statement is executed, since it is just a String, with no file path behaviour. If you're viewing the "file" variable, then the local system may be displaying the file with Windows path separators. This suggests that the file does not exist, at least at the implied path. Maybe it isn't looking for the file in quite the location you expect?

Tony

[Tim Holloway]

The actual debugger is built into each JVM instance. What Eclipse is providing is simply a client to communicate with that debugger via a network connection (the Java JDK also comes with a command-line-based debug client app). So whatever your debugger sees will be relative to what the remote application sees, not what's on your debug console machine.

Do note, however, that use of relative paths in J2EE is a great way to get into trouble, debugger or not. So make sure that A) your file paths are absolute and B) The tomcat server instance userid has the necessary filesystem access rights.

[Clayton Cramer]

Tim Holloway wrote:The actual debugger is built into each JVM instance. What Eclipse is providing is simply a client to communicate with that debugger via a network connection (the Java JDK also comes with a command-line-based debug client app). So whatever your debugger sees will be relative to what the remote application sees, not what's on your debug console machine.

Do note, however, that use of relative paths in J2EE is a great way to get into trouble, debugger or not. So make sure that A) your file paths are absolute and B) The tomcat server instance userid has the necessary filesystem access rights.

I am using an absolute path to a file name, and that file exists, and is readable. Mystifying. I notice that when I call the File.exists method for the path, the File.exists method calls a getBooleanAttributes method that has the attribute WinNTFileSystem.