• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Webapp can't load sql driver

 
Ranch Hand
Posts: 75
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello all,
I have a tomcat 7 on cent os and I use sqljdbc4-SNAPSHOT.jar as a driver to connect to Microsoft SQL Server 2008.
I deployed the solution but i got execeptions when I tried to load the SQL driver (at DriverManager). I copied the driver's jar in tomcat's lib folder and the problem was fixed.

Can you please help me understand why moving the jar in the tomcat's folder solved the problem?

Thanks in advance
 
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It depends on where you copied it from. And if there were other copies in other classpaths.

JDBC drivers should almost always be copied to the TOMCAT_HOME/lib directory and not made part of the WARs, however. Take that as a near-universal rule. For one thing, the connection pooling is normally provided by the server, so the driver has to be in the server classpath, which means TOMCAT_HOME/lib.

It might be just a co-incidence that you got the "Connection reset". Network-related problems usually cause that. However, if you DID have 2 copies of the driver in the system, differing access paths could have resulted in internal inconsistencies, like where one copy sent out the request, and the other copy listened for it (but didn't have the context of the sender!).
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic