У меня есть приложение Java EE EE5 EJB3. Я разрабатываю с использованием NetBeans 6.7 и GlassFish 2.x. Мне нужен файл конфигурации (*.xsl, *.xml), специфичный для развертывания/клиента.
Мои вопросы:
1) куда класть файлы, которые являются внешними по отношению к файлу уха?
2) Как загрузить файлы в сеансовый компонент? можно ли использовать инъекцию?
Мне удается ввести @Resource для имени файла, используя ejb-jar.xml.
Спасибо заранее. ГРАММ.
Я думаю, это не то, что вы ожидаете, но правильный ответ: вам не следует этого делать! Согласно спецификациям EJB, а точнее Ограничениям программирования:
Корпоративный компонент не должен использовать пакет
java.ioдля доступа к файлам и каталогам в файловой системе.
И за этим утверждением следует такое объяснение:
API-интерфейсы файловой системы плохо подходят для доступа бизнес-компонентов к данным. Бизнес-компоненты должны использовать API-интерфейс менеджера ресурсов, например JDBC, для хранения данных.
Причины этого утверждения следующие:
Теперь, когда вы это знаете, если вы все еще хотите делать то, что имели в виду, и если ваш контейнер EJB не ограничивает использование классов из пакета java.io, тогда я бы поместил файл только для чтения в путь к классам, предпочтительно в JAR , и получить к нему доступ с помощью методов getResource() или getResourceAsStream() из java.lang.Class. Но на самом деле вы должны помнить о спецификации, она поможет вам создавать переносимые приложения.
Если вы можете собрать один EAR для каждого целевого развертывания (возможно, maven profile может помочь в этой области), то вы можете затем загрузить его как ресурс.
Другой вариант — ознакомиться с Спецификацией развертывания приложений J2EE (JSR-88 ), чтобы иметь один EAR с планом развертывания N для каждой среды.
Вы также можете решить сохранить файл в файловой системе (даже если это запрещено). Если вы хотите, чтобы путь был в ejb.xml то нужно опять же собирать или разворачивать EAR по разному - большого выигрыша тогда нет. Другой вариант — использовать пользовательский ресурс JNDI Glassfish, чтобы иметь возможность настроить путь прямо из консоли администратора. Ваше приложение. может загрузить файл в соответствии с настроенным путем.
См. этот вопрос: Обработка файлов в Java EE.
Спецификация запрещает доступ к файлам с помощью java.io, но не запрещает доступ к файлам вообще.
Одна из основных причин, по которой файлы вызывают проблемы в корпоративных приложениях, заключается в том, что их сложно безопасно и эффективно использовать в многопользовательской среде. В частности, блокировки файлов могут сильно ограничивать масштабируемость.
Использование загрузчика классов для чтения файла конфигурации один раз за сеанс, как это предлагает Pascal, вряд ли вызовет проблемы на большинстве серверов приложений, за исключением, возможно, случая горячего развертывания.
Свойства JNDI можно использовать в качестве альтернативы файлу конфигурации. Свойства JNDI определяются в дескрипторе развертывания и привязывают значение к имени JNDI во время развертывания. Приложение может искать значение внутри приложения, используя имя JNDI.
