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] Commented: (DERBY-2498) NullPointerException on ClientDataSource.getConnection() when ds.setdatabaseName was invalid
Date Wed, 22 Oct 2008 02:54:44 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12641699#action_12641699

Myrna van Lunteren commented on DERBY-2498:

I'll do some debugging and try to understand how the productID_ is set if we have a databaseName
without colons in it., but I was wondering why in DERBY-95 the solution with XA/Embedded was
to catch a null coming back from a getConnection call, in other words, why was there a null
coming from a getConnection call.

It seems to me that this is because in BaseMonitor we look for colons (':') in the databaseName
passed in, and if we find them (more than one anyway; comments suggest one might be interpreted
as being part of a drive indicator on windows) we return the null connection.

This is a simplification, (we try to figure a suitable protocol) but I think what this means
is that we don't accept database names with a ':' in it.
Experiments bear this out, e.g. 'my:db' also gets thrown out (with Embedded DataSource).

Is that OK to maintain? If so,  maybe the solution to the NPE with the client DataSource is
to add a similar check for colons in NetConnection.checkDatabaseName()?

> 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
> 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