is there a standard way to define a JDBC Datasource for Java EE containers?

Question

I know that for JBoss you need a [name]-ds.xml file in the /deploy subdirectory of the appropriate instance. i dont have any experience with other Java EE containers, but im trying to stick to standards as much as possible. is there a standard way to define a JDBC datasource and deploy it ? if possible i'd like to include my datasource inside the *.ear file (for instance, an embedded in-memory HSQLDB datasource for demo purposes) ?

if there is no standard way, will other containers at least accept the jboss way ? (/deploy/*-ds.xml)

Answer 1

Is there a standard way to define a JDBC datasource and deploy it?

Yes, there is. It's done via the <data-source> element, which you can put in web.xml, ejb-jar.xml and application.xml. If you don't like XML, you can also use an annotation for this instead: @DataSourceDefinition

Example of a web.xml entry

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

Further reading:

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

p.s. I'm surprised all other answers say this doesn't exist, while it clearly does, even at the time this question was originally asked.

Answer 2

Is there a standard way to define a JDBC datasource and deploy it ?

No, this is container specific. As Application Component Provider, you're supposed to document the resources you need and the Application deployer and Administrator will configure them.

If there is no standard way, will other containers at least accept the JBoss way?

No, because this is the JBoss way and thus JBoss specific.

• With Tomcat, you would have to use the context.xml file.
• With Jetty, jetty-env.xml.
• With WebSphere, you can create a so called WebSphere Enhanced EAR.
• With WebLogic, you can package a JDBC Module in your application.
• With GlassFish, you can use the command asadmin add-resources my.xml to add a datasource described in a XML file (example here).
• Etc, etc.

Note that there are some projects trying to achieve this goal in a universal way like jndi-resources or Cargo. There are also more complex solution like ControlTier or Chef.

Now, in your case (as I understood you want to use an embedded database that will be bundled with your application), I don't think you should configure a datasource at the application server level. You should just package the jar of your database in your application with a standalone connection pool like c3p0 or DBCP.

Answer 3

Sun's Java EE philosophy defines several roles in the design, development and deployment of an enterprise application. Java EE design accommodates and reflects these separations of concerns.

In particular Sun wants to separate the developer from the administrator of an application, which is a good idea. The developer writes enterprise components in a container-agnostic way. In web.xml, for example, you do declare your DataSources in a standard way:

<resource-ref>
 <res-ref-name>jdbc/myDB</res-ref-name>
 <res-type>javax.sql.DataSource</res-type>
 <res-auth>Container</res-auth>
</resource-ref>

This says "this database thing the application needs, make it available to me, whatever database is and whatever container you're running it in, via standard JNDI at 'jdbc/myDB' ". This is as much as the developer can do -- the rest is necessarily container specific and therefore not standardized.

And then how "myDB" is actually configured is up to a different role, the administrator of the container.

So I'm repeating the correct answer above: no. But the reason is, otherwise, you'd be coding your app to a specific type of database on a specific host and port, and the point is that you shouldn't be able to do that, so there's no standard support for that on purpose.