I was trying to load a file in a webapp, and I was getting a FileNotFound exception when I used FileInputStream. However, using the same path, I was able to load the file when I did getResourceAsStream(). What is the difference between the two methods, and why does one work while the other doesn't?
views:
1181answers:
5
+1
A:
FileInputStream will load a the file path you pass to the constructor as relative from the working directory of the Java process. Usually in a web container, this is something like the bin folder.
getResourceAsStream() will load a file path relative from your application's classpath.
matt b
2010-02-22 00:57:14
+1
A:
The FileInputStream class works directly with the underlying file system. If the file in question is not physically present there, it will fail to open it. The getResourceAsStream() method works differently. It tries to locate and load the resource using the ClassLoader of the class it is called on. This enables it to find, for example, resources embedded into jar files.
Dirk
2010-02-22 00:57:59
Well, files within a jar are still physically "present" in a file system, just contained within other files
matt b
2010-02-22 01:30:42
Well, yes, of course. But they are usually not something seen as independent entities in the file system, unless you application happens to know about the `jar` file format and its implications. And in Java, the appropriate `ClassLoader` might have this knowledge, whereas a plain `FileInputStream` certainly has not.
Dirk
2010-02-22 09:36:37
+1
A:
classname.getResourceAsStream() loads a file via the classloader of classname. If the class came from a jar file, that is where the resource will be loaded from.
FileInputStream is used to read a file from the filesystem.
Lachlan Roche
2010-02-22 00:59:47
+2
A:
getResourceAsStream is the right way to do it for web apps (as you already learned).
The reason is that reading from the file system cannot work if you package your web app in a WAR. This is the proper way to package a web app. It's portable that way, because you aren't dependent on an absolute file path or the location where your app server is installed.
duffymo
2010-02-22 01:03:13
+1 - though "cannot work" is too strong. (Reading from the filesystem can be made to work, but doing it portably is a tricky ... and a lot more code, especially if the resource is in a JAR.)
Stephen C
2010-02-22 01:10:34
duffy, very nice answer and you explained what my mistake was, but BalusC went into a lot of detail - I think his answer would be helpful for people who'd like to know the inner details as well. Hope you don't mind me changing the accepted answer to his!
Vivin Paliath
2010-02-22 03:36:59
@Stephen - I don't think "cannot work" is too strong. Even something as simple as being deployed on two different servers with different paths to the app server will break it. The point is that you need to make your WAR as self-contained as possible. Your point is correct, but I'm going to stick to my wording.
duffymo
2010-02-22 10:58:45
+3
A:
The java.io.File and consorts acts on the local disk file system. The root cause of your problem is that relative paths in java.io are dependent on the current working directory. I.e. the directory from which the JVM (in your case: the webserver) is started. This may for example be C:/Tomcat/bin or something entirely different, but thus not C:/Tomcat/webapps/contextname or whatever you'd expect it to be. The working directory is in no way programmatically controllable. You should never use relative paths with them. Always use absolute paths. E.g. C:/full/path/to/file.ext.
You don't want to hardcode or guess the absolute path in Java (web)applications. That's only portability trouble. The normal practice is to place those kind of resoures in the classpath (or to add its full path to the classpath) and use ClassLoader#getResource() or ClassLoader#getResourceAsStream() instead. It is able to locate files relative to the "root" of the classpath, as you by coincidence figured out. In webapplications (or any other application which uses multiple classloaders) it's recommend to use the ClassLoader as returned by Thread.currentThread().getContextClassLoader() for this.
Another alternative in webapps is the ServletContext#getResource() and its counterpart ServletContext#getResourceAsStream(). It is able to access files located in the public web folder of the webapp project, including the /WEB-INF folder. The ServletContext is available in servlets by the inherited getServletContext() method, you can call it as-is. It however requires that the WAR is been exploded by the servletcontainer.
BalusC
2010-02-22 01:59:29