23

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)

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
radai
  • 23,949
  • 10
  • 71
  • 115

3 Answers3

30

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:

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.

Kalle Richter
  • 8,008
  • 26
  • 77
  • 177
Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
  • The question was about container-specific config, I believe? Like http://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/Connectors_on_JBoss-Configuring_JDBC_DataSources.html This isn't the equivalent of that if I understand the question correctly. But yeah you're right this is the right answer for 90% of cases -- it was a few months old at the time this was asked and I sure didn't know about it! – Sean Owen Apr 28 '13 at 11:23
  • 1
    @SeanOwen >`The question was about container-specific config, I believe` - I think Op asked for a standard way for something that could otherwise be done via container-specific config. I agree that at the time this mechanism was only a few months old, and the various vendors didn't really make a lot of noise about it. – Arjan Tijms Apr 28 '13 at 11:29
  • yup, OP was definitely looking for something like this :-) thank you very much Arjan. it does mean i need to go with exploded deployment to make the config easily accessible to scripts/tools, but its a very valid option. if you look at the date though, i was looking at ~2010 so j2ee6 wasnt really an option. – radai Apr 28 '13 at 14:41
  • 1
    @radai you're welcome! Note that I issued https://java.net/jira/browse/JAVAEE_SPEC-19 to address the configurability concern for among others the datasource in web.xml. If you or anyone else cares for this, please give it a vote ;) – Arjan Tijms Apr 28 '13 at 17:24
  • @ArjanTijms Where is the data-source tag docs? I ask because [TomEE](http://tomee.apache.org) is complaining that some elements are unsupported. – Gilberto Mar 11 '16 at 18:11
  • 1
    @Gilberto EE.5.18.3 (page 132) of the EE platform spec that you can download here: http://download.oracle.com/otndocs/jcp/java_ee-7-fr-eval-spec/index.html – Arjan Tijms Mar 13 '16 at 09:25
  • @ArjanTijms with help of Romain Manni-Bucau, the TomEE are making good progresses http://tomee-openejb.979440.n4.nabble.com/org-postgresql-xa-PGXADataSource-cannot-be-cast-to-java-sql-Driver-TomEE-7-0-0-M3-tp4678050.html – Gilberto Apr 04 '16 at 18:28
  • @Gilberto Thank you so much for reporting this with the TomEE guys! Great to see progress there :) Btw, Romain in one of his first comments is right about the custom properties not able to distinguish between datasource and pool. See https://java.net/projects/javaee-spec/lists/users/archive/2015-02/message/4 – Arjan Tijms May 05 '16 at 10:22
  • 1
    This doesn't seem to be official. The links you provide are from some blogs and Google fails to find anything else. Is there some reference documentation on this? Particularly the `web.xml` approach listing all the available `` elements and their semantics / possible values? – Marcus Junius Brutus Dec 30 '16 at 22:07
  • 2
    @MarcusJuniusBrutus you can find the reference here: http://download.oracle.com/otndocs/jcp/java_ee-7-fr-eval-spec/index.html See EE.5.18.3 (page 132). That's as official as it's going to get ;) – Arjan Tijms Dec 31 '16 at 18:14
  • Thank you. Where/how does [Example application use standard datasource](http://jdevelopment.nl/open-source/java-ee-kickoff-app)? I just don't get it... or maybe it has been updated. – Kalle Richter Oct 03 '17 at 13:50
  • The issue filed by @ArjanTijms is now on [GitHub](https://github.com/javaee/javaee-spec/issues/19) – m.sarhan Jan 31 '21 at 08:48
3

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.

Community
  • 1
  • 1
Pascal Thivent
  • 562,542
  • 136
  • 1,062
  • 1,124
  • 1
    >this is container specific. - No, it's not necessarily container specific. There is a standard way as well using the `` element in e.g. web.xml (see my answer below). – Arjan Tijms Apr 28 '13 at 09:33
  • Based on the accepted answer, it appears that it is not container-specific. – Greg Brown Aug 23 '18 at 18:53
  • ...although perhaps at the time you answered the question, it was container-specific. – Greg Brown Aug 23 '18 at 19:11
1

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.

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
Sean Owen
  • 66,182
  • 23
  • 141
  • 173
  • while youre right for the general case, in my case i plan on using an in-jvm, in-memory DB, with hibernate on top (think of it as an Object cache) - something i was hoping could be done in a portable fashion – radai Feb 17 '10 at 13:18
  • 2
    > which is a good idea - it's a good idea for some use cases, but not for all use cases. Java EE 6 started to provide alternatives (e.g. you can define a data source from within your app), and Java EE 7 has continued this trend (things like JMS destinations and mail sessions can be defined from the app as well). – Arjan Tijms Apr 28 '13 at 09:36
  • 2
    >you shouldn't be able to do that - The spec shouldn't mandate a one-and-only-one way of working. This explanation completely fails to take into account the existence of local, private (possibly in-memory) databases AND it doesn't scale down to the simplest of apps. Interfaces and separate modules for business logic might have been a best practice for some use cases, but enforcing it made EJB feel heavyweight. From Java EE 6 onwards, the choice is up to the developer (Interfaces and a separate EJB module are optional now). – Arjan Tijms Apr 28 '13 at 09:40
  • 2
    Other reasons for embedded datasources: agile teams, devops, cloud deployments, unit and integration tests, tutorials and demos, ... The list is endless... – Mike Braun Apr 28 '13 at 11:02
  • 2
    I was more just describing the Sun rationale here, which does feel somewhat antiquated now. Separation of concerns remains a good idea, and doesn't prevent you from packaging separate concerns at a higher level. As to whether it's worth the trouble -- still probably yes for a big app, probably not for small libraries and small dependencies. JavaEE hardly scales down, yes. The spec has to mandate a coherent architecture and way of working, I don't agree that it shouldn't, but it sure may not be suitable for all use cases. – Sean Owen Apr 28 '13 at 11:27