Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

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

 
Clayton Cramer
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:



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
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Saloon Keeper
Pie
Posts: 18020
47
Android Eclipse IDE Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic