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

Ответ 1

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

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

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

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

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

Ответ 2

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

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

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

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

Ответ 3

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

Ответ 4

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

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

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

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

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

Ответ 8

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