groovy

Calling a method overwritten via metaClass from another method uses the original (non-overwritten) method

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.8.0
  • Fix Version/s: 1.8.1
  • Component/s: primtive opts
  • Labels:
    None
  • Number of attachments :
    0

Description

Having the following code...

class A {
    String m1() { println 'called m1'; 'm1' }
    String m2() { println 'called m2'; println m1(); 'm2' }
}
a = new A()                                                                                                   
a.metaClass.m1 = { -> println 'pwned m1'; 'o-m1' }

Calling a.m2() shows...

called m2
called m1
m1
===> m2

...but expected is this:

called m2
pwned m1
o-m1
===> m2

The correct output is shown in Groovy 1.7.x, only Groovy 1.8.0 shows the wrong one.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Tim Yates added a comment -

Oddly, works as expected on the Groovy Web Console (which I believe is running 1.8.0?)...

Show
Tim Yates added a comment - Oddly, works as expected on the Groovy Web Console (which I believe is running 1.8.0?)...
Hide
Permalink
Guillaume Laforge added a comment -

Groovy Web Console indeed runs 1.8.0.

Show
Guillaume Laforge added a comment - Groovy Web Console indeed runs 1.8.0.
Hide
Permalink
Jason Griffith added a comment -

We appear to be hitting this in our tests... Upgrading from 1.7.5 to 1.8.0 broke tests that verified values by overriding m1()-type methods and checking what m2() was passing in.

We've tried the 1.8.1 snapshot, but our tests still fail.

I'd be happy to attach an example, but it doesn't vary much from Rene's code. Please let me know if there's anything I can do to help!

Show
Jason Griffith added a comment - We appear to be hitting this in our tests... Upgrading from 1.7.5 to 1.8.0 broke tests that verified values by overriding m1()-type methods and checking what m2() was passing in. We've tried the 1.8.1 snapshot, but our tests still fail. I'd be happy to attach an example, but it doesn't vary much from Rene's code. Please let me know if there's anything I can do to help!
Hide
Permalink
blackdrag blackdrag added a comment -

should be fixed now

Show
blackdrag blackdrag added a comment - should be fixed now
Hide
Permalink
Jason Griffith added a comment -

Hi Jochen,

Rene's example works, and more of our tests pass with 1.8.1, but we're still having problems with what looks like a variant of the problem.

This is a stripped-down version of a test that passes with 1.7.6 but fails with 1.8.1:

import org.junit.Test;

public class BreakingExample_NoMetaclassOverride {
   @Test
   void testNotOverriden() {
      def list = []
      ClassUnderTest cut = new ClassUnderTest()
      cut.metaClass.getRemoteObject = { ->
         return [method: {obj -> 
            list << obj
         }] as RemoteObject
      }
      
      String val = "Value" 
      cut.someMethod(val)
      assert list == [val]
   }
}

public class ClassUnderTest {
   public def someMethod(String someValue) {
      RemoteObject object = getRemoteObject()
      object.method(someValue)
   }
   protected RemoteObject getRemoteObject() {
      return new RemoteObject()
   }
}

public class RemoteObject {
   public void method(obj) { /* Something */ }
}

Is this a bug or a change in how the metaClass works?

Thank you!
Jason

Show
Jason Griffith added a comment - Hi Jochen, Rene's example works, and more of our tests pass with 1.8.1, but we're still having problems with what looks like a variant of the problem. This is a stripped-down version of a test that passes with 1.7.6 but fails with 1.8.1: import org.junit.Test; public class BreakingExample_NoMetaclassOverride { @Test void testNotOverriden() { def list = [] ClassUnderTest cut = new ClassUnderTest() cut.metaClass.getRemoteObject = { -> return [method: {obj -> list << obj }] as RemoteObject } String val = "Value" cut.someMethod(val) assert list == [val] } } public class ClassUnderTest { public def someMethod( String someValue) { RemoteObject object = getRemoteObject() object.method(someValue) } protected RemoteObject getRemoteObject() { return new RemoteObject() } } public class RemoteObject { public void method(obj) { /* Something */ } } Is this a bug or a change in how the metaClass works? Thank you! Jason
Hide
Permalink
blackdrag blackdrag added a comment -

your code works for me in trunk.

Show
blackdrag blackdrag added a comment - your code works for me in trunk.
Hide
Permalink
John Bito added a comment -

Seems we either need another issue to track the fix into 1.8.x or re-open this issue. If it's not appropriate to re-open this, we can make a new report for the problem Jason identified in 1.8.1.

Show
John Bito added a comment - Seems we either need another issue to track the fix into 1.8.x or re-open this issue. If it's not appropriate to re-open this, we can make a new report for the problem Jason identified in 1.8.1.
Hide
Permalink
blackdrag blackdrag added a comment -

please open a new issue

Show
blackdrag blackdrag added a comment - please open a new issue
Hide
Permalink
Jason Griffith added a comment -

Looks like Eclipse and/or I messed up the build order... The Groovy-Eclipse plugin (currently) comes with Groovy 1.8.0. Once I made sure I had groovy-all-1.8.1.jar ahead of "Groovy Libraries" in the Order and Export list, the example I posted worked.

The test it came from still fails in Eclipse, but that looks like further Eclipse wackiness... The failing test passes by cleaning, building and testing from command-line Ant using only 1.8.1.

Thanks for taking a look, Jochen!

Show
Jason Griffith added a comment - Looks like Eclipse and/or I messed up the build order... The Groovy-Eclipse plugin (currently) comes with Groovy 1.8.0. Once I made sure I had groovy-all-1.8.1.jar ahead of "Groovy Libraries" in the Order and Export list, the example I posted worked. The test it came from still fails in Eclipse, but that looks like further Eclipse wackiness... The failing test passes by cleaning, building and testing from command-line Ant using only 1.8.1. Thanks for taking a look, Jochen!

People

  • Assignee:
    blackdrag blackdrag
    Reporter:
    Rene Scheibe
Vote (2)
Watch (3)

Dates

  • Created:
    Updated:
    Resolved: