[ 
https://issues.apache.org/jira/browse/JEXL-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Henri Biestro resolved JEXL-246.
--------------------------------
    Resolution: Fixed

Uberspect on JexlArithmetic now properly sees all operator methods that are not 
mere overrides of base implementation. For instance 'JexlOperator 
selfAdd(Object...' is now detected.

MethodKey has relaxed rules wrt ambiguity with nulls; if there are several 
applicable method and one the parameter is null, if one applicable defines this 
parameter as an Object, no ambiguity will be reported and that method will be 
chosen. In other words, when null is present as argument, parameter of type 
Object is considered the best match (over more precisely typed parameters).

src/main/java/org/apache/commons/jexl3/internal/introspection/MethodKey.java
src/main/java/org/apache/commons/jexl3/internal/introspection/Uberspect.java
src/test/java/org/apache/commons/jexl3/IssuesTest200.java
src/test/java/org/apache/commons/jexl3/SideEffectTest.java

Committed revision 1821295.

> Intermittent ambiguous method invocation when processing assignOverload
> -----------------------------------------------------------------------
>
>                 Key: JEXL-246
>                 URL: https://issues.apache.org/jira/browse/JEXL-246
>             Project: Commons JEXL
>          Issue Type: Bug
>    Affects Versions: 3.1
>            Reporter: Dmitri Blinov
>            Assignee: Henri Biestro
>            Priority: Minor
>             Fix For: 3.2
>
>
> Sometimes the simple operator like {code}z += 1{code} when {{z}} has not been 
> defined yet raises an exception 
> {{org.apache.commons.jexl3.internal.introspection.MethodKey$AmbiguousException}}
>  with the following stack trace: 
> {quote}
> ambiguous method invocation: MyArithmetic.selfAdd(null, java.lang.Integer)
> org.apache.commons.jexl3.internal.introspection.MethodKey$AmbiguousException: 
> null
>       at 
> org.apache.commons.jexl3.internal.introspection.MethodKey$Parameters.getMostSpecific(MethodKey.java:540)
>       at 
> org.apache.commons.jexl3.internal.introspection.MethodKey$Parameters.access$000(MethodKey.java:452)
>       at 
> org.apache.commons.jexl3.internal.introspection.MethodKey.getMostSpecificMethod(MethodKey.java:261)
>       at 
> org.apache.commons.jexl3.internal.introspection.ClassMap.getMethod(ClassMap.java:178)
>  
>       at 
> org.apache.commons.jexl3.internal.introspection.Introspector.getMethod(Introspector.java:146)
>       at 
> org.apache.commons.jexl3.internal.introspection.MethodExecutor.discover(MethodExecutor.java:52)
>       at 
> org.apache.commons.jexl3.internal.introspection.Uberspect.getMethod(Uberspect.java:218)
>  
>       at MyUberspect.getMethod(MyUberspect.java:168)
>       at 
> org.apache.commons.jexl3.internal.introspection.Uberspect$ArithmeticUberspect.getOperator(Uberspect.java:413)
>       at 
> org.apache.commons.jexl3.internal.Operators.tryOverload(Operators.java:85) 
>       at 
> org.apache.commons.jexl3.internal.Operators.tryAssignOverload(Operators.java:118)
>  
>       at 
> org.apache.commons.jexl3.internal.Interpreter.executeAssign(Interpreter.java:1292)
>  
>       at 
> org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1102) 
> ....
> {quote}
> The class MyArithmetic contains a couple of overloaded
> {{public JexlOperator selfAdd(T x, Object y)}} methods with the first 
> argument being the desired type {{T}} like {{Appendable}} or {{Collection}} 
> for which the {{+=}} operator is overloaded.
> Obviously in case where the first argument is null and the second argument is 
> an Integer it is not possible to differentiate between {{public JexlOperator 
> selfAdd(Collection x, Object y)}} and {{public JexlOperator 
> selfAdd(Appendable x, Object y)}} but I wonder is there any point in trying 
> to perform {{selfAdd}} on the null variable? What questions me more is that 
> this error is intermittent and sometimes there is an exception and sometimes 
> there is not, so at the moment I have no test case to reproduce. So I think 
> this is a bug.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to