getResourceAsStream() vs FileInputStream

Question

J’ai essayé de charger un fichier dans une application Web, et je recevais un exception lorsque j’ai utilisé . Cependant, en utilisant le même chemin, j’ai été en mesure de charger le fichier quand j’ai fait `` . Quelle est la différence entre les deux méthodes, et pourquoi une œuvre tandis que l’autre pas ?

Answer 1

L' java.io.File et consorts agit sur le disque local du système de fichiers. La cause racine de votre problème, c'est que par rapport chemins en java.io sont dépendants sur le répertoire de travail courant. I. e. le répertoire à partir duquel la JVM (dans votre cas: le serveur) est démarré. Cela peut par exemple être C:\Tomcat\bin ou quelque chose d'entièrement différent, mais pas C:\Tomcat\webapps\contextname ou tout ce que vous attendez qu'elle soit. Dans un projet Eclipse, qui serait C:\Eclipse\workspace\projectname. Vous pouvez en apprendre davantage sur le répertoire de travail courant de la façon suivante:

System.out.println(new File(".").getAbsolutePath());

Cependant, le répertoire de travail n'est en aucune façon par programme contrôlable. Vous devriez vraiment préfèrent utiliser absolue des chemins dans l' File API au lieu de chemins d'accès relatifs. E. g. C:\full\path\to\file.ext.

Vous ne voulez pas coder en dur, ou de deviner le chemin d'accès absolu en Java (web)des applications. C'est seulement la portabilité de la difficulté (c'est à dire qu'il fonctionne dans le système de X, mais pas dans le système Y). La pratique normale est de placer ces types de ressources dans le classpath, ajouter son chemin complet vers le chemin de la classe (dans un IDE comme Eclipse c'est l' src le dossier et le "build path", respectivement). De cette façon, vous pouvez les attraper avec l'aide de l' ClassLoader par ClassLoader#getResource() ou ClassLoader#getResourceAsStream(). Il est capable de localiser des fichiers par rapport à la "racine" du classpath, comme vous, par hasard, trouvé. Dans les applications (ou toute autre application qui utilise plusieurs chargeurs de classes), il est conseillé d'utiliser l' ClassLoader tel que retourné par la Thread.currentThread().getContextClassLoader() pour cette.

Une autre alternative à webapps est l' ServletContext#getResource() et son homologue ServletContext#getResourceAsStream(). Il est en mesure d'accéder à des fichiers situés dans le public web le dossier de la webapp projet, y compris l' /WEB-INF le dossier. L' ServletContext est disponible dans les servlets par les hérité getServletContext() méthode, vous pouvez l'appeler comme ça.

Answer 2

``est la bonne façon de le faire pour les applications web (comme vous l’avez déjà appris).

La raison est que la lecture du système de fichiers ne peut pas fonctionner si vous empaquetez votre application web dans une guerre. Il s’agit de la bonne façon d’empaqueter une application web. Il est portable ça, parce que vous n’êtes pas tributaire d’un chemin d’accès absolu au fichier ou l’emplacement d’installation de votre serveur d’applications.

Answer 3

FileInputStream chargera un le chemin du fichier vous passez au constructeur comme relatif depuis le Répertoire de travail du processus Java. Habituellement dans un conteneur web, c’est quelque chose comme le `` dossier.

``charge un fichier chemin d’accès relatif du classpath de votre application.

Answer 4

Le classe travaille directement avec le système de fichiers sous-jacent. Si le fichier en question n’est pas physiquement présent là, il échoue pour l’ouvrir. La méthode fonctionne différemment. Il essaie de localiser et de charger la ressource à l’aide du de la classe, il est appelé. Cela lui permet de trouver, par exemple, les ressources incorporées dans fichiers.

Answer 5

classname.getResourceAsStream() charge un fichier via le chargeur de classe de la classe classname. Si la classe provenait d’un fichier jar, qui est où la ressource sera chargée de.

FileInputStream est utilisé pour lire un fichier du système de fichiers.