db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Myrna van Lunteren (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-2498) NullPointerException on ClientDataSource.getConnection() when ds.setdatabaseName was invalid
Date Mon, 03 Nov 2008 20:24:44 GMT

     [ 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

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
> ---------------------------------------------------------------------------------------------
>                 Key: DERBY-2498
>                 URL: https://issues.apache.org/jira/browse/DERBY-2498
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Client
>    Affects Versions:
>            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
> 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.

View raw message