Существует ли стандартный способ определения источника данных JDBC для контейнеров Java EE?

Ответ 1

Существует ли стандартный способ определения источника данных JDBC и его развертывания?

Да, есть. Это делается с помощью элемента <data-source>, который можно поместить в web.xml, ejb-jar.xml и application.xml. Если вам не нравится XML, вы можете также использовать аннотацию для этого: @DataSourceDefinition

Пример записи в web.xml

<data-source>
    <name>java:app/myDS</name>
    <class-name>org.postgresql.xa.PGXADataSource</class-name>
    <server-name>pg.myserver.com</server-name>
    <database-name>my_db</database-name>
    <user>foo</user>
    <password>bla</password>
    <transactional>true</transactional>
    <isolation-level>TRANSACTION_READ_COMMITTED</isolation-level>
    <initial-pool-size>2</initial-pool-size>
    <max-pool-size>10</max-pool-size>
    <min-pool-size>5</min-pool-size>
    <max-statements>0</max-statements>
</data-source>

Дальнейшее чтение:

• Представление аннотации DataSourceDefinition
• Состояние @DataSourceDefinition в Java EE
• Пример использования стандартного источника данных

p.s. Я удивлен, что все другие ответы говорят, что этого не существует, хотя это ясно, даже в то время, когда этот вопрос изначально был задан.

Ответ 2

Существует ли стандартный способ определения источника данных JDBC и его развертывания?

Нет, это конкретный контейнер. Как Application Component Provider, вы должны документировать необходимые вам ресурсы и Application deployer и Administrator настроит их.

Если стандартного способа нет, будут ли другие контейнеры, по крайней мере, принимать способ JBoss?

Нет, потому что это способ JBoss и, следовательно, JBoss.

• С Tomcat вам придется использовать файл context.xml.
• С Jetty, jetty-env.xml.
• В WebSphere вы можете создать так называемый WebSphere Enhanced EAR.
• С помощью WebLogic вы можете упаковать JDBC Module в ваше приложение.
• С помощью GlassFish вы можете использовать команду asadmin add-resources my.xml, чтобы добавить источник данных, описанный в XML файле (пример здесь).
• Etc и т.д.

Обратите внимание, что есть некоторые проекты, пытающиеся достичь этой цели универсальным способом, например jndi-resources или Cargo. Существуют также более сложные решения, такие как ControlTier или Chef.

Теперь, в вашем случае (поскольку я понял, что вы хотите использовать встроенную базу данных, которая будет поставляться вместе с вашим приложением), я не думаю, что вам нужно настроить источник данных на уровне сервера приложений. Вы должны просто упаковать банку своей базы данных в свое приложение с помощью автономного пула подключений, например c3p0 или DBCP.

Ответ 3

Философия Sun Java EE определяет несколько ролей при разработке, разработке и развертывании корпоративного приложения. Конструкция Java EE учитывает и отражает эти проблемы.

В частности, Sun хочет отделить разработчика от администратора приложения, что является хорошей идеей. Разработчик записывает корпоративные компоненты контейнерно-агностическим способом. Например, в web.xml вы объявляете свои DataSources стандартным образом:

<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", зависит от другой роли, администратора контейнера.

Итак, я повторяю правильный ответ выше: нет. Но причина в том, что в противном случае вы будете кодировать свое приложение для определенного типа базы данных на конкретном хосте и порту, и дело в том, что вы не должны этого делать, поэтому нет стандартной поддержки для этого на цель.