Exception selecting overloaded method in 3.1.4

[danielfernandez]

In Thymeleaf there is an Aggregates class which contains an overloaded avg(...) method. See the specific class here.

All the different variants of this method look like this:

    public BigDecimal avg(final Iterable<? extends Number> target) {...}
    public BigDecimal avg(final Number[] target) {...}
    public BigDecimal avg(final byte[] target) {...}
    public BigDecimal avg(final short[] target) {...}
    public BigDecimal avg(final int[] target) {...}
    public BigDecimal avg(final long[] target) {...}    
    public BigDecimal avg(final float[] target) {...}
    public BigDecimal avg(final double[] target) {...}

In one of my tests, I create an object using an OGNL expression, like:

nums01 = { 5, 5 }

Which creates a java.util.ArrayList<java.lang.Integer> for the nums01 variable.

Then I use this variable as an argument to an avg call in an OGNL expression such as:

#aggregates.avg(nums01)

This worked perfectly until OGNL 3.1.3, and the first version of the overloaded method (the one receiving an Iterable<? extends Number>) was executed. However, in OGNL 3.1.4 I receive this exception:

java.lang.IllegalArgumentException: Can't decide wich method to use: "public java.math.BigDecimal org.thymeleaf.expression.Aggregates.avg(float[])" or "public java.math.BigDecimal org.thymeleaf.expression.Aggregates.avg(long[])"
    at ognl.OgnlRuntime.findBestMethod(OgnlRuntime.java:1427)
    at ognl.OgnlRuntime.getAppropriateMethod(OgnlRuntime.java:1283)
    at ognl.OgnlRuntime.callAppropriateMethod(OgnlRuntime.java:1452)
    at ognl.ObjectMethodAccessor.callMethod(ObjectMethodAccessor.java:68)
    at ognl.OgnlRuntime.callMethod(OgnlRuntime.java:1598)
    at ognl.ASTMethod.getValueBody(ASTMethod.java:91)
    at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:212)
    at ognl.SimpleNode.getValue(SimpleNode.java:258)
    at ognl.ASTChain.getValueBody(ASTChain.java:141)
    at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:212)
    at ognl.SimpleNode.getValue(SimpleNode.java:258)
    at ognl.Ognl.getValue(Ognl.java:494)
    at ognl.Ognl.getValue(Ognl.java:458)

[lukaszlenart]

It can be only related to #19

[marvkis]

Hi.

#19 was originally made by me. I'll take a look into that issue...

Sorry for the late reply it seems somehow my github email notification's dont work and I just disovered this by chance...

[lukaszlenart]

@marvkis great, thanks a lot!

[marvkis]

Okay, I have an idea what's going wrong:
Initially in AstMethod.getChildrenClasses() implementation for ASTList I already had a parametrized array as returning type that hold's the information about the appropriate carried class types. But as this didn't reflect ASTList's real behavior - returning an ArrayList - this wasn't the right way so I changed it to return a list. List itself is a generic type, but as far as I know a 'Class' can't be parametrized easily so the 'inner' type information got lost and so the method weighting can't make a clean decision...

Have to dig into that... but it must work somehow, when refactoring into a class the returning types are parametrized...

[marvkis]

After some investigation:

The "Generics" approach is the wrong way. I started an approach to use a "typed class carrier" but it was the wrong way. It worked quite well for "compiled" OGNL commands, but it failed during interpretation - Interpretation is done on live objects and not on classes, and due to "Generics Type Erasure" generics type information is only available during compilation and not any more during run time. So i abandoned this approach - it's still here for whom it might interest: Issue-23-Generics

So, as always if you ran into the wrong direction, change your perspective: What does java itself when it has to call avg() with a java.util.List argument? And indeed, it chooses the avg(Iterable...) method.

And it didn't work because the OgnlRuntime.isTypeCompatible() bailed out with an exception to early instead of continuing if there is a better matching method.
I also had to change the method weighting and matching a bit with the 'Generics Type Erasure' in mind: A java.util.List only will match to an Object[] array during runtime. With this in mind all Unit-Tests worked again.

Btw: sa-ChristianNiessner is my 'work' account and marvkis my personal / private account. I did this during work hours so the credit is for my company ;)

[lukaszlenart]

@marvkis aka sa-ChristianNiessner please provide your company name and I will used in Version Notes :)

[marvin-enthus]

@lukaszlenart it is 'secadm GmbH' - http://www.secadm.de/ . thanks a lot.

@danielfernandez Was this discovered in an unit test of thymeleaf or during runtime? Can you do further 'real life' tests?

@lukaszlenart can you test it within struts to see if the changes perform fine or bring up another issues?

thanks!

[danielfernandez]

Do we already have a snapshot for this? if so, what's OGNL's Maven snapshots repository?

[lukaszlenart]

@danielfernandez just pushed it to https://oss.sonatype.org/content/repositories/snapshots/

[danielfernandez]

I can confirm all Thymeleaf tests pass with 3.1.5-SNAPSHOT, including the dozen tests that fail with 3.1.4

[lukaszlenart]

Fixed with #24

[lukaszlenart]

3.1.5 is under way to the Central, thanks @sa-ChristianNiessner and @danielfernandez !