Программисты Java EE не пишут в файлы

Сегодня один человек сказал мне, что "программисты Java EE не пишут в файлы". Почему я не могу писать в файлы из контейнера Java EE (например, из JBoss)? Что случилось?

8 ответов

Решение

Лучшая страница для просмотра: http://www.oracle.com/technetwork/java/restrictions-142267.html

Он подробно описывает ограничения по модели программирования Java EE.

Помимо пункта, упомянутого выше, безопасность, переносимость, кластеризация, многопоточность также учитывают транзакции и обработку ошибок (файловые системы не являются транзакционными).

Однако в JVM не происходит черной магии, и вы можете создавать файлы (если у вас есть соответствующие права), использовать статические переменные и создавать потоки, если вы знаете, что делаете.

Лучше найдите время, чтобы понять, почему обычно предлагаются эти ограничения, чем прыгнуть и написать JCA-коннектор ради совместимости.

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

  • нет уверенности в том, что любой последующий вызов EJB будет даже на том же физическом сервере с доступом к тем же файлам / файловой системе (например, при кластеризации)
  • нет возможности мешать друг другу (несколько приложений пытаются записать в один файл)
  • нет проблем с безопасностью (одно приложение записывает конфиденциальные данные, которые может прочитать другое приложение)

Вы также должны предположить, что вы не должны:

  • создайте свои собственные потоки (контейнер будет управлять этим для вас; если вы создаете свои собственные, вы можете голодать другие приложения в контейнере процессорного времени)
  • использовать socket-IO (также есть проблемы с безопасностью)

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

Согласно спецификациям Java EE, EJB-компонентам строго запрещается доступ к любым внешним ресурсам любыми способами, кроме как через "диспетчер ресурсов" (JDBC, JNDI, JCA и т. Д.), И это особенно касается доступа к локальной файловой системе через классы java.io пакет. Кроме того, не может ClassLoader использоваться для такого доступа, например, для загрузки файла свойств из пути к классам приложения.

Причины этого уже были приведены в других ответах:

  • Проблемы с безопасностью
  • Проблемы с переносимостью
  • Проблемы с кластеризацией
  • Проблемы с потоками

В конечном счете, лучшим ресурсом по этим вопросам является база данных.

Вы должны рассматривать файловую систему как корпоративную информационную систему (EIS). Затем вы можете создать ResourceAdapter, который обращается к этому EIS, аналогично адаптеру JDBC, который обращается к базе данных. Спецификация находится здесь: http://java.sun.com/j2ee/connector/download.html. Это означает, что доступ к файлу возможен, но намного сложнее. Эта спецификация даже позволяет вам создавать какие-то "потоки" под названием Work.

Если ваш экземпляр не кластеризован или вы можете гарантировать, что все экземпляры могут использовать сетевой диск, тогда на самом деле не проблема использовать File apis для чтения / записи файлов. Однако необходимо позаботиться о том, чтобы правильно проложить пути и как следует очистить. Зачастую нет необходимости писать файлы, поэтому подумайте еще раз. Основная причина, по которой большинство людей приводят, состоит в том, что в кластере разные серверы не видят один и тот же файл, потому что пути меняются и так далее. В конце концов, большинство небольших приложений не работают в таком кластере...

Потому что спецификация Java EE не предлагает API для записи файлов. Конечно, вы можете просто использовать обычный API Java IO для создания файлов, но вы должны убедиться, что этот код является поточно-ориентированным, что кто-то очищает файлы, что имя файла передается следующему бину, что файл переносится, когда ваш компонент перемещается на другой узел в кластере и т. д.

Так что, хотя вы можете сделать это, на практике вы столкнетесь с множеством небольших проблем, которые делают обработку файлов в Java EE действительно сложной.

Чтобы взаимодействовать с унаследованными системами, отличными от j2ee, вам иногда приходится делать "плохие вещи", такие как ввод / вывод сокетов, запись в файлы и т. Д. В лучшем из всех миров строго следовали бы спецификации j2ee, но люди все время сойдут с рук, не связанных с j2ee, ради целесообразности и выполнения своей работы. Есть способы безопасно и вдумчиво справиться с этим.

Другие вопросы по тегам