This link explains the new things about WildFly. Under the Migrating The Database Connection -> JDBC Driver
the article explains about two ways of using jdbc drivers for the applications. I tried with installing it as a module and it works fine. The problem is which way is better and when it is better, whether deploy it as any other application package or install it as a module?
(I noted that install it as a module is necessary for clustered environment. I am looking for, are there any other reasons?)

- 2,847
- 6
- 28
- 60
1 Answers
I think the correct link to the article you are referencing is this one : http://wildfly.org/news/2014/02/06/GlassFish-to-WildFly-migration/ (The other one does not seem to point to the article you are mentioning)
Below is the interesting part from "Migrating The Database Connection" section you are referencing:
On WildFly, you have two ways of installing the JDBC driver: whether you deploy it as any other application package or you install it as a module. You can always choose to deploy the driver, but it’s specially recommend when you have a cluster environment, since the deployments are automatically propagated in the server groups. You may have issues with the deployment if the driver is not JDBC4-compliant. In this case, installing the driver as a module solves those issues. The advantage of the JDBC driver as a module is the possibility of creating a custom WildFly bundle for your organization. This way, you can repeat exactly the same installation throughout several machines, preserving the same configuration. This is perfect for the development environment.
So in this section, the author describes the following advantage:
You may have issues with the deployment if the driver is not JDBC4-compliant. In this case, installing the driver as a module solves those issues.
The following Wildfly documentation describes this also:
Any JDBC 4-compliant driver will automatically be recognized and installed into the system by name and version. A JDBC JAR is identified using the Java service provider mechanism. Such JARs will contain a text a file named META-INF/services/java.sql.Driver, which contains the name of the class(es) of the Drivers which exist in that JAR. If your JDBC driver JAR is not JDBC 4-compliant, it can be made deployable in one of a few ways. (...)
Thus, deploying your driver as a module is easier than deploying it as any other application package in case it is not JDBC-4 compliant. (Because you would have to modify and rebuild your JDBC-4 not compliant jar to deploy it as any other application package)

- 1,899
- 14
- 27
-
Could you provide some more background and/or description in your answer? – Joe Kennedy Dec 01 '15 at 20:22
-
I had updated my answer with one reason explaining why you should use a module instead of deploying the driver directly. – Rémi Bantos Dec 14 '15 at 12:07
-
Also installing it as a module separates the required JDBC implementation from the application. For example you are then able to upgrade the JDBC driver without rebuilding the application. – ozOli Mar 29 '16 at 12:43
-
@ozOli, I think you misunderstood the question (as I did at first read) as the "as any other application package" method, in the referenced article, does not mean that the JDBC driver is embedded inside an application package. It just means that you can deploy it directly to the app server as any other .war, .jar package, so it's available for datasources configurations. – Rémi Bantos Mar 30 '16 at 19:15
-
Besides all this, I think that in order to use XA Transactions the driver will need to be installed on the application server. – K.Nicholas Mar 30 '16 at 19:33