Commons Dbcp
  1. Commons Dbcp
  2. DBCP-209

Is DataSource.getConnection(user, pass) working the way it is suppose to?


    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: 1.2.1
    • Fix Version/s: 1.3
    • Labels:


      In Tomcat's server.xml, I create a DataSource resource using the FACTORY org.apache.commons.dbcp.BasicDataSourceFactory and I also provide a URL and a DRIVERCLASSNAME. However I do not provide USERNAME or PASSWORD because I want to use DataSource.getConnection(user, pass) in my application. When I call DataSource.getConnection(user, pass) I get the following exception, java.sql.SQLException: invalid arguments in call, which was unexpected. I dug into the source code for BasicDataSource and I found what I think is the source of the problem. First, the method getConnection(user, pass) call the createDataSource() method. The createDataSource() method creates a Properties object and tries to put the username and password into the properties object. However, because the server.xml file does contain a username or password, this Properties object (named connectionProperties in the code) is empty. The createDataSource() the proceeds to call the validateConnectionFactory() method. This method then tries to get a Connection object!! This attempt fails because the Properties object has no username or password in it hence the Oracle driver complains about being passed invalid arguments. My question is why is the code working this way? Why does the createDataSource() and validateConnectionFactory() methods assume the username and password have been set in server.xml and then attempt to try to return a Connection object with the username and password passed to the getConnection(user, pass) method? It would seem to me the createDataSource() and validateConnectionFactory() methods should be aware of the username and password passed to the getConnection(user, pass) if this method is used.


        No work has yet been logged on this issue.


          • Assignee:
            Michael Remijan
          • Votes:
            0 Vote for this issue
            0 Start watching this issue


            • Created: