Такой параметр приложения, например, как строка соединения, в виду удобства изменения, рекомендуется хранить в отдельном файле.
Вопрос в том, где лучше хранить этот файл и как получать к нему доступ?

Что имеется в виду.
В конечном итоге, приложение будет запаковано, например, в war- или ear-архив и будет помещено (развернуто) в рабочую директорию сервера приложений.

Насколько я сейчас понимаю, из кода мы можем получать доступ к файлам только по абсолютным или относительным путям по отношению к доступным для сервера приложений дискам.
То есть, условно говоря, если архив приложения лежит в директории D:\upload\ , то относительный путь ../ выведет нас в корень диска D, другими словами, используемые в коде относительные пути никак не связаны со структурой каталогов приложения в его архиве.

Не знаю, как это обычно делается, поэтому предполагаю, что было бы удобным хранить конфигурационный файл со строкой соединения в самом архиве приложения, оттуда и считывать, 
тогда при необходимости модификации, открываешь этот архив, изменяешь этот файл, приложение начинает работать с другой строкой соединения, то есть приложение и его конфигурационный файл в одном месте (в архиве приложения).
Иначе пришлось бы иметь на руках как архив приложения, так и конфигурационный файл, 
архив деплоить на сервер приложений, конфигурационный файл дополнительно размещать в какой-нибудь директории диска.

Если так, то непонятно как получать доступ к этом файлу.

Наилучшим способом видится использование относительных путей, наподобие того, как если page1.jsp и page2.jsp имеют одно расположение в архиве, то <%@ include file="page2.jsp" %> позволит включить page2 в page1, 
но при работе с файлами такие относительные пути не прокатывают.

В общем, прошу направить в нужном направлении как это всё делается.





Это сообщение отредактировал(а) jah2 - 8.5.2013, 22:21

Это действительно несколько неловкий момент. Дело в том, что разные сервера приложений по-разному формируют свои classpath'ы и, соответственно, по-разному разрешают относительные пути. Например, у JBoss можно положить конфиг в server/your_configuration/config/ и доступаться к нему через путь ./my_config.properties. А вот в Glassfish 2, например, мы клали конфиги в my_domain/lib/classes, чтобы они были доступны по аналогичному пути.

Держать же конфиги в архиве - плохой путь, слишком велико неудобство модификации и вероятность ошибки юзера (запакует war zip-архиватором со сжатием - и сгорим в кислороде).

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

хотя я не совсем представляю такой момент: 
каждый сервер приложений предоставляет некоторое местоположение для хранения конфигурационных файлов развёртываемых на нём приложений и способ доступа к этим файлам, так это нужно понимать?

Проблема, наверное не в месте хранения настроек, а в желании их редактировать "на лету".



Откуда приложение знает, что файл изменился? А если узнает, оно умеет корректно переключаться, т.е. завершать все текущие задачи со старым соединением, а потом продолжать с новым соединением? 

Стандартным конфигурационным файлом является web.xml (по крайней мере, в Томкате). Чтобы изменить настройки, надо удалить war из webapps (undeploy), отредактировать web.xml внутри war, положить war в webapps (deploy). В этот момент новые настройки вступят в силу. Это неудобно, но контейнер (Томкат) сам может сделать корректный undeploy, т.е. дождаться когда текущие запросы к приложению обработаются (а новые не принимать), и только после этого выключить приложение.

COVD, в данном случае я рассматриваю более простые изменения
например, даёшь админу war-архив и говоришь, что вот здесь в отдельном файле пропишешь строку соединения (приложение соответственно подхватит эту строку из этого файла и для того, чтобы поменять эту строку, не нужно будет лезть в приложение)

Добавлено через 4 минуты и 56 секунд
была мысль дать возможность настройки при входе с админскими правами, но всё равно придётся сохранять их где-то во внешнем файле по отношению к архиву приложения, то есть это жёстко привяжет приложение к выбранному расположению этого настроечного файла

хотя я собственно этот вариант и имел в виду сначала: хранить настройки в самом архиве (batigoal, сказал, что не стоит   )
и если говоришь, как-то можно взять данные из web.xml (я думал там размещаются только некие стандартные заранее определённые настройки), то это хорошо, прогуглю эту тему, спасибо

А что не так со сжатием?

Кто-нибудь знает и может намекнуть как взять данные из xml-файла, находящегося в архиве приложения (например, из того же web.xml)?
Прогугливаю эту тему, пока не могу найти ничего похожего, поосвоился даже с xml-парсерами, но в них также используются пути, завязанные на расположение на самом диске, но не в архиве приложения.
Обращаться к самому архиву, как он расположен на диске в рабочей директории сервера приложений, не вижу смысла, так как это привяжет приложение к расположению самого сервера приложений.

getResourceAsStream()



Уж не знаю какие парсеры ты смотрел, но стандартные DOM, SAX, JAXB принимают на вход в том числе и InputStream.

LSD, их смотрел (кроме jaxb) + jdom, но там пути также указываются не по отношению к тому как они располагаются в архиве приложения.
Например, у меня есть war-архив и мне нужно в index.jsp получить данные из web.xml в том же архиве, путь WEB-INF/web.xml не укажет мне на этот файл.

LSD, может я что-то принципиальное не понимаю в InputStream
сейчас для того, чтобы обратиться к файлу я бы стал использовать FileInputStream, передав ему, например, путь к файлу, но опять же это путь по отношению к диску, а не к тем расположениям, которые есть в архиве приложения
какой момент я здесь не догоняю, что нужно использовать у InputStream, чтобы получить доступ к файлу в архиве?

это если он в classpath, если нет то смотреть в сторону ZipFile (можно и ZipInputStream, но это сложнее).

так про то и речь, что смысла обращаться к архиву приложения по его расположению на диске смысла нет, так как при переносе на другой сервер приложений путь изменится и обратиться по этому пути к файлу уже не будет возможности
хотя бы если этот архив разворачивался в реальные директории на диске, тогда стандартные .. позволили бы выйти  на уровень вверх, но, например, на weblogic они выведут в основную директорию домена экземпляра сервера приложений, то есть совсем не туда, куда хотелось бы

jah2
Если вы пытаетесь извлечь параметры из web.xml, то надо там описать параметры и класс - лисенер.



Класс, который получит сообщения на deploy и undeploy