Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Message-ID: <370474755.21681267377426739.JavaMail.jira@brutus.apache.org>
Date: Sun, 28 Feb 2010 17:17:06 +0000 (UTC)
From: "Robert Ross (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Subject: [jira] Commented: (JXPATH-129) MethodLookupUtils#matchType uses
 TypeUtils#canConvert which causes "Ambiguous method call" exception.
In-Reply-To: <776619154.1235685541978.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Robert Ross commented on JXPATH-129:
------------------------------------

I provided specific example method signatures which consistently reproduces the problem:

static final String formatISO(Calendar calendar) { return ""};
static final String formatISO(Date date) { return ""}; }

If you create a class with these two methods and then attempt to invoke one of the methods through JXPath, it will generate an "Ambiguous method call" exception.  We were forced to change the function names themselves in order to avoid the problem.  Overloaded functions with similar parameters cause this issue.  I am using JXPath 1.3.

Robert A. Ross
Senior Software Developer
DSCI Inc.
609.509.5139 - Mobile
609.702.8114 - Home


> 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.