[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-dev
Subject:    [jira] Updated: (JXPATH-129) MethodLookupUtils#matchType uses
From:       "Matt Benson (JIRA)" <jira () apache ! org>
Date:       2010-02-28 16:55:05
Message-ID: 1503858566.21391267376105803.JavaMail.jira () brutus ! apache ! org
[Download RAW message or body]


     [ https://issues.apache.org/jira/browse/JXPATH-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel \
]

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

    Attachment: MethodLookupTest.java

Test case showing apparently desirable behavior

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


[prev in list] [next in list] [prev in thread] [next in thread]