Using Jboss Datasource files, JBoss 5.1

If you’re using jboss and you’re storing database connection info in a properties file, you might be doing something wrong. Specifically, you’re probably not using the data source files jboss ships with to configure all that plumbing.

What’s a Datasource file?

Simply put, its a file that contains all the connection properties an application needs in order to connect to a database in xml format. Here’s an example:


So, the “jndi-name” node gives this datasource configuration the jndi name it will be bound to while the server is running. We’ll need this later since we’ll be using jndi to fetch the datasource configuration. The “connection-url” is the jdbc connection string used to connect to the database; the “driver-class” sets the java driver used to load the database connectors; and the username/password nodes are self explanatory. The “metadata” node is optional, but its good to specify which mapping type jboss should use for this datasource; its job is to set which sql dialect constructs are used to map sql and data during an actual jdbc call. This file itself can be named anything, with the only limitation being that it needs to end with “-ds.xml”. The suffix pretty much flags jboss and lets it know to process the contents of the file as a datasource type. This file needs to be in the deploy directory for it to be loaded up.

Great, now we have a datasource file set up, how do we access it?

If you’re using ejb3, your persistence.xml file references the ds configuration by jndi-name. I’m pretty sure the hibernate configuration files do the same. If you’re using jdbc in your own homegrown persistence layer – gah, read on. Remember how we mapped the ds connection info with a jndi-name? We now get to use the InitialContext object to fetch the ds configuration by name via a jndi lookup:

 *	Returns a java.sql.Connection object, given the ds name to lookup
private Connection getDatasourceConnection(String jndiName) throws Exception { 

	// load the driver first
	String dsFile = "java:/DefaultDS"; 

	// sloppy, but just to show it can be done
	if(jndiName != null) {
		dsFile = jndiName;

	InitialContext ic = new InitialContext(); 
	DataSource ds = (DataSource) ic.lookup(dsFile); 

	// returns an object of java.sql.Connection
	return ds.getConnection(); 

What’s powerful about this is because you’re using a jndi name to lookup the datasource, you can set up multiple datasources and just call them by name when you need them. Send in the name of your ds config, and you get back a fully loaded java.sql.Connection object, ready to fire up jdbc calls. But.. jdbc was so.. Y2004…


If you’re using a legacy jdbc system (hard coded connection strings, ugly bundled properties files to hold connection settings, etc), porting your application to use datasource files could prove to be a worthwhile refactor, its so much cleaner. If you’re building an entirely new application though, take a look at ejb3 persistence, hibernate, they’re mature persistence frameworks that do a lot of the heavy lifting for you. There are others but these two stand out.

Comments (1)

  1. 5:33 AM, October 30, 2012Anand  / Reply

    Following should be corrected

Leave a Reply

Allowed Tags - You may use these HTML tags and attributes in your comment.

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>