This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
On my test Server 2003, the Servlet successfully reads files from the Tomcat\bin directory (files read from init() method).
On the test server, the Servlet works but fails to read the files (throws FileNotFound exception).
This exception will be thrown by the FileInputStream, FileOutputStream, and RandomAccessFile constructors when a file with the specified pathname does not exist. It will also be thrown by these constructors if the file does exist but for some reason is inaccessible, for example when an attempt is made to open a read-only file for writing.
Yes, carbon.oak is the file I am trying to open. I placed it in
and the Servlet can't find open the file.
Is there anywhere else the Servlet could be looking?
What is strange that it is opened fine in a similar Windows 2003 Server environment.
If you're attempting to reference the Tomcat binary directory on Linux, Solaris, AIX, or, well, any OS but Windows, it's going to fail if you say "tomcat\bin". Backslash separators ONLY work for Windows, and even there, they can be pretty dangerous when working with Java - you're better off saying "tomcat/bin", which works everywhere, including Windows.
However, I don't encourage putting user files in Tomcat's bin directory. Pick a place that isn't dedicated to a private purpose already.
Incidentally, if you want to read a file, don't plan on writing to the file and the file isn't expected to change, you can include it as a resource in your WAR and use the request getResourceAsStream to open an input stream on it.
One thing you should NEVER do is have a webapp write files into WARs, however!
An IDE is no substitute for an Intelligent Developer.
I am going to provide you with a totally different solution than any which has been discussed here.
If I read correctly, you need to read a file into your web application and you are going to port the file along with the application wherever you host it. First and foremost do not use hard-coded absolute path, as has been suggested by some. This will tie your application down to the exact directory structure and becomes useless on any other kind of requirement.
To open a file you are going to need absolute path to the file so we go about getting the absolute path (sounds contradictory , read on) without having to change the code or disturbing the application.
There is a method in ServletContext interface called getRealPath this method coverts the virtual path of the application into an absolute path depending on the App Server + OS at runtime. So regardless of where you have deployed the application, this method will always give you the absolute path to the context of your web app, plus you don't even have to bother about confusion of slash (/) or backslash (\). This method returns a string, which is appropriate for your situation.
So get the real path to the context, attach the filename (with subdirectories if that applies) and then open this using the normal IO methods.
Hope that helps
Never Remember the failure
Never Forget the mistake