• 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

Driver loading

 
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What are the pros/cons regarding loading a DB driver in a way that bypasses the usual way driver gets loaded (i.e. including location of the driver in the classpath, or physically placing it in the proper directory where the JVM expects drivers to live), and instead loading it dynamically.

I don't think it's a common way to deal with driver loading and it took me a while to find an example of how it's done. I did however, and now I'm wondering what are the implications of such a loading process.

The reason I've been isistant on using such a thing is that I want the app to completely self contained and as simple as possible.

Say the small desktop app works with the McKoi DB and its use is intened for people (single user most of the time) who maybe don't want to know about classpaths, JVM, directories and such in order to start the app. Instead, all they expect is to double click something and be done with it.

So what's good/bad about such approach?
Thank you in advance, Tomasz
 
Ranch Hand
Posts: 128
Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi tomasz,

I dont know if I understood your question correctly, but if you look at the DriverManager classes description, you could also specify a Driver in through a Property in a properties file that will be used at load time,


As part of its initialization, the DriverManager class will attempt to load the driver classes referenced in the "jdbc.drivers" system property. This allows a user to customize the JDBC Drivers used by their applications. For example in your ~/.hotjava/properties file you might specify:

jdbc.drivers=foo.bah.Driver:wombat.sql.Driver:bad.taste.ourDriver

When the method getConnection is called, the DriverManager will attempt to locate a suitable driver from amongst those loaded at initialization and those loaded explicitly using the same classloader as the current applet or application.



So you can still provide the "Double click" comfort to your clients, by providing a list of all the Databases that will be used from Developing to testing to production. worst is you can avoid "Class.forName" option and directly instantiate the driver class for example "org.gjt.mm.mysql.Driver = new Driver()", but this will "hard code" the Application with the MySQL database.

But thinking of the Driver loading, I think we need to some where do this loading as the dirver implementations are provided by the Database vendors.

Pros: you can keep the Application "database independent" all you need to do is specify a different driver class in your properties table.
 
reply
    Bookmark Topic Watch Topic
  • New Topic