You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Dianne Richards (JIRA)" <ji...@apache.org> on 2009/02/18 17:19:01 UTC
[jira] Created: (OPENJPA-927) Fix definition of
javax.persistence.query.timeout property
Fix definition of javax.persistence.query.timeout property
----------------------------------------------------------
Key: OPENJPA-927
URL: https://issues.apache.org/jira/browse/OPENJPA-927
Project: OpenJPA
Issue Type: Bug
Components: kernel
Affects Versions: 2.0.0
Reporter: Dianne Richards
Assignee: Dianne Richards
Priority: Minor
Fix For: 2.0.0
This was originally reported by Pinaki in OPENJPA-849. It is being moved to this new JIRA. Here's Pinaki's original comment:
queryTimeout.setLoadKey("javax.persistence.query.timeout");
queryTimeout.setDefault("-1");
queryTimeout.set(-1);
queryTimeout.setDynamic(true);
does not seem kosher for the following reason:
1. loadKey is the key with which a property is loaded from configuration artifacts. At this point of execution, no property has been *actually* loaded, they are merely being declared to exist. Hence we should not be setting load key.
2. configuration declares a Value. But does not assign its value. So setting its value to -1 does not look alright. Setting default value is OK.
These issues gain significance in the light of the fact the configuration's hashcode is the key to a factory in JNDI. And computation of hashcode depends on the actual value of the Values.
As an extreme example, assume two Configuration C1 and C2 nearly identical but differs *only* in their query.timeout value. The requirement is hash code for C1 and C2 must not be equal. And that is what Configuration.hashCode() ensures. But, because we are setting query timeout to -1 (that is not what the user's p.xml sets) and it is marked as dynamic, in both cases Configuration hashcode will treat query.timeout value to be -1 and will end up computing same hashcode for C1 and C2.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-927) Fix definition of
javax.persistence.query.timeout property
Posted by "Dianne Richards (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dianne Richards updated OPENJPA-927:
------------------------------------
Attachment: patch.txt
Here's a patch that does the following:
1 - Changes the setLoadKey() for javax.persistence.query.timeout to setEquivalentKey()
2 - Removes the set(-1) for the query timeout and lock timeout properties
3 - Removes from the EM getProperties Map the Connection2Password property
> Fix definition of javax.persistence.query.timeout property
> ----------------------------------------------------------
>
> Key: OPENJPA-927
> URL: https://issues.apache.org/jira/browse/OPENJPA-927
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 2.0.0
> Reporter: Dianne Richards
> Assignee: Dianne Richards
> Priority: Minor
> Fix For: 2.0.0
>
> Attachments: patch.txt
>
>
> This was originally reported by Pinaki in OPENJPA-849. It is being moved to this new JIRA. Here's Pinaki's original comment:
>
> queryTimeout.setLoadKey("javax.persistence.query.timeout");
> queryTimeout.setDefault("-1");
> queryTimeout.set(-1);
> queryTimeout.setDynamic(true);
> does not seem kosher for the following reason:
> 1. loadKey is the key with which a property is loaded from configuration artifacts. At this point of execution, no property has been *actually* loaded, they are merely being declared to exist. Hence we should not be setting load key.
> 2. configuration declares a Value. But does not assign its value. So setting its value to -1 does not look alright. Setting default value is OK.
> These issues gain significance in the light of the fact the configuration's hashcode is the key to a factory in JNDI. And computation of hashcode depends on the actual value of the Values.
> As an extreme example, assume two Configuration C1 and C2 nearly identical but differs *only* in their query.timeout value. The requirement is hash code for C1 and C2 must not be equal. And that is what Configuration.hashCode() ensures. But, because we are setting query timeout to -1 (that is not what the user's p.xml sets) and it is marked as dynamic, in both cases Configuration hashcode will treat query.timeout value to be -1 and will end up computing same hashcode for C1 and C2.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-927) Fix definition of
javax.persistence.query.timeout property
Posted by "Donald Woods (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Donald Woods updated OPENJPA-927:
---------------------------------
Attachment: OPENJPA-927-trunk.patch
Thanks Dianne. Here is a version of the unmodified patch for non-Eclipse users.
> Fix definition of javax.persistence.query.timeout property
> ----------------------------------------------------------
>
> Key: OPENJPA-927
> URL: https://issues.apache.org/jira/browse/OPENJPA-927
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 2.0.0
> Reporter: Dianne Richards
> Assignee: Dianne Richards
> Priority: Minor
> Fix For: 2.0.0
>
> Attachments: OPENJPA-927-trunk.patch, patch.txt
>
>
> This was originally reported by Pinaki in OPENJPA-849. It is being moved to this new JIRA. Here's Pinaki's original comment:
>
> queryTimeout.setLoadKey("javax.persistence.query.timeout");
> queryTimeout.setDefault("-1");
> queryTimeout.set(-1);
> queryTimeout.setDynamic(true);
> does not seem kosher for the following reason:
> 1. loadKey is the key with which a property is loaded from configuration artifacts. At this point of execution, no property has been *actually* loaded, they are merely being declared to exist. Hence we should not be setting load key.
> 2. configuration declares a Value. But does not assign its value. So setting its value to -1 does not look alright. Setting default value is OK.
> These issues gain significance in the light of the fact the configuration's hashcode is the key to a factory in JNDI. And computation of hashcode depends on the actual value of the Values.
> As an extreme example, assume two Configuration C1 and C2 nearly identical but differs *only* in their query.timeout value. The requirement is hash code for C1 and C2 must not be equal. And that is what Configuration.hashCode() ensures. But, because we are setting query timeout to -1 (that is not what the user's p.xml sets) and it is marked as dynamic, in both cases Configuration hashcode will treat query.timeout value to be -1 and will end up computing same hashcode for C1 and C2.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Work started: (OPENJPA-927) Fix definition of
javax.persistence.query.timeout property
Posted by "Dianne Richards (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Work on OPENJPA-927 started by Dianne Richards.
> Fix definition of javax.persistence.query.timeout property
> ----------------------------------------------------------
>
> Key: OPENJPA-927
> URL: https://issues.apache.org/jira/browse/OPENJPA-927
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 2.0.0
> Reporter: Dianne Richards
> Assignee: Dianne Richards
> Priority: Minor
> Fix For: 2.0.0
>
>
> This was originally reported by Pinaki in OPENJPA-849. It is being moved to this new JIRA. Here's Pinaki's original comment:
>
> queryTimeout.setLoadKey("javax.persistence.query.timeout");
> queryTimeout.setDefault("-1");
> queryTimeout.set(-1);
> queryTimeout.setDynamic(true);
> does not seem kosher for the following reason:
> 1. loadKey is the key with which a property is loaded from configuration artifacts. At this point of execution, no property has been *actually* loaded, they are merely being declared to exist. Hence we should not be setting load key.
> 2. configuration declares a Value. But does not assign its value. So setting its value to -1 does not look alright. Setting default value is OK.
> These issues gain significance in the light of the fact the configuration's hashcode is the key to a factory in JNDI. And computation of hashcode depends on the actual value of the Values.
> As an extreme example, assume two Configuration C1 and C2 nearly identical but differs *only* in their query.timeout value. The requirement is hash code for C1 and C2 must not be equal. And that is what Configuration.hashCode() ensures. But, because we are setting query timeout to -1 (that is not what the user's p.xml sets) and it is marked as dynamic, in both cases Configuration hashcode will treat query.timeout value to be -1 and will end up computing same hashcode for C1 and C2.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-927) Fix definition of
javax.persistence.query.timeout property
Posted by "Donald Woods (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678071#action_12678071 ]
Donald Woods commented on OPENJPA-927:
--------------------------------------
Dianne, your patch is working for me. Can you commit it?
> Fix definition of javax.persistence.query.timeout property
> ----------------------------------------------------------
>
> Key: OPENJPA-927
> URL: https://issues.apache.org/jira/browse/OPENJPA-927
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 2.0.0
> Reporter: Dianne Richards
> Assignee: Dianne Richards
> Priority: Minor
> Fix For: 2.0.0
>
> Attachments: OPENJPA-927-trunk.patch, patch.txt
>
>
> This was originally reported by Pinaki in OPENJPA-849. It is being moved to this new JIRA. Here's Pinaki's original comment:
>
> queryTimeout.setLoadKey("javax.persistence.query.timeout");
> queryTimeout.setDefault("-1");
> queryTimeout.set(-1);
> queryTimeout.setDynamic(true);
> does not seem kosher for the following reason:
> 1. loadKey is the key with which a property is loaded from configuration artifacts. At this point of execution, no property has been *actually* loaded, they are merely being declared to exist. Hence we should not be setting load key.
> 2. configuration declares a Value. But does not assign its value. So setting its value to -1 does not look alright. Setting default value is OK.
> These issues gain significance in the light of the fact the configuration's hashcode is the key to a factory in JNDI. And computation of hashcode depends on the actual value of the Values.
> As an extreme example, assume two Configuration C1 and C2 nearly identical but differs *only* in their query.timeout value. The requirement is hash code for C1 and C2 must not be equal. And that is what Configuration.hashCode() ensures. But, because we are setting query timeout to -1 (that is not what the user's p.xml sets) and it is marked as dynamic, in both cases Configuration hashcode will treat query.timeout value to be -1 and will end up computing same hashcode for C1 and C2.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-927) Fix definition of
javax.persistence.query.timeout property
Posted by "Donald Woods (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12676003#action_12676003 ]
Donald Woods commented on OPENJPA-927:
--------------------------------------
Note: my patch is a lot larger, as it removes the Windows ^M chars off every line of EntityManagerImpl.java, since I have my svn config properties setup as suggested by the ASF....
> Fix definition of javax.persistence.query.timeout property
> ----------------------------------------------------------
>
> Key: OPENJPA-927
> URL: https://issues.apache.org/jira/browse/OPENJPA-927
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 2.0.0
> Reporter: Dianne Richards
> Assignee: Dianne Richards
> Priority: Minor
> Fix For: 2.0.0
>
> Attachments: OPENJPA-927-trunk.patch, patch.txt
>
>
> This was originally reported by Pinaki in OPENJPA-849. It is being moved to this new JIRA. Here's Pinaki's original comment:
>
> queryTimeout.setLoadKey("javax.persistence.query.timeout");
> queryTimeout.setDefault("-1");
> queryTimeout.set(-1);
> queryTimeout.setDynamic(true);
> does not seem kosher for the following reason:
> 1. loadKey is the key with which a property is loaded from configuration artifacts. At this point of execution, no property has been *actually* loaded, they are merely being declared to exist. Hence we should not be setting load key.
> 2. configuration declares a Value. But does not assign its value. So setting its value to -1 does not look alright. Setting default value is OK.
> These issues gain significance in the light of the fact the configuration's hashcode is the key to a factory in JNDI. And computation of hashcode depends on the actual value of the Values.
> As an extreme example, assume two Configuration C1 and C2 nearly identical but differs *only* in their query.timeout value. The requirement is hash code for C1 and C2 must not be equal. And that is what Configuration.hashCode() ensures. But, because we are setting query timeout to -1 (that is not what the user's p.xml sets) and it is marked as dynamic, in both cases Configuration hashcode will treat query.timeout value to be -1 and will end up computing same hashcode for C1 and C2.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-927) Fix definition of
javax.persistence.query.timeout property
Posted by "Dianne Richards (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dianne Richards resolved OPENJPA-927.
-------------------------------------
Resolution: Fixed
> Fix definition of javax.persistence.query.timeout property
> ----------------------------------------------------------
>
> Key: OPENJPA-927
> URL: https://issues.apache.org/jira/browse/OPENJPA-927
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 2.0.0
> Reporter: Dianne Richards
> Assignee: Dianne Richards
> Priority: Minor
> Fix For: 2.0.0
>
> Attachments: OPENJPA-927-trunk.patch, patch.txt
>
>
> This was originally reported by Pinaki in OPENJPA-849. It is being moved to this new JIRA. Here's Pinaki's original comment:
>
> queryTimeout.setLoadKey("javax.persistence.query.timeout");
> queryTimeout.setDefault("-1");
> queryTimeout.set(-1);
> queryTimeout.setDynamic(true);
> does not seem kosher for the following reason:
> 1. loadKey is the key with which a property is loaded from configuration artifacts. At this point of execution, no property has been *actually* loaded, they are merely being declared to exist. Hence we should not be setting load key.
> 2. configuration declares a Value. But does not assign its value. So setting its value to -1 does not look alright. Setting default value is OK.
> These issues gain significance in the light of the fact the configuration's hashcode is the key to a factory in JNDI. And computation of hashcode depends on the actual value of the Values.
> As an extreme example, assume two Configuration C1 and C2 nearly identical but differs *only* in their query.timeout value. The requirement is hash code for C1 and C2 must not be equal. And that is what Configuration.hashCode() ensures. But, because we are setting query timeout to -1 (that is not what the user's p.xml sets) and it is marked as dynamic, in both cases Configuration hashcode will treat query.timeout value to be -1 and will end up computing same hashcode for C1 and C2.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-927) Fix definition of
javax.persistence.query.timeout property
Posted by "Dianne Richards (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12674680#action_12674680 ]
Dianne Richards commented on OPENJPA-927:
-----------------------------------------
Thanks for checking this out Pinaki.
>1. loadKey is the key with which a property is loaded from configuration artifacts. At this point of execution, no property has been >*actually* loaded, they are merely being declared to exist. Hence we should not be setting load key.
I now understand this and will change it. But, we have to solve a problem if we don't do this. The getProperties() methods return all defined properties, even if they have not been explicitly set. This calls the Configuration .toProperties() method which calls the setValue() method. By default, if we don't do anything, the value javax.persistence.query.timeout will be prefixed with "openjpa.", which is not good. We can get around this doing a setEquivalentKey() instead. But, now I'm wondering what we'll get with the getSupportedProperties() with this change. I'll have to investigat that. But, if that's ok, is this a reasonable alternative? Or, should I figure out something else?
The other option is to define a new openjpa property, such as openjpa.QueryTimeout. I was trying to avoid that option. I'm not sure we want to define a new openjpa property for every new spec property.
>2. configuration declares a Value. But does not assign its value. So setting its value to -1 does not look alright. Setting default >value is OK.
ok - But, I modeled this after the openjpa.LockTimeout definition. So, does this one need to be corrected too?
> Fix definition of javax.persistence.query.timeout property
> ----------------------------------------------------------
>
> Key: OPENJPA-927
> URL: https://issues.apache.org/jira/browse/OPENJPA-927
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 2.0.0
> Reporter: Dianne Richards
> Assignee: Dianne Richards
> Priority: Minor
> Fix For: 2.0.0
>
>
> This was originally reported by Pinaki in OPENJPA-849. It is being moved to this new JIRA. Here's Pinaki's original comment:
>
> queryTimeout.setLoadKey("javax.persistence.query.timeout");
> queryTimeout.setDefault("-1");
> queryTimeout.set(-1);
> queryTimeout.setDynamic(true);
> does not seem kosher for the following reason:
> 1. loadKey is the key with which a property is loaded from configuration artifacts. At this point of execution, no property has been *actually* loaded, they are merely being declared to exist. Hence we should not be setting load key.
> 2. configuration declares a Value. But does not assign its value. So setting its value to -1 does not look alright. Setting default value is OK.
> These issues gain significance in the light of the fact the configuration's hashcode is the key to a factory in JNDI. And computation of hashcode depends on the actual value of the Values.
> As an extreme example, assume two Configuration C1 and C2 nearly identical but differs *only* in their query.timeout value. The requirement is hash code for C1 and C2 must not be equal. And that is what Configuration.hashCode() ensures. But, because we are setting query timeout to -1 (that is not what the user's p.xml sets) and it is marked as dynamic, in both cases Configuration hashcode will treat query.timeout value to be -1 and will end up computing same hashcode for C1 and C2.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-927) Fix definition of
javax.persistence.query.timeout property
Posted by "Jeremy Bauer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678868#action_12678868 ]
Jeremy Bauer commented on OPENJPA-927:
--------------------------------------
Committed Dianne's patch (with modifications) under revisions 750112 750113 750115 750117.
> Fix definition of javax.persistence.query.timeout property
> ----------------------------------------------------------
>
> Key: OPENJPA-927
> URL: https://issues.apache.org/jira/browse/OPENJPA-927
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 2.0.0
> Reporter: Dianne Richards
> Assignee: Dianne Richards
> Priority: Minor
> Fix For: 2.0.0
>
> Attachments: OPENJPA-927-trunk.patch, patch.txt
>
>
> This was originally reported by Pinaki in OPENJPA-849. It is being moved to this new JIRA. Here's Pinaki's original comment:
>
> queryTimeout.setLoadKey("javax.persistence.query.timeout");
> queryTimeout.setDefault("-1");
> queryTimeout.set(-1);
> queryTimeout.setDynamic(true);
> does not seem kosher for the following reason:
> 1. loadKey is the key with which a property is loaded from configuration artifacts. At this point of execution, no property has been *actually* loaded, they are merely being declared to exist. Hence we should not be setting load key.
> 2. configuration declares a Value. But does not assign its value. So setting its value to -1 does not look alright. Setting default value is OK.
> These issues gain significance in the light of the fact the configuration's hashcode is the key to a factory in JNDI. And computation of hashcode depends on the actual value of the Values.
> As an extreme example, assume two Configuration C1 and C2 nearly identical but differs *only* in their query.timeout value. The requirement is hash code for C1 and C2 must not be equal. And that is what Configuration.hashCode() ensures. But, because we are setting query timeout to -1 (that is not what the user's p.xml sets) and it is marked as dynamic, in both cases Configuration hashcode will treat query.timeout value to be -1 and will end up computing same hashcode for C1 and C2.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-927) Fix definition of
javax.persistence.query.timeout property
Posted by "Donald Woods (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679678#action_12679678 ]
Donald Woods commented on OPENJPA-927:
--------------------------------------
Dianne, can this be marked as resolved now?
> Fix definition of javax.persistence.query.timeout property
> ----------------------------------------------------------
>
> Key: OPENJPA-927
> URL: https://issues.apache.org/jira/browse/OPENJPA-927
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 2.0.0
> Reporter: Dianne Richards
> Assignee: Dianne Richards
> Priority: Minor
> Fix For: 2.0.0
>
> Attachments: OPENJPA-927-trunk.patch, patch.txt
>
>
> This was originally reported by Pinaki in OPENJPA-849. It is being moved to this new JIRA. Here's Pinaki's original comment:
>
> queryTimeout.setLoadKey("javax.persistence.query.timeout");
> queryTimeout.setDefault("-1");
> queryTimeout.set(-1);
> queryTimeout.setDynamic(true);
> does not seem kosher for the following reason:
> 1. loadKey is the key with which a property is loaded from configuration artifacts. At this point of execution, no property has been *actually* loaded, they are merely being declared to exist. Hence we should not be setting load key.
> 2. configuration declares a Value. But does not assign its value. So setting its value to -1 does not look alright. Setting default value is OK.
> These issues gain significance in the light of the fact the configuration's hashcode is the key to a factory in JNDI. And computation of hashcode depends on the actual value of the Values.
> As an extreme example, assume two Configuration C1 and C2 nearly identical but differs *only* in their query.timeout value. The requirement is hash code for C1 and C2 must not be equal. And that is what Configuration.hashCode() ensures. But, because we are setting query timeout to -1 (that is not what the user's p.xml sets) and it is marked as dynamic, in both cases Configuration hashcode will treat query.timeout value to be -1 and will end up computing same hashcode for C1 and C2.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-927) Fix definition of
javax.persistence.query.timeout property
Posted by "Alan Raison (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12737110#action_12737110 ]
Alan Raison commented on OPENJPA-927:
-------------------------------------
The test org.apache.openjpa.persistence.simple.TestPropertiesMethods contains a derby connection string. This is problematic if Derby is not being used to test.
I think removing the setting of the openjpa.ConnectionURL property will fix this - but I'm not sure if this nullifies the test!
> Fix definition of javax.persistence.query.timeout property
> ----------------------------------------------------------
>
> Key: OPENJPA-927
> URL: https://issues.apache.org/jira/browse/OPENJPA-927
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 2.0.0-M2
> Reporter: Dianne Richards
> Assignee: Dianne Richards
> Priority: Minor
> Fix For: 2.0.0-M2
>
> Attachments: OPENJPA-927-trunk.patch, patch.txt
>
>
> This was originally reported by Pinaki in OPENJPA-849. It is being moved to this new JIRA. Here's Pinaki's original comment:
>
> queryTimeout.setLoadKey("javax.persistence.query.timeout");
> queryTimeout.setDefault("-1");
> queryTimeout.set(-1);
> queryTimeout.setDynamic(true);
> does not seem kosher for the following reason:
> 1. loadKey is the key with which a property is loaded from configuration artifacts. At this point of execution, no property has been *actually* loaded, they are merely being declared to exist. Hence we should not be setting load key.
> 2. configuration declares a Value. But does not assign its value. So setting its value to -1 does not look alright. Setting default value is OK.
> These issues gain significance in the light of the fact the configuration's hashcode is the key to a factory in JNDI. And computation of hashcode depends on the actual value of the Values.
> As an extreme example, assume two Configuration C1 and C2 nearly identical but differs *only* in their query.timeout value. The requirement is hash code for C1 and C2 must not be equal. And that is what Configuration.hashCode() ensures. But, because we are setting query timeout to -1 (that is not what the user's p.xml sets) and it is marked as dynamic, in both cases Configuration hashcode will treat query.timeout value to be -1 and will end up computing same hashcode for C1 and C2.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.