[ 
https://issues.apache.org/jira/browse/JEXL-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16324122#comment-16324122
 ] 

Dmitri Blinov commented on JEXL-246:
------------------------------------

As it has turned out for me, Jexl restricts me, for some reason, from 
overloading operators in Arithmetic, if the operator signature is of 
generalized form, like {{operator(Object)}} or {{operator(Object, Object)}}. So 
the idea of having {{public JexlOperator selfAdd(Object x, Object y)}} does not 
apply. I don't know if it worth raising an issue about that, or it's better to 
find more appropriate the solution to the original problem. Lets not 
over-complicate. Suppose, we have an original script for {{z += 1}} and 
standard Arithmetic without any {{selfAdd}} overloaded operators. Should this 
work for an empty z value? I think it should. So, it should work exactly the 
same as with any number of {{selfAdd}} overloaded operators too. It's not an 
ambiguity, it's like Jexl couldn't find an appropriate overloaded operator for 
this case, and reverted to the default implementation.

> 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
(v6.4.14#64029)

Reply via email to