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

Question

Я знаю, что для JBoss вам нужен файл [name] -ds.xml в подкаталоге/deploy соответствующего экземпляра. У меня нет опыта с другими контейнерами Java EE, но я стараюсь придерживаться стандартов как можно больше. Существует стандартный способ определения источника данных JDBC и его развертывания? если возможно, я хотел бы включить свой источник данных в * .ear-файл (например, встроенный в источник данных HSQLDB в памяти для демонстрационных целей)?

Если нет стандартного способа, будут ли другие контейнеры, по крайней мере, принимать способ jboss? (/deploy/*-ds.xml)

Answer 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> 

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

• Introducing the DataSourceDefinition Annotation
• The state of @DataSourceDefinition in Java EE
• Example application use standard data source

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

Answer 2

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

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

Answer 3

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

Нет, это конкретный контейнер. Как Application Component Provider, вы должны документировать необходимые вам ресурсы, и Application deployer and 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-файле (пример here).
• И т.д. и т. Д.

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

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