[
https://issues.apache.org/jira/browse/DERBY-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535535
]
Knut Anders Hatlen commented on DERBY-974:
------------------------------------------
Rather than hard-coding the host name and the database name, I think you can
wrap the test case in a DatabaseChangeSetup via
TestConfiguration.singleUseDatabaseDecorator(). This will automatically
generate a unique database name and do cleanup afterwards. Then you can get the
JDBC URL by calling TestConfiguration.getCurrent().getJDBCUrl(). With this
approach, it is also easier to make the test run in both embedded mode and
client/server mode, so you don't need special code in suite().
Wouldn't it be better to skip this catch block? If the test fails, it would
probably be more interesting to see the actual error message and its stack
trace, so I think it is better just to let the exception propagate up to the
caller.
+ } catch (SQLNonTransientConnectionException e){
+ fail("Connecting with a Properties object with "+
+ "default values does not work");
+ } finally {
Does this test belong in the JDBC 4 suite? I don't see that it is testing any
functionality specific to JDBC 4. Perhaps jdbcapi/DriverTest is a better place?
In fact, it looks like DriverTest already has what you need to pass in a
Properties object to getConnection(). See DriverTest.assertConnect().
> ClientDriver can lose some connection properties
> ------------------------------------------------
>
> Key: DERBY-974
> URL: https://issues.apache.org/jira/browse/DERBY-974
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.1.2.1, 10.1.3.1, 10.4.0.0
> Environment: Linux, Sun JRE 1.5
> Reporter: Michael Hackett
> Assignee: Jørgen Løland
> Priority: Minor
> Attachments: ClientDriver.java-diff, derby-974-1.diff,
> derby-974-1.stat, PropertiesTest.java
>
>
> Internally, the ClientDriver class's appendDatabaseAttributes() method uses
> keys() on the connection properties to get a list of the property names.
> However, this misses any properties in the default set. The correct method
> for a Properties object is propertyNames(). This will return the same type of
> object as keys(), but will include all properties.
> (It is unfortunate that Sun chose to make Properties a subclass of Hashtable,
> instead of giving Properties a Hashtable, as the former exposes too much
> implementation.)
> The fix is to simply replace calls to keys() on all Property objects to use
> propertyNames(). A quick search revealed that this is not the only place in
> the code base where this is done, so a more thorough scan should be made.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
