JDBC in Web Service Glassfish - java

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?

Related

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.

JDBC Connection Pool / JDBC resource

I am a beginner working on a project in Netbeans and using Glasshfish, but I have to deploy on TOMCAT on Elastic BeanStalk. I don't know anything about tomcat. To connect to my database, I use Entity Classes and a named connection jdbc/whatever (I hear this is called a JDNI name) in my persistence.xml.
On the Glassfish server bundled with Netbeans, I added a Connection pool and a JDBC resource. This was done with a GUI. It was super simple. Create the JDBC connection pool after you stuffed the right driver in the right folder by pointing to the location of server/password/etc. Then point the jdbc resource at the pool.
Now I need to do this with TOMCAT and XML. I have no idea what I am doing...
How do I create a connection pool which all my applications can reach?
How do I then get JNDI? set up that persistence.xml can reference and make the magic db stuff happen?
How do I then set up a jdbc authentication realm based on this database?
It was magic in Glassfish is it was so GUI. But I don't have a GUI for TOMCAT.
I am using spring.

(In Eclipse) JDBC Database access in servlet goes awry

I'm very new to web-application programming with Java. I have two questions.
First: I have a postgresql database. I can access the database fine when doing it outside of a servlet (as a JUnit4 test). However, when I try to access it via a servlet I get:
java.sql.SQLException: No suitable driver found for jdbc:postgresql://localhost:5432/comic_store
at java.sql.DriverManager.getConnection(DriverManager.java:602)
at java.sql.DriverManager.getConnection(DriverManager.java:185)
at ilya.database.DBService.<clinit>(DBService.java:15)
at ilya.database.UserGateway.getUserByEmail(UserGateway.java:29)
at ilya.controller.Login.<init>(Login.java:12)
etc.
Why would this exception get thrown while accessing from a servlet, but not otherwise.
Second: What is the preferred way of initializing a database connection in servlets? Should I be creating a DataSource with web.xml?
Found my answer here . And Apache's JNDI Datasources HOW-TO also helped. Here's what worked: adding the driver jar to %CATALINA_HOME%/lib instead of WEB-INF/lib and then using Class.forName() to load the driver. I tried excluding Class.forName() and got the same exception. I also tried Class.forName() with the driver only in WEB-INF/lib, and that also didn't work. As I said above, I'm running Tomcat 7 and jdk 1.6.0.

Best way to access a sqlite database file in a web service

First question from me on stack overflow.
I have created a java web application containing a web service using netbeans (I hope a web application were the correct choice). I use the web application as is with no extra frameworks. This web service use a sqlite JDBC driver for accessing a sqlite database file.
My problem is that the file path end up incorrect when I try to form the JDBC connection string. Also, the working directory is different when deploying and when running JUnit tests. I read somewhere about including the file as a resource, but examples of this were nowhere to be seen.
In any case, what is the best way to open the sqlite database, both when the web service is deployed and when I test it "locally"?
I don't know much about web services, I just need it to work, so please, help me with the technicalities.
Update
To put this a litle bit in context, some "println" code gives this:
Printing the work directory from a simple JUnit test gives
C:\MinaFiler\Work\SOA\BusTimetableWS
Invoking a similar web servic method returns
C:\Program Files\sges-v3\glassfish\domains\domain1
The connection string is formed from prepending "jdbc:sqlite:" to the path which at the moment is absolute:
C:\MinaFiler\Work\SOA\BusTimetableWS\src\java\miun\bustimetable\database\sqlit\BusTimetableWS.db
However, this fails because my tests throws exceptions stating database tables doesn't exist although they really do, I can see them with sqlite3.exe .
One way would be to use a config file that you can read and fetch your connection string from there.
I'm sure the framework you are using has some kind of standard way of saving configurations.
Another option would be to place the db in a known relative path from your main execution files. Then when executed fetch your current directory, and look for the db from that path.
In any case, what is the best way to open the sqlite database, both when the web service is deployed and when I test it "locally"?
The web service should use a DataSource to retrieve a connection from a connection pool configured at the application server level. In your unit test, use whatever you want (a standalone connection pool, a direct JDBC connection).
But in both cases, why don't you use an absolute path to the database file in your jdbc url? From How to Specify Database Files:
jdbc:sqlite:C:/work/mydatabase.db
The working directory wouldn't matter if you do so.

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.

Categories

Resources