Issue Details (XML | Word | Printable)

Key: DERBY-530
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Kathey Marsden
Reporter: Piet Blok
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
Derby

ClientDriver ignores Properties object in connect(String url, Properties connectionProperties) method

Created: 24/Aug/05 12:25 AM   Updated: 20/Mar/07 09:54 PM
Return to search
Component/s: Network Client
Affects Version/s: 10.1.1.0
Fix Version/s: 10.1.2.1, 10.2.1.6

Time Tracking:
Not Specified

File Attachments:
  Size
File Licensed for inclusion in ASF works DERBY530.diff 2005-09-10 05:03 AM Kathey Marsden 32 kB
Environment: windows XP, JRE 1.5.0_04
Issue Links:
Dependants
 

Resolution Date: 17/Sep/05 08:07 AM


 Description  « Hide
In contrast to EmbeddedDriver, a connection attribute create=true is not recognized when presented as a property in a Properties object.

 As a workaround I append the attributes from the Properties object to the url string before invoking the connect() method: then a new database is created and a connection is established.

Next code fragment illustrates the bug and the workaround:



    private static final ClientDriver clientDriver = new ClientDriver();


    private Connection getClientConnection(String database,
            Properties connectionProperties) throws SQLException {
        try {
            System.out.println("Try to connect with properties");
            String connectionURL = "jdbc:derby://127.0.0.1:1527/" + database;
            System.out.println("connectionURL: " + connectionURL);
            Connection rv = clientDriver.connect(connectionURL,
                    connectionProperties);
            System.out.println("Connection: " + rv);
            return rv;
        } catch (SQLException e) {
            System.out.println("Try to connect with URL attributes");
            StringBuffer sb = new StringBuffer();
            for (Enumeration enu = connectionProperties.propertyNames(); enu
                    .hasMoreElements();) {
                String key = (String) enu.nextElement();
                sb.append(';');
                sb.append(key);
                sb.append('=');
                sb.append(connectionProperties.getProperty(key, ""));
            }
            String connectionURL = "jdbc:derby://127.0.0.1:1527/" + database
                    + sb.toString();
            System.out.println("connectionURL: " + connectionURL);
            Connection rv = clientDriver.connect(connectionURL,
                    connectionProperties);
            System.out.println("Connection: " + rv);
            System.out
                    .println("!!!!!!!!!!! seems a bug: Properties argument in ClientDriver.connect(String, Properties) has not been used");
            return rv;
        }
    }



 All   Comments   Work Log   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Kathey Marsden added a comment - 07/Sep/05 01:32 AM
Currently the client sends all attributes specified in the the url to the server in the RDBNAM parameter of the ACCSEC command. This includes any client attributes (which the server ignores). It does not however make proper consideration for the properties specified in the info parameter of the connect(String url, Properties info) method. Another issue with the current approach is that user and password attributes get passed to the server without encryption if specified with the url.
 

I propose to fix this issue by sending both the properties specified in the info parameter and those specified in the url to the server in the RDBNAM. user and password attributes will be the exception. user and password will be sent via the standard DRDA mechanism and excluded from the attributes sent with RDBNAM whether specified with the url or info properties. As a result of the combination, the order of attributes sent to the server may be different than originally specified in the URL.



Kathey Marsden added a comment - 10/Sep/05 05:03 AM

Send both the properties specified in the info parameter and those specified in the url to the server in the RDBNAM. user and password attributes will be the exception. user and password will be sent via the standard DRDA mechanism and excluded from the attributes sent with RDBNAM whether specified with the url or info properties. As a result of the combination, the order of attributes sent to the server may be different than originally specified in the URL.

Also added additional driver tests and attrbute tests to checkDriver.


Piet Blok added a comment - 10/Sep/05 03:39 PM
I just add this because it was not explicitly mentioned by Kathey : I guess encryption applies both to the user password and the bootPassword property?

Kathey Marsden added a comment - 12/Sep/05 08:39 PM
To answer Piet's question. No . bootPassword is not encrypted. I added a note to DERBY-474 to update the documentation to provide a warning that this is the case.

Deepa Remesh added a comment - 13/Sep/05 12:43 AM
I ran derbyall with this patch and got two failures:
* derbyall/derbynetclientmats/derbynetmats.fail:jdbcapi/checkDriver.java
* derbyall/derbynetmats/derbynetmats.fail:jdbcapi/checkDriver.java
I think new master files have to be created for DerbyNet and DerbyNetClient frameworks because of addition of tests for Client attributes.

I looked at the changes and I have one comment on one of the comments in the code. The comment for 'tokenizeDatabase' method in ClientDriver.java can be changed from "//return database name and attributes" to "//return database name". With the changes for DERBY-530, it only returns the databaseName.

Currently in jdbcapi/checkDriver.java, I see tests only for 'traceFile' property in 'testClientAttributes'. I think it would be good to test some more properties using the Properties object.

Kathey Marsden added a comment - 13/Sep/05 01:57 AM
Thanks Deepa for the review.
I will fix up the code comments.

svn add bites me again.

On the test, I agree that additional tests for all the attributes should be added, and started to do that, but found DERBY-530 growing, so thought it best to check in with the tests that the embedded attributes get passed to the server and the client attributes get processed and put a todo in the test to add the additional attributes. I'll file a separate Jira entry to enhance the test.

When I ran derbyAll, I found there is another problem too with the test that tracefile goes to a different subdirectory based on whether the test is run in a suite or independently.
I will fix that too.


Kathey Marsden added a comment - 15/Sep/05 10:08 PM
Checked into the trunk.

Date: Thu Sep 15 05:49:14 2005
New Revision: 289227

URL: http://svn.apache.org/viewcvs?rev=289227&view=rev
Log:
DERBY-530
ClientDriver ignores Properties object in connect(String url, Properties connectionProperties) method

In 1 derbyAll run I saw a failure in DerbyNetAutoStart. It was an exception from network server closing the connections after Derby was intentionally shut down, similar to DERBY-273. I was not able to reproduce the failure after many dozens of runs of the test and repeating derbyAll. Looking at the test I see that Derby is intentionally shut down and so the exception is not unexpected but the shutdown is not passed through properties, so I am assuming that this was a rare intermittent diff and not caused by this change.

Probably still to be resolved is what Network Server should do with exceptions that occur before Derby is started or after Derby is shut down. Right now it prints them to the console or System.out if the console is not specified. It seems like it could at least print them to derby.log if only the database and not the engine was shut down.

Kathey Marsden added a comment - 17/Sep/05 08:07 AM
Committed to trunk (2892227) and 10.1 (289672)

Date: Fri Sep 16 15:59:43 2005
New Revision: 289672
URL: http://svn.apache.org/viewcvs?rev=289672&view=rev
Log:
DERBY-530

ClientDriver ignores Properties object in connect(String url, Properties connectionProperties) method
Merge from trunk
svn merge -r289226:289227 https://svn.apache.org/repos/asf/db/derby/code/trunk

Kathey Marsden added a comment - 17/Sep/05 08:12 AM
The sending of user/password in RDBNAM is fixed by DERBY-530. getURL still needs to be fixed.