Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Message-ID: <108222804.20971267374066047.JavaMail.jira@brutus.apache.org>
Date: Sun, 28 Feb 2010 16:21:06 +0000 (UTC)
From: "Matt Benson (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Subject: [jira] Updated: (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:all-tabpanel ]

Matt Benson updated JXPATH-129:
-------------------------------

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

  was:
MethodUtils#matchParameterTypes calls MethodUtils#matchType.  

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

        Summary: MethodLookupUtils#matchType uses TypeUtils#canConvert which causes "Ambiguous method call" exception.  (was: MethodUtils#matchType uses TypeUtils#canConvert which causes "Ambiguous method call" exception.)

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