Develop Reference

Wildfly 10 classloader hell (hibernate doesn't see Postgres Driver installed as module)

I use wildfly Entity Manager for my application, but besides that I need to establish jdbc connection in runtime for other purposes, so I receiving settings from service, in runtime, during application start and establish this connection.
I tried to use sql2o and it works just fine, but then I tried hibernate (I'm creating it programatically), and it didn't work. I took a look on internals and figured out why it doesn't work.
When library calls DriverManager.getConnection() it checks callers ClassLoader. And when sql2o was loaded with an application just like Postgres Driver, the hibernate is not, and it fails.
creating of client sql2o that works just fine
creating hibernate programatically and it fails
Then I was trying to use PostgresDriver installed as Wildfly module and as deployment both ways didn't work.
Furthermore I tried to extract hibernate from wildfly with jboss-deployment-structure.xml, and use bundled from my application. Again it doesn't work.
Every time I'm getting
Caused by: java.sql.SQLException: No suitable driver found for jdbc:postgresql...
I found among registered drivers PostgresDriver loaded with Wildfly's
with classloader id "org.postgres:main", when caller (hibernate's) ClassLoader
has id = "org.hibernate:main". So it's wildfly's modules, but why don't they see each other???
The problem:
I use ear packaging with 2 subdeployments (jar + war), how can I solve this problem, and make wildfly's hibernate see installed as wildfly module Postgres Driver?

Error starting webapp with Mybatis, c3p0 on Tomcat 8

I am trying to deploy my webapp on Tomcat 8 that uses Mybatis 3.2.7 and c3p0 for connection pooling to connect to an SQLServer database. I have the sqljdbc4.jar in my classpath. I query the database during my webapp startup to get some values.
The application works in Tomcat 7, however on Tomcat 8, I cannot connect to the database. I debugged a lot using eclipse and the root cause is in the file BasicResourcePool.class file in c3p0 where it is waiting for resource to become available but then throws an java.lang.InterruptedException.
Due to this, Mybatis is throwing a java.SQL.SQLException and thus my webapp does not start as it cannot connect to the database.
Has someone else upgraded to Tomcat 8 and has successfully used Mybatis-c3p0? If yes am I missing something over here?

Solved this. It was JDBC driver issue. Mybatis isn't very good in showing underlying exceptions it seems.
Found this on tomcat 8's documentation:
Thus, the web applications that have database drivers in their
WEB-INF/lib directory cannot rely on the service provider mechanism
and should register the drivers explicitly.
So, I added a Class.forName() with the appropriate driverClass during app startup and this solved my issue.

MSSQL JDBC on unix

I am trying to integrate a web tool we have with a sql server database using Integrated Security. I have been looking around trying to find a unix version of the sqljdbc4.jar however I cannot seem to find one with .so files only .dll's.
Does anyone know where I can get a version with the .so files required or another way to use integrated security?
Currently my application is failing to connect with
com.microsoft.sqlserver.jdbc.SQLServerException: This driver is not configured for integrated authentication
and I can see
WARNING: Failed to load the sqljdbc_auth.dll
earlier in the logs.
Using version 2.5 of mssqljdbc.

According to these docs, beginning with MSSQL JDBC Driver 4.0, you should be able to specify authenticationScheme=JavaKerberos to use the pure Java Kerberos implementation that doesn't need sqljdbc_auth.dll.
Note, I haven't tried this.

I know its late but for anyone searching this, try the following:
put the sqljdbc_auth.dll in your resource folder then add the following code
ClassLoader classLoader = TestDBConnection.class.getClassLoader();
File file = new File(classLoader.getResource("sqljdbc_auth.dll").getFile());
System.setProperty("java.library.path", file.getParent());

JDBC in Web Service Glassfish

I have made an application with the java JDBC driver for MYSQL and that works fine. But now I'm trying to implement a web service into my application and I can't seem to get a connection made. Do I need to use a different driver or different way to connect to the MySQL server?
Thanks

You can use the same driver. Most likely you don't have your connection pool in Glassfish properly set up.
You can read about it here http://docs.sun.com/app/docs/doc/820-7692/ablih?l=en&a=view

You have to put the JDBC driver JAR either in a /lib directory that's visible to Glassfish (if it's shared) or in the WEB-INF/lib of your web service WAR.
You don't say what the error was. If it's a ClassNotFoundException, it means the class loader couldn't find the JDBC driver JAR.
If the error message is "no suitable driver found", it usually means that the syntax of your connection URL isn't correct for the given driver. The good news in that case is that the driver .class was picked up by the class loader.
Were you going to create a connection with a DriverManager, like you probably did with your app, or were you going to be ambitious and try to set up a connection pool?

Instantiating Oracle Driver results in InvocationTargetException

I have a simple web service that uses an oracle database. When I test the service internally it works fine, however, calling the web service through my client (on the same machine but in a different WAR) throws an invocationtargetexception. I've finally discovered it's an issue with instantiating the OracleDriver. It doesn't throw any exception at all so I cannot find out what the error is.
Googling has only provided a solution of using oracle.jdbc.driver.OracleDriver instead of oracle.jdbc.OracleDriver but that doesn't seem to fix anything. The jar I'm using is ojdbc14.jar and, as far as I can tell, it's included in the class path for the web service properly... since it works when I test the service with a simple main method.
EDIT:
The InvocationTargetException is generated by an AxisFault from the Axis server. The invocationtargetexception is a wrapper class, and my attempts to try to extract the exception using .getCause() always return null.
I am deploying the service using jboss and was including the driver JAR file in the library for the source but not for the server. Including the driver in /jboss/server/default/lib resolved it.

2 WARs? I suppose your ojdbc.jar is located inside WEB-INF/lib of the web service's WAR.
Maybe your WAR is inside an EAR, so you should reference the driver in MANIFEST.MF.
More info: http://java.sun.com/j2ee/verified/packaging.html

Without more information, it's hard to provide concrete suggestions; I have however had experience with an Oracle driver that attempts to connect via native OCI libraries, fails to find those libraries installed on the system, and throws an InvocationTargetException. This is all from very vague memory, so your mileage will almost certainly vary.
It's been a while, but if memory serves me, I had a case where the connection URL was incorrectly configured, and OracleDriver (or one of its wrappers) iterated through a set of possible connection methods, trying to find one that worked. In the case that the URL was correctly configured, it never got to the OCI attempt (the thin connection method attempt came first), but if the connection URL was misconfigured, the thin attempt would fail, causing the OCI attempt, which then also failed because the OCI client was not installed on the host (resulting in an InvocationTargetException.)
So, some things to check:
Is the connection URL valid? If you're using the same connection URL in both places, are you sure that both processes are binding to the same NIC? If they are binding to different NICs, it might cause connection oddities, even on the same host.
Is the environment the same in both cases - if the OCI client is getting used in your development environment, there are likely several environment variables it depends on. If those environment variables aren't set identically in the environment where the servlet container is running, I'd expect different behavior.