Где/как хранить постоянные данные с помощью tomcat?

Где я могу хранить постоянные файлы в веб-приложении Tomcat?

  • javax.servlet.context.tempdir не представляется возможным, он удаляется, когда приложение перераспределяется/удаляется.
  • Не хотите использовать абсолютный путь, например. параметры инициализации сервлета
  • Сохранение файлов в базе данных не является параметром

Ответ 1

Наша команда делает это много. Общее правило, за которым мы следуем, находится вне веб-приложения и за пределами Tomcat.

Наш sysadmin настроил на нашем сервере каталог, на котором пользователь tomcat имеет права на rw (например, /var/tomcat/persist). У нас есть встроенная структура каталогов, в которой tomcat использует для хранения файлов, чтения файлов файлов, связанных с приложением, и т.д.

Если вы не хотите использовать абсолютный путь в своих init-params для вашего сервлета, подумайте о настройке системного свойства при запуске tomcat. Хорошо, что все приложения, работающие под управлением tomcat, будут иметь доступ к нему. Плохая вещь в том, что каждое приложение, работающее под управлением tomcat, будет иметь к нему доступ. Вы можете установить свойство с именем base.persist.dir и собрать подкаталоги для каждого приложения под ним. Мы устанавливаем свойства системы в файле setenv.sh script в каталоге bin/в переменной среды CATALINA_OPTS.

Ответ 2

Отвечая на заголовок вопроса, как насчет использования базы данных, DataSource и JDNI? Даже в контексте только для Интернета, запись в файлы с использованием java.io на самом деле не рекомендуется из-за concurrency, потоков, безопасности, кластеризации, проблем с переносимостью. Некоторые из этих проблем могут быть "обходными", но все же это не самая лучшая практика. Стандартный подход заключается в использовании базы данных, и я бы предложил пересмотреть этот вариант, бросив в микс "облегченную файлом" базу данных, такую ​​как HSQLBD или JavaDB.

(EDIT: по неизвестной причине база данных не является параметром. Использование JNDI или параметров контекста или параметров инициализации для прохождения абсолютного пути, которые являются менее худшими вариантами IMHO, также исключается. Для относительного пути, возможно, посмотрите в user.home или user.dir, затем - или любое другое системное свойство, которое вы могли бы передать в командной строке. Мне это не нравится, я бы этого не сделал, и это не решает вышеупомянутые проблемы, но это ваш выбор в конце концов.)

Ответ 3

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

Ответ 4

Как правило, это относится к базе данных. Но поскольку OP настаивает на том, чтобы не использовать базу данных, я бы попробовал другой подход:

  • Известный путь файловой системы: ${user.home}/.myapp. Приложения иногда используют это для, например, индексы поиска, которые могут быть пересчитаны на основе данных в базе данных. Возможно, для вашего прецедента вы можете использовать домашний пользователь.
  • Сохраните конфигурационный путь файловой системы в репозитории конфигурации, например, в базе данных или, возможно, Предпочтения Java (если вам не нравятся параметры инициализации сервлета). Коммерческие приложения, такие как Atlassian JIRA, используют настраиваемый (но абсолютный) путь к файловой системе, где хранятся вложения проблем. Если они не знают лучшего способа, я не знаю, кто это делает:)

Ответ 5

Обычно я предлагаю использовать базу данных для хранения постоянных данных и выставлять ее через DataSource.

Если вы не хотите этого делать, я думаю, вы могли бы рассмотреть использование системного свойства "user.home" (я видел, что это использовалось в нескольких случаях). Но... нет никаких гарантий, что ваш сервлет будет запущен с разрешением на доступ к записи, если вы не настроите его самостоятельно.