[
https://issues.apache.org/jira/browse/DERBY-2498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Myrna van Lunteren updated DERBY-2498:
--------------------------------------
Attachment: DERBY-2498.diff
After thought and debugging, I decided looking for a : in checkDatabases was
not the right thing to do - it would have duplicated code in InternalDriver.
According to the api, Driver.connect() is allowed to return a null connection,
so that's fine - we just shouldn't continue on from the DataSource.
I added a check for isConnectionNull() in NetConnection.java, which throws the
same SQLException as was implemented for DERBY-95, so we get the same result
with all three datasources in this situation.
tests passed (sane jars on windows with jdk16 & ibm15).
I'll commit tomorrow unless someone thinks this is a bad idea.
> NullPointerException on ClientDataSource.getConnection() when
> ds.setdatabaseName was invalid
> ---------------------------------------------------------------------------------------------
>
> Key: DERBY-2498
> URL: https://issues.apache.org/jira/browse/DERBY-2498
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.3.1.4
> Reporter: Myrna van Lunteren
> Attachments: DERBY-2498.diff
>
>
> The following code snippet:
> ClientDataSource ds =
> (ClientDataSource)JDBCDataSource.getDataSource();
> // invalid database string
> ds.setDatabaseName("jdbc:derby:wombat");
> ds.getConnection();
> results (with jdk14) in this stack trace:
> java.lang.NullPointerException
> at org.apache.derby.client.am.ProductLevel.<init>(ProductLevel.java:41)
> at
> org.apache.derby.client.net.NetDatabaseMetaData.<init>(NetDatabaseMetaData.java:40)
> at
> org.apache.derby.client.net.ClientJDBCObjectFactoryImpl.newNetDatabaseMetaData(ClientJDBCObjectFactoryImpl.java:276)
> at
> org.apache.derby.client.net.NetConnection.newDatabaseMetaData_(NetConnection.java:1144)
> at
> org.apache.derby.client.am.Connection.completeConnect(Connection.java:1803)
> at
> org.apache.derby.client.net.NetConnection.completeConnect(NetConnection.java:412)
> at
> org.apache.derby.client.net.NetConnection.initialize(NetConnection.java:297)
> at
> org.apache.derby.client.net.NetConnection.<init>(NetConnection.java:231)
> at
> org.apache.derby.client.net.ClientJDBCObjectFactoryImpl.newNetConnection(ClientJDBCObjectFactoryImpl.java:213)
> at
> org.apache.derby.jdbc.ClientDataSource.getConnection(ClientDataSource.java:186)
> at
> org.apache.derby.jdbc.ClientDataSource.getConnection(ClientDataSource.java:163)
> at
> org.apache.derbyTesting.functionTests.tests.jdbcapi.DataSourceTest.testJira95ds(DataSourceTest.java:808)
> This is a similar situation as described for EmbeddedDataSource in DERBY-95.
> This bug was found when converting the test for DERBY-95 to junit - the old
> test was explicitly creating an EmbeddedDataSource, so, this was never tested
> for Client (even when running with network server).
> Note, that the similar test for XADataSource, even for client, does not
> result in an NPE.
> I have not tested PooledDataSource, but it should be checked.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
