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

Вы должны делать все в самом контейнере 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.

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

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

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

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