is there a standard way to define a JDBC Datasource for J2EE 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 J2EE 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 ?

Not as far as I know.

Will other containers at least accept the jboss way ? (/deploy/*-ds.xml)

I don't think so. At least, it's not the case of Glassfish.

EDIT

I suggest you try to start and stop the HSQL database from a ServletContextListener. This then resembles what is done in unit tests, when you start and stop the HSQL database in the setUp and tearDown. You could even try to create a datasource and bind it in the JNDI at the same time -- but I don't think you need this if all you want it to have a simple-to-install demo .ear.

Answer 2

This is servletcontainer specific and serveradmin responsibility.

Just document your webapplication so that a datasource with name X must be created for it. That's all.

Answer 3

Sun's J2EE philosophy defines several roles in the design, development and deployment of an enterprise application. J2EE's 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.

Answer 4

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.