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Удачи в борьбе с ветряными мельниками.
- самокритично