max_from_sumy
уже только ленивый не знает, что вытягивать с помощью getRealPath ресурсы (как видимо хочет автор топика) вообще неправильно

1

2
- в приведенных топиках никто не сумел ответить на вопрос как писать в файл, не используя getRealPath()

- getRealPath нормально работает если приложение при деплое распаковывается из WAR-архива, что зависит от настроек контейнера сервлетов (например в Tomcat настройка контекста unpackWAR )

ненавижу хибернейт
товарищ Blazkowicz подсказывал решение как получить путь.
- ну и где? Еще раз внимательно перечитал оба топика и нашел там единственный кусок кода:
- но это не получение пути к файлу, а получение потока чтения, связаного с файлом.

no13 Kachalov
- в приведенных топиках никто не сумел ответить на вопрос как писать в файл, не используя getRealPath()
А зачем? Почему надо писать именно туда?
- когда не знаешь как, спроси зачем :)

- предположим хочу что-то (что угодно, например сериализованые объекты) сохранять в папке WEB-INF. Вопрос: как получить физический путь к этой папке не используя getRealPath()? Я понимаю что вопрос почти философский, т. е. в соответствии с идеологией JavaEE наверное надо сделать ресурс, зарегистрировать его в JNDI и уже после этого использовать в приложении, но это в больших проектах, а если надо сделать небольшой сайт на JSP? Тоже париться с JNDI или "хранить все в базе" (еще один популярный совет)? Есть определенный класс задач (с определенными ограничениями типа распаковки WAR) где getRealPath() (если он такой "вообще неправильный" почему он не deprecated?) вполне имеет право на существование.

- собственно я, в отличие от некоторых других участников беседы, не говорю что getRealPath() "вообще правильный" метод, но если говоришь "А", скажи и "Б", т. е. расскажите как "правильно" получить абсолютный путь к файлу из web-приложения.

no13
Можно придумать задачу, которой нужен указатель структуру в памяти, и засіпать форумы всех вопросами "как получить указатель в java". ;)
- когда не знаешь как, переведи разговор на другую тему :)

ненавижу хибернейт
тогда вот так:
getServlet().getServletContext().getResource("/");
а getRealPath(), в общем случае, работать не будет.
- надеюсь Вы сами пробовали такой вариант. У меня он дает результат:
jndi:/localhost/testapp/ (testapp - имя тестового web-приложения).

При попытке открыть URL (типа: jndi:/localhost/testapp/WEB-INF/test.txt) на запись получаем:
java.net.UnknownServiceException: protocol doesn't support output

KachalovВопрос: как получить физический путь к этой папке не используя getRealPath()?

no13когда лень делать как надо, можно доказывать что твой путь самый правильный, а все остальные неправы

- ну скажите дураку как надо осуществлять запись в файл из web-приложения не используя getRealPath(), а то Вы уже третий пост в этой теме пишите, а еще ни одной строчки кода.

rimanА что выдаст this.getClass().getResource("/"); ?
file:/D:/server/tomcat/work/Catalina/localhost/testapp/WEB-INF/classes/
- но это путь к временной папке куда распакуется (Tomcat все же распакует архив) приложение

riman Kachalov rimanА что выдаст this.getClass().getResource("/"); ?
file:/D:/server/tomcat/work/Catalina/localhost/testapp/WEB-INF/classes/
- но это путь к временной папке куда распакуется (Tomcat все же распакует архив) приложение
well...
А разве можно писать файлы внутрь war'a?
- практически, ни разу не слышал :)

- однако все равно вопрос открыт, при андеплое приложения временная папка куда приложение теоретически может писать данные (еще неизвестно какие настройки у SecurityManager-а) пропадет вместе со всеми данными, так что либо приложение надо хранить в распакованном виде и тогда работает getRealPath(), либо доступ к файловому ресурсу надо осуществлять предварительно зарегистрировав его в JNDI и располагая его в отдельной папке физически не связанной с приложением.

Deadyвообще писать внутри томката имхо бред собачий.
- совершенно с Вами согласен

Deadyдолжнен быть отдельный
ресурс для этого, где-нить в /var/www/tomcat/app/

- в том то и вопрос, где? и как туда добраться для записи?

Deady
где - в любом месте на сервере. как добраться - или в конфе путь хранить (web.xml), или в БД, или в JNDI.
- мне это понятно. Обсужадемая проблема заключается в том что хочется создать приложение которое легко переносится с сервера на сервер, самостоятельно определяя физический путь к домашней директории, а не прописывая его каждый раз ручками в конфигах. Для определения пути можно использовать getRealPath(), который работает "почти" всегда (за исключением случаев, когда приложение хранится в виде WAR-архива), однако некоторые участники обсуждения считают этот метод не кошерным из-за того самого "почти".

- как решается проблема с точки зрения "нераспаковщиков" понятно, собственно очевидны два варианта решения:

1) зарегистрировать папку как ресурс в JNDI или LDAP и переложить проблему на того кто будет развертывать приложение

2) хранить все изменяемые ресурсы в БД

Оба решения, IMHO, имеют недостатки для определенного круга задач. В первом случае для небольших приложений возникают неоправданно сложные настройки. Во втором случае появляется необходимость пропускать все данные через БД и сервлет, что не здорово при показе картинок на ресурсе с большой посещаемостью.

Мне кажется что при условии распаковки приложения getRealPath() это нормальный метод и предавать его анафеме не стоит, так как он позволяет просто решить задачу доступа к ресурсу на запись.

VoDA
Первое: в джаве нет "директории откуда запущено приложение", ибо кроссплатформенность и т.п. (приложение не знает на какой платформе работает). Есть только относительные... остальное своеобразные хаки системы.
- в web-программировании со времен CGI есть понятие DOCUMENT_ROOT - абсолютный физический путь к домашней директории сайта. Если разработчики контейнеров сервлетов (и Sun как создатель спецификации) допускают невозможность получить физический путь к домашней директории сайта (собственно уничтожают такое понятие), то они дают лишний аргумент сторонникам разработки web-приложений на других языках.

VoDA
Второе: web-приложение не должно иметь доступа на запись... особенно в директорию web-server'a.
- кто сказал, что приложение не должно иметь права на запись? А куда сохранять картинки? В базу? А как поступать с CMS которые генерируют статические HTML страницы? Исключить как класс когда программируешь на Java?

VoDA
Третье: вы уверены, что нужно писать в нечто найденное по jndi ?
- посмотрите топик с начала. Это мне ненавижу хибернейт посоветовал, а писать туда мне лично не удалось.

VoDA
Итог: если нужно что-то записывать на сервере - ТОЛЬКО в СУБД.
- после таких советов, начинаются разговоры о "тормознутости" Java сайтов и необходимости использования отдельного сервера для Java-сайта

VoDAPS опиши задачу конкретнее - может и получишь внятный ответ.
- getRealPath() и требование распаковки приложения при деплое (кстати у Tomcat это свойство по дефолту)

skipper13 Kachalov...ну скажите дураку как надо осуществлять запись в файл из web-приложения не используя getRealPath(), а то Вы уже третий пост в этой теме пишите, а еще ни одной строчки кода.
Ответ прост - а не надо туда писать.
- еще один любитель писать в базу, больше ничего полезного из Вашего поста извлечь не сумел (извините за скудоумие и неспособность понять эзотерическое знание).

- откуда у жителей Харькова такая уверенность в том как делать "надо", а как "не надо"? Чем подтверждается Ваше утверждение? Какими то разумными доводами или, может быть, большим опытом web-программирования (посмотрел на Ваш сайт ...)? Напишите в компанию Sun и укажите им как "надо", пусть они объявят метод getRealPath() как deprecated :)

no13Удачи в борьбе с ветряными мельниками.
- самокритично

VoDA
ИМХО для каждой задачи свои языки более предпочтительны.

Если вам нужно работать на Java, то стоит изучить как правильно его использовать. А если нужно сваять сайтик на 5 страниц - PHP вам в руки. Java начнет выигрывать на сложной бизнес-логике или когда количество разработчиков превысит 5-7 или когда ... ;)

- "не надо делать сложным, то что проще простого" © Nautilus

- не хотел писать, так как по существу вопроса все уже высказались и ничего нового, по моему добавить уже нельзя, но советы типа "стоит изучить как правильно его использовать" просто задолбали, каждый студент сегодня знает как правильно и какие методы не надо использовать. Нельзя ли быть более вежливым к собеседнику? Откуда такая категоричность? Если метод объявлен как deprecated его действительно не стоит использовать, иначе, пожалуйста, не забывайте добавлять "IMHO".