Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better way to distinguish go.x and go.getProperty("x") in JavaMockInterceptor #1076

Open
szpak opened this issue Jan 15, 2020 · 3 comments
Open

Comments

@szpak
Copy link
Member

szpak commented Jan 15, 2020

This is an issue to track an ability to better handle calling go.x when the generic Java mock implementation is used for an Groovy object in Groovy 3. Currently a working (but ugly and fragile) workaround (aka "hack") is applied, but we hope to have some better way. Related discussion on the Groovy devel mailing list.

A quotation from the original message:

TL;TR. How would be best to distinguish in Groovy 3 foo.x and foo.getProperty("x") in a call (at the level of an interceptor for a mocking system)?

More detailed version.
Working on the Spock adjustment to Groovy 3, I spotted that Groovy 3 started for a property access go.x (go - some GroovyObject instance with a field "x") to call go.getProperty("x") instead of go.getX() directly (as it took place in Groovy 2). This broke tests for mocking with a property call (getX() is stubbed, but go.x is called) and forced me to detect getProperty("x") calls in a mock interceptor - to analyze deeper and check which method (here getter) is being called and if has been stubbed.

However, in addition, it should be possible to just stub direct go.getProperty("x") calls [1]. To do that, currently, I have to analyze a stack trace to detect groovy.lang.GroovyObject$getProperty.call() at
the position -3 [2] (for direct go.getProperty("x") calls) and deeper process only the other calls (go.x). It seems to work, but it's quite ugly and fragile. I wonder, how to reliably differentiate those two types of calls?

@szpak
Copy link
Member Author

szpak commented Jan 17, 2020

Created an issue in Groovy: https://issues.apache.org/jira/browse/GROOVY-9369 . Paul K. declared to take a look at that in the Groovy 4 development.

@AndreasTu
Copy link
Member

This problem gets worse with Groovy >=4.0.7, because it uses now indy as default, which makes the current used hack in BaseMockInterceptor checking the caller stack useless due to MethodHandle/Indy frames.
#1752 adds a test case for the behavior of >=4.0.7.

@leonard84
Copy link
Member

Probably related #1815

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants