[
https://issues.apache.org/jira/browse/DERBY-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Waagan updated DERBY-2559:
-----------------------------------
Attachment: derby-2559-1a.diff
'derby-2559-1a.diff' is a patch that fixes the reported problem, where attempts
to (re)create a data source through Reference returned null.
The cause was an if with entries for the pre-JDBC 4.0 classes (like
ClientDataSource), but no entries for the JDBC 4.0 classes. I changed the
factory class to use the same approach as the embedded driver, as it seemed to
be easier to use reflection because of the mix between pre-JDBC 4.0 classes and
JDBC 4.0 classes.
The patch also removes the workaround (disabling) in DataSourceReferenceTest.
I am not sure if the method behaves as documented. I don't think it will ever
return null, but either succeed or throw an exception. I will look at the
documentation in a separate patch.
I'm running tests and will post the results later.
Patch ready for review.
> recreating a datasource using javax.naming.Reference from a
> ClientDataSource40 fails
> ------------------------------------------------------------------------------------
>
> Key: DERBY-2559
> URL: https://issues.apache.org/jira/browse/DERBY-2559
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.3.1.4
> Reporter: Myrna van Lunteren
> Assignee: Kristian Waagan
> Fix For: 10.4.0.0
>
> Attachments: derby-2559-1a.diff
>
>
> Consider the following code snippet from test DataSourceReferenceTest:
> --------------------
> Referenceable refDS = (Referenceable) ds;
> Reference dsAsReference = refDS.getReference();
> String factoryClassName = dsAsReference.getFactoryClassName();
> ObjectFactory factory =
> (ObjectFactory) Class.forName(factoryClassName).newInstance();
> Object recreatedDS =
> factory.getObjectInstance(dsAsReference, null, null, null);
> ---------------------
> When ds is a ClientDataSource40 (i.e. when running with jdk16), recreatedDS
> is null.
> Note, that this showed up only after converting the test to junit, because
> the original test hardcoded the ds to be a ClientDataSource. I confirmed this
> not to be related to my changes for DERBY-2296 (which prompted me to convert
> the test), by backing out my changes to ClientBaseDataSource and
> client/am/Connection and rerunning the test (needed some minor adjustments of
> expected values table/array).
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.