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?