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