commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Biestro (JIRA)" <>
Subject [jira] [Resolved] (JEXL-246) Intermittent ambiguous method invocation when processing assignOverload
Date Mon, 08 Jan 2018 15:17:00 GMT


Henri Biestro resolved JEXL-246.
       Resolution: Fixed
    Fix Version/s: 3.2

The behavior is not intermittent; when JEXL detects an ambiguity when resolving a method,
it will log this exception as an info (using the JEXL engine logger if configured to allow
these) and will remember this signature as a cache-miss. The second time this resolution is
attempted, the cache-miss will be detected to return a null (and avoid throwing the same exception
In effect, the MethodKey.AmbiguousException will only be logged once (per lifetime of the

The fix though is to make it clearer what the error is due to; in the accompanying case, it
is due to a null operand (z) during operator evaluation.


Committed revision 1820568.

> Intermittent ambiguous method invocation when processing assignOverload
> -----------------------------------------------------------------------
>                 Key: JEXL-246
>                 URL:
>             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(
> 	at org.apache.commons.jexl3.internal.introspection.MethodKey$Parameters.access$000(
> 	at org.apache.commons.jexl3.internal.introspection.MethodKey.getMostSpecificMethod(
> 	at org.apache.commons.jexl3.internal.introspection.ClassMap.getMethod(

> 	at org.apache.commons.jexl3.internal.introspection.Introspector.getMethod(
> 	at
> 	at org.apache.commons.jexl3.internal.introspection.Uberspect.getMethod(

> 	at MyUberspect.getMethod(
> 	at org.apache.commons.jexl3.internal.introspection.Uberspect$ArithmeticUberspect.getOperator(
> 	at org.apache.commons.jexl3.internal.Operators.tryOverload( 
> 	at org.apache.commons.jexl3.internal.Operators.tryAssignOverload(

> 	at org.apache.commons.jexl3.internal.Interpreter.executeAssign(

> 	at org.apache.commons.jexl3.internal.Interpreter.visit( 
> ....
> {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

View raw message