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