существует ли стандартный способ определить Источник данных JDBC для Java контейнеры EE?
Я знаю, что для JBoss Вам нужно [имя], файл -ds.xml в / развертывает подкаталог соответствующего экземпляра. у меня нет опыта с другим Java контейнерами EE, но я пытаюсь придерживаться стандартов как можно больше. существует ли стандартный способ определить источник данных JDBC и развернуть его? если возможный я хотел бы включать свой источник данных в *.ear файле (например, встроенный источник данных HSQLDB в оперативной памяти в демонстрационных целях)?
если не будет никакого стандартного пути, то другие контейнеры, по крайней мере, примут jboss путь? (/deploy/*-ds.xml)
2 ответа
Существует ли стандартный способ определения источника данных JDBC и его развертывания?
Нет, это зависит от контейнера. Как поставщик компонентов приложения , вы должны задокументировать необходимые ресурсы, а разработчик приложения и администратор настроят их.
Если нет стандартного способа, будут ли другие контейнеры хотя бы принимать путь JBoss?
Нет, потому что это способ JBoss и, следовательно, специфичный для JBoss.
- В Tomcat вам нужно будет использовать файл
context.xml. - С Jetty,
jetty-env.xml. - С помощью WebSphere вы можете создать так называемый WebSphere Enhanced EAR .
- С помощью WebLogic вы можете упаковать JDBC-модуль в свое приложение.
- В GlassFish вы можете использовать команду
asadmin add-resources my.xml, чтобы добавить источник данных, описанный в XML-файле (пример здесь ). - И т. Д.
Обратите внимание, что есть несколько проектов, пытающихся достичь этой цели универсальным способом, например jndi-resources или Cargo . Есть также более сложные решения, такие как ControlTier или Chef .
Теперь, в вашем случае (как я понял, вы хотите использовать встроенную базу данных, которая будет связана с вашим приложением), я не думаю, что вам следует настраивать источник данных на уровне сервера приложений. Вам нужно просто упаковать банку своей базы данных в свое приложение с автономным пулом соединений, например c3p0 или DBCP.
Философия Sun Java EE определяет несколько ролей в проектировании, разработке и развертывании корпоративных приложений. Дизайн Java EE учитывает и отражает такое разделение проблем.
В частности, Sun хочет отделить разработчика от администратора приложения, что является хорошей идеей. Разработчик пишет корпоративные компоненты независимо от контейнера. В web.xml, например, вы объявляете свои источники данных стандартным способом:
<resource-ref>
<res-ref-name>jdbc/myDB</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
Здесь говорится: «Эта база данных, которая нужна приложению, сделайте ее доступной для меня, независимо от того, какая база данных и в каком контейнере вы ее запускаете, через стандартный JNDI в 'jdbc / myDB' ». Это все, что может сделать разработчик - остальное обязательно зависит от контейнера и, следовательно, не стандартизировано.
И то, как фактически настраивается myDB, зависит от другой роли, администратора контейнера.
Итак, я повторяю правильный ответ выше: нет. Но причина в том, что в противном случае вы бы кодировали свое приложение для определенного типа базы данных на определенном хосте и порту, и дело в том, что у вас не должно быть такой возможности, поэтому нет стандартной поддержки для этого на цель.