Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
2.7
-
None
Description
Sorry for the long summary but the situation is difficult to describe in brief 
I've found a bug or at least a "notable difference" with previous (ognl 2.6.7) behaviour regarding this.
It took me some to understand what was going on as the tapestry page this expression was used for had apparently nothing strange and worked perfectly with OGNL 2.6.7. The sample code I provide below contains a Tapestry example because is where I found it but the bug seems to be completely OGNL related.
This is the situation. I have some model classes using a structure similar to this:
public interface MyInterface
{ public String getXyz(); public void setXyz(String x); public void doSomething(); }abstract class MyAbstractClass implements interface MyInterface {
public void doSomething()
{ // blah blah blah }// I don't implement the other interface methods here! leave to subclass responsability to implement it
}
public class MyConcreteClass extends MyAbstractClass {
private String xyz;
// I just implement the getters/setters of the implemented interface in the concrete class!
public String getXyz() { return xyz; }
public void setXyz(String x);
this.xyz = x;
}
}
Now I have a Tapestry page:
public abstract MyPage extends BasePage { public MyAbstractClass getMyObject() @Component(bindings="value= myobject.xyz") // This is the expression failing public abstract TextField getMyObjectTextField(); }
The page has a getter for object of type "MyAbstractClass" but obviously I'm feeding it with non abstract classes extending "MyAbstractClass that actually implement the MyInterface XYZ getters and setters.
Now, this WAS NOT failing with previous OGNL, IT'S FAILING with OGNL 2.7 complaining for non existing method signatures.
After some experimentation I've discovered that in order for this to work I need to implement, at least as an abstract method, in class MyAbstractClass the XYZ getters ans setters, turning MyAbstractClass into:
abstract class MyAbstractClass implements interface MyInterface {
public void doSomething() { // blah blah blah }
public abstract String getXyz();
public abstract void setXyz(String x);
}
After this modification it works perfectly and it obviously the solution does not affect my code at all.
I think what's missing is proper interface checking for accessing property: that is to say you might have to do with an abstract class not directly implementing an interface method and the expression evaluator should check for it. I think this should be checked by the expression evaluator.
I don't think this is really a big problem because in all situation I can think of the solution is easy and won't imply big code/behaviour modifications
but I assure you that it can take some time to figure out what is happening down there