Writeup of what I did December 2016 in order to configure a datasource in JBoss EAP 6. Actually tested and verified in JBoss EAP 6.2 and 6.4
The configuration of a datasource may require two distinct steps:
I followed a kind of amalgam between the instructions found here and here. Apparently these instructions are equally applicable to JBoss EAP 6 and/or 7. Furthermore, in my particular case, the database I was trying to connect to was a Sybase ASE 15 (or 16, am not sure at the moment) so the exotic factor is high.
You can checkout this playground project of mine for a solution implementing what is described here.
In accordance with what is expected from a JDBC jar, it contains a file java.sql.Driver in the META-INF/services directory:
$ jar tvf jtds-1.3.1.jar | grep Driver 33 Sat Jun 08 18:22:50 EDT 2013 META-INF/services/java.sql.Driver… which spells out the class name of the driver, in our case: net.sourceforge.jtds.jdbc.Driver
NB: I added the dependency in my ivy.xml file only temporarily as the JDBC driver is not bundled with the WAR in this method — instead it is created as a module in JBoss (see below).
mkdir -p net/sourceforge/jtds/jdbc/main… and did cd there.
NB: the main in the above directory path is artificial but it is important that the directory branch ends with main. The remaining levels are taken from the package structure inside the driver's JAR all the way to the sub-package where the JDBC driver class is defined. However, I am not sure one has to go all the way there and whether the directory structure is not just a convention to ensure segregation of modules. In the latter case it may have been equally valid to create the module directory as net/sourceforge (if we are confident we aren't going to host any other modules from net.sourceforge) or even some directory structure with no resemblance to the package names at all.
The element for the h2 driver was already there, I just added the one about the sybasejtds driver.
NB: The driver name sybasejtds is entirely arbitrary and is basically what's going to appear in the JBoss AEP administration GUI (typically at port 9990) when one tries to create a new datasource. It is the module name net.sourceforge.jtds.jdbc that has to agree with step #4 and the module's directory structure as created in step #2.
After the above steps, I restarted the server and when I visited the JBoss EAP administrative interface to define a new datasource I saw that the driver was already recognized and available as an option. I then defined the datasource using the administrative GUI and then tested it (using the same GUI).
NB: the JNDI name is pretty arbitrary, the important connection is the name of the driver sybasejtds which has to agree with step #5.
The definition of the datasource resulted in further changes in file EAP-6.2.0/jboss-eap-6.2/standalone/configuration/standalone.xml. I could obviously have just elected to define the datasource directly in the XML file (however, the GUIs option to test the connection is nice).
The <datasource> element that ended up in my standalone.xml (after the datasource was defined from the GUI) looked like the following:
NB: The JBoss server is a piece of excrement as attested by the fact that if you decided to comment out a section in the standalone.xml file (using XML comments), e.g. to try something out — hoping to be able to revert back to it after the test — when the server restarts it's going to delete that element. So to test always make a separate copy of standalone.xml. I've also noticed some random changes in the standalone.xml file which led me to believe that this piece of human waste is reading the file and the writing it back to file based on a parsed representation of the XML (which would explain why it deletes comments).