И java.io.File
действует на локальной файловой системе диска. Основная причина вашей проблемы в том, что относительные пути в java.io
зависимости от текущего рабочего каталога. Т.е. каталог, из которого запускается JVM (в вашем случае это сервер). Например, это может быть C:\Tomcat\bin
или что-то совершенно другое, но, таким образом, нет, C:\Tomcat\webapps\contextname
или то, что вы ожидаете. В обычном проекте Eclipse это было бы C:\Eclipse\workspace\projectname
. Вы можете узнать о текущем рабочем каталоге следующим образом:
System.out.println(new File(".").getAbsolutePath());
Однако рабочий каталог никоим образом не является программно управляемым. Вы действительно должны предпочитать использовать абсолютные пути в File
API вместо относительных путей. Например C:\full\path\to\file.ext
.
Вы не хотите жестко кодировать или угадывать абсолютный путь в Java (веб) приложениях. Это только проблема переносимости (то есть она работает в системе X, но не в системе Y). Обычной практикой является размещение таких ресурсов в пути к классам или добавление их полного пути к пути к классам (в IDE, такой как Eclipse, это src
папка и «путь сборки» соответственно). Таким образом , вы можете получить их с помощью объекта с ClassLoader
помощью ClassLoader#getResource()
или ClassLoader#getResourceAsStream()
. Он может найти файлы относительно «корня» пути к классам, как вы случайно поняли. В веб-приложениях (или любых других приложениях, использующих несколько загрузчиков классов) рекомендуется использовать для этого ClassLoader
возвращаемое значение, Thread.currentThread().getContextClassLoader()
чтобы вы также могли смотреть «вне» контекста веб-приложения.
Другой альтернативой в веб-приложениях является ServletContext#getResource()
и его аналог ServletContext#getResourceAsStream()
. Он может получить доступ к файлам, расположенным в web
общей папке проекта webapp, включая эту /WEB-INF
папку. ServletContext
Доступен в сервлетах унаследованного getServletContext()
метода, вы можете назвать это как есть.
Смотрите также: