Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <6353249.1192524650636.JavaMail.jira@brutus>
Date: Tue, 16 Oct 2007 01:50:50 -0700 (PDT)
From: =?utf-8?Q?J=C3=B8rgen_L=C3=B8land_=28JIRA=29?= <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-974) ClientDriver can lose some connection
 properties
In-Reply-To: <1720554496.1139870383935.JavaMail.jira@ajax.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/DERBY-974?page=3Dcom.atlassian.=
jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535204 ]=20

J=C3=B8rgen L=C3=B8land commented on DERBY-974:
-------------------------------------

I figured a way to test this. Without the patch, the code below results in=
=20

"java.sql.SQLException: The connection was refused because the database tes=
t1 was not found."=20

whereas it correctly creates a database named 'test1' with the patch applie=
d.

<code>
Properties props1 =3D new Properties();
props1.put("create", "true");
Properties props2 =3D new Properties(props1);
...
con =3D DriverManager.getConnection("jdbc:derby://localhost:1527/test1;", p=
rops2);
</code>

> 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=C3=B8rgen L=C3=B8land
>            Priority: Minor
>         Attachments: ClientDriver.java-diff, PropertiesTest.java
>
>
> Internally, the ClientDriver class's appendDatabaseAttributes() method us=
es 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 Hashta=
ble, instead of giving Properties a Hashtable, as the former exposes too mu=
ch implementation.)
> The fix is to simply replace calls to keys() on all Property objects to u=
se 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 mad=
e.

--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.