commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Benson (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JXPATH-129) MethodLookupUtils#matchType uses TypeUtils#canConvert which causes "Ambiguous method call" exception.
Date Mon, 01 Mar 2010 16:48:05 GMT

    [ https://issues.apache.org/jira/browse/JXPATH-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839747#action_12839747
] 

Matt Benson commented on JXPATH-129:
------------------------------------

My test, if you would review the attachment, differs from your example in two respects only:
 my methods (a) are not declared as final (which in my understanding is moot in the case of
a static method), and (b) are called "toString" rather than "formatISO".  Are you suggesting
that it is one of these two items causing me to get different results than you?  If not, again,
I would ask you to tell me what I have done wrong that stops me from getting your results.
 Was I correct to assume that you were speaking of registering your ExampleClass as a provider
of extension functions, or have I somehow forgotten some other mechanism by which you are
attempting to invoke these methods?

> MethodLookupUtils#matchType uses TypeUtils#canConvert which causes "Ambiguous method
call" exception.
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JXPATH-129
>                 URL: https://issues.apache.org/jira/browse/JXPATH-129
>             Project: Commons JXPath
>          Issue Type: Bug
>         Environment: Not relevant.
>            Reporter: Robert Ross
>             Fix For: 1.4
>
>         Attachments: MethodLookupTest.java
>
>
> MethodLookupUtils#matchParameterTypes calls MethodUtils#matchType.  
> MethodLookupUtils#matchType includes this:
>         if (TypeUtils.canConvert(object, expected)) {
>             return APPROXIMATE_MATCH;
>         }
> This goes through a whole process of attempting to convert types using JXPath-specific
conversion routines.  However, this is not valid logic when attempting to find matching Methods
since overloaded functions with "convertable" parameters would still have different function
signatures.
> An example:
> abstract class ExampleClass
> {
>      static final String formatISO(Calendar calendar) { return ""};
>      static final String formatISO(Date date) { return ""};
> }
> If referenced from JXPath with "ExampleClass.formatISO(pathToDateObject)", these two
functions would trigger JXPathException("lookupMethod() Ambiguous method call: " + name) because
apparently TypeUtils is able to convert a Calendar to a Date and vice-versa.
> When attempting to retrieve a function via signature, is it not irrelevant whether JXPath
is able to convert a parameter's type or not?  Is there a way to change this behavior or provide
a way to toggle this behavior similar to the setLenient() method.
> Also, the word "Ambiguous" is spelled incorrectly as "Ambigous" three times in MethodLookupUtils.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message