You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Myrna van Lunteren (JIRA)" <ji...@apache.org> on 2007/04/17 23:27:15 UTC
[jira] Created: (DERBY-2559) recreating a datasource using
javax.naming.Reference from a ClientDataSource40 fails
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.0.0
Reporter: Myrna van Lunteren
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.
[jira] Updated: (DERBY-2559) recreating a datasource using
javax.naming.Reference from a ClientDataSource40 fails
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ 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-3b-documentation.diff
Thanks for looking at the patch Knut Anders.
'derby-2559-3b-documentation.diff' adds a throw clause to the JavaDoc and corrects an invalid reference. I also refreshed the patch after applying patch 2a.
Committed 'derby-2559-2a-defenses.diff' to trunk with revision 628647.
Committed 'derby-2559-3b-documentation.diff' to trunk with revision 628654.
The previous code failed to create data sources when running with Java SE 6.
This suggest the patches could be backported to branches 10.2 and 10.3.
Patches 1 and 2 apply cleanly, the documentation patch (3) does not.
> 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, 10.4.0.0
> Reporter: Myrna van Lunteren
> Assignee: Kristian Waagan
> Fix For: 10.4.0.0
>
> Attachments: derby-2559-1a.diff, derby-2559-2a-defenses.diff, derby-2559-3a-documentation.diff, derby-2559-3b-documentation.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.
[jira] Updated: (DERBY-2559) recreating a datasource using
javax.naming.Reference from a ClientDataSource40 fails
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-2559:
-----------------------------------
Derby Info: [Patch Available]
> 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, 10.4.0.0
> Reporter: Myrna van Lunteren
> Assignee: Kristian Waagan
> Fix For: 10.4.0.0
>
> Attachments: derby-2559-1a.diff, derby-2559-2a-defenses.diff, derby-2559-3a-documentation.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.
[jira] Updated: (DERBY-2559) recreating a datasource using
javax.naming.Reference from a ClientDataSource40 fails
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ 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-3a-documentation.diff
derby-2559-2a-defenses.diff
I have attached two more patches:
- derby-2559-2a-defenses.diff: Does some defensive checking to ensure no exception is thrown when it should not be.
- derby-2559-3a-documentation.diff: Fixes to the documentation, both formatting and content.
Patches ready for review. I'm especially awaiting comments on the 2a patch.
> 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, 10.4.0.0
> Reporter: Myrna van Lunteren
> Assignee: Kristian Waagan
> Fix For: 10.4.0.0
>
> Attachments: derby-2559-1a.diff, derby-2559-2a-defenses.diff, derby-2559-3a-documentation.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.
Re: [jira] Updated: (DERBY-2559) recreating a datasource using
javax.naming.Reference from a ClientDataSource40 fails
Posted by Kristian Waagan <Kr...@Sun.COM>.
Kristian Waagan wrote:
<snip>
> if (ref.getClassName().startsWith("org.apache.derby")) { // <-- Even
> more restrictive??
There's a missing ! (not) in the if above...
--
Kristian
<snip>
Re: [jira] Updated: (DERBY-2559) recreating a datasource using
javax.naming.Reference from a ClientDataSource40 fails
Posted by Kristian Waagan <Kr...@Sun.COM>.
Sending this as a mail for now, since Jira is down. Will add it to the
issue later.
I don't know much about Referenceable/Reference, but I do observe that
Derby's object factories can easily be made to throw an exception.
According to the JDK API documentation, this will cause a full stop in
the process of creating the requested object (i.e. no more object
factories will be attempted).
Would it make sense to add something like the code below?
If so, it would go into ClientDataSourceFactory and
ReferenceableDataSource and the method getObjectInstance.
---- CODE ----
// Do some defensive checking to avoid exception being thrown.
// Throwing an exception means that no other factory will be attempted.
if (!(refObj instanceof javax.naming.Reference)) {
return null;
}
javax.naming.Reference ref = (javax.naming.Reference) refObj;
if (ref.getClassName().startsWith("org.apache.derby")) { // <-- Even
more restrictive??
return null;
}
// Create the proper data source object shell.
Object ds = Class.forName(ref.getClassName()).newInstance();
// Fill in the data source object shell with values from the jndi reference.
ClientDataSourceFactory.setBeanProperties(ds, ref);
return ds;
---- CODE ----
--
Kristian
Kristian Waagan (JIRA) wrote:
> [ https://issues.apache.org/jira/browse/DERBY-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Kristian Waagan updated DERBY-2559:
> -----------------------------------
>
> Derby Info: [Patch Available]
> Fix Version/s: 10.4.0.0
>
>> 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).
>>
>
[jira] Updated: (DERBY-2559) recreating a datasource using
javax.naming.Reference from a ClientDataSource40 fails
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-2559:
-----------------------------------
Derby Info: [Patch Available]
Fix Version/s: 10.4.0.0
> 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.
[jira] Commented: (DERBY-2559) recreating a datasource using
javax.naming.Reference from a ClientDataSource40 fails
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12569269#action_12569269 ]
Knut Anders Hatlen commented on DERBY-2559:
-------------------------------------------
2a looks good. Seems like the patch makes the implementation more in line with the description in the javadoc, so that's good.
> 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, 10.4.0.0
> Reporter: Myrna van Lunteren
> Assignee: Kristian Waagan
> Fix For: 10.4.0.0
>
> Attachments: derby-2559-1a.diff, derby-2559-2a-defenses.diff, derby-2559-3a-documentation.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.
[jira] Updated: (DERBY-2559) recreating a datasource using
javax.naming.Reference from a ClientDataSource40 fails
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Resolved: (DERBY-2559) recreating a datasource using
javax.naming.Reference from a ClientDataSource40 fails
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan resolved DERBY-2559.
------------------------------------
Resolution: Fixed
Thank you Army.
The revision you mention updates the documentation, but does not fix the JavaDoc error (didn't notice...). I didn't merge it right away because I got conflicts for 10.2, but it applies fine for 10.3.
Merged patch 3b to 10.3 with revision 635567, and also fixed the JavaDoc error in the same commit.
Resolving issue, reopen to merge the fixes back to 10.2.
Will close the issue in a few days.
> 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, 10.4.0.0
> Reporter: Myrna van Lunteren
> Assignee: Kristian Waagan
> Fix For: 10.3.2.2, 10.4.0.0
>
> Attachments: derby-2559-1a.diff, derby-2559-2a-defenses.diff, derby-2559-3a-documentation.diff, derby-2559-3b-documentation.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.
[jira] Updated: (DERBY-2559) recreating a datasource using
javax.naming.Reference from a ClientDataSource40 fails
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-2559:
-----------------------------------
Derby Info: (was: [Patch Available])
Affects Version/s: 10.4.0.0
Committed 'derby-2559-1a.diff' to trunk with revision 617492.
This commit is an incremental fix. More thought must be put into how the object factory is to be well behaved.
The factory will now create all the client data source objects, but it might/will fail if another type of object (or null) is passed as the first argument.
I'm also thinking about porting the fix to 10.3.
> 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, 10.4.0.0
> 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.
[jira] Updated: (DERBY-2559) recreating a datasource using
javax.naming.Reference from a ClientDataSource40 fails
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-2559:
-----------------------------------
Derby Info: (was: [Patch Available])
Clearing patch available flag, but considering backporting at least patches 1 and 2 to 10.2 and 10.3.
> 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, 10.4.0.0
> Reporter: Myrna van Lunteren
> Assignee: Kristian Waagan
> Fix For: 10.4.0.0
>
> Attachments: derby-2559-1a.diff, derby-2559-2a-defenses.diff, derby-2559-3a-documentation.diff, derby-2559-3b-documentation.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.
[jira] Assigned: (DERBY-2559) recreating a datasource using
javax.naming.Reference from a ClientDataSource40 fails
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan reassigned DERBY-2559:
--------------------------------------
Assignee: Kristian Waagan
> 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
>
> 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.
[jira] Updated: (DERBY-2559) recreating a datasource using
javax.naming.Reference from a ClientDataSource40 fails
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-2559:
-----------------------------------
Fix Version/s: 10.3.2.2
Merged patches 1 and 2 to 10.3 with revision 632274.
Tests ran cleanly.
For 10.2, the merge also worked (except that the test changes were skipped because the file doesn't exist), but I got one error:
derbyall/derbyall.fail:lang/timestampArith.java.
I also got this failure without the merge as well. I don't have time to investigate, so I will hold back the merge to 10.2.
If anyone wants to merge the fix, please go ahead.
If this issue is still open in one week, I'll mark it resolved.
> 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, 10.4.0.0
> Reporter: Myrna van Lunteren
> Assignee: Kristian Waagan
> Fix For: 10.3.2.2, 10.4.0.0
>
> Attachments: derby-2559-1a.diff, derby-2559-2a-defenses.diff, derby-2559-3a-documentation.diff, derby-2559-3b-documentation.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.
[jira] Commented: (DERBY-2559) recreating a datasource using
javax.naming.Reference from a ClientDataSource40 fails
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12573976#action_12573976 ]
Kristian Waagan commented on DERBY-2559:
----------------------------------------
Seems I was bitten by this one, due to leap year issues: DERBY-3486.
Thus the merge also ran without failures on the 10.2 branch.
I leave it up to the release manager or someone else to do the merge if they feel it's worth the hassle.
> 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, 10.4.0.0
> Reporter: Myrna van Lunteren
> Assignee: Kristian Waagan
> Fix For: 10.3.2.2, 10.4.0.0
>
> Attachments: derby-2559-1a.diff, derby-2559-2a-defenses.diff, derby-2559-3a-documentation.diff, derby-2559-3b-documentation.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.
[jira] Commented: (DERBY-2559) recreating a datasource using
javax.naming.Reference from a ClientDataSource40 fails
Posted by "A B (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12574707#action_12574707 ]
A B commented on DERBY-2559:
----------------------------
> Merged patches 1 and 2 to 10.3 with revision 632274.
I think this merge lead to a javadoc error:
[javadoc] java\client\org\apache\derby\client\ClientDataSourceFactory.java:48: warning - Tag @see: reference not found: ClientDataSource
Does 628654 need to be merged back, as well?
> 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, 10.4.0.0
> Reporter: Myrna van Lunteren
> Assignee: Kristian Waagan
> Fix For: 10.3.2.2, 10.4.0.0
>
> Attachments: derby-2559-1a.diff, derby-2559-2a-defenses.diff, derby-2559-3a-documentation.diff, derby-2559-3b-documentation.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.