Details
-
Bug
-
Status: Closed
-
Critical
-
Resolution: Fixed
-
1.7.0
-
None
-
None
-
Tested on an AMD Turion64 under WinXP with Eclipse Galileo, Java 6u17, will occur on any platform though since this are groovy source code bugs.
Description
When a class offers a getter or setter (but not both) for a property, which is also accessible without that getter or setter breaks, the MOP's according MetaProperty is broken in terms of access permission: A (visible) property with additional setter is marked "write only", and one with additional getter "read only".
I have attached a test case which shows all four possible variants, two of which are broken:
For each variant, first, read and write access to the property are done by simply accessing the property. This proves, that both read and write access should be possible to that property.
Then, read and write access are done again, this time using the properties MetaProperty.
No getter, no setter.
for propertyOne (line 6), neither a getter, nor a setter is defined. The according test (line 27 to 34) passes: The normal access and the MetaProperty can be read and written. It is neither marked read-only, nor write-only, just as it is supposed to be.
Setter only.
for propertyTwo(line 7), only a setter is defined (line 11 to 13). The according test (line 36 to 43) fails: The normal access works fine, also setting the MetaProperty is possible, but when trying to read the MetaProperty, a GroovyRuntimeException is thrown: "Cannot read write-only property: propertyTwo", although it should be possible to read it directly without a setter (as done in line 38), but the MOP does not respect that.
Getter only.
for propertyThree(line 8), only a getter is defined (line 15 to 17). The according test (line 45 to 52) fails just like the previous one, except this time read access is possible and write access fails, and the exception states, this was a read-only property, which it is not. Direct write access without a setter (as done in line 46) should be possible.
Getter and Setter
for propertyFour(line 9), both a getter (lines 19 to 21) and a setter (lines 23 to 25) are defined. The according test (lines 54 to 61) passes just like the first test, where neither were defined. Again, the meta property is neither marked write-only or read-only, as it is supposed to be.
few final words
This bug prevents MetaClasses, from implementing get/setProperty(object, name[, value]) by forwarding it to getMeta/hasProperty(name).get/setProperty(object[, value]). This is very disturbing if you redefined getMetaProperty or hasProperty (where's the difference in these methods by the way?) to perform additional searches to find properties, and you simply want to invoke the returned meta property instead of first determining, if you should ignore the returned meta property and call super.get/setProperty(..) because the meta property invocation might fail with such a misplaced access violation.