You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@click.apache.org by Alvin Townsend <al...@gmail.com> on 2008/10/19 20:33:20 UTC
"Wrong Number of Arguments" Error in Form.copyTo()
Hi All,
I'm wondering if anyone else has seen this error before when using
form.copyTo(myObject, false):
java.lang.IllegalArgumentException: wrong number of arguments
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at net.sf.click.util.ContainerUtils.ensureObjectPathNotNull(ContainerUtils.java:592)
at net.sf.click.util.ContainerUtils.copyContainerToObject(ContainerUtils.java:318)
at net.sf.click.util.ContainerUtils.copyContainerToObject(ContainerUtils.java:355)
at net.sf.click.control.Form.copyTo(Form.java:1710)
at com.globalpay.lrs.ui.page.admin.ReferralPartnerEditor.onSubmitClick(ReferralPartnerEditor.java:147)
It's very odd, Form.copyTo() has been working very well up to this
point, only happens in one place in our application, and only when
adding a new entity. Error doesn't happen when editing an existing
entity. We're using the latest version of Click from trunk at the
moment - 1.5-pre-RC3 I guess. :-)
Any ideas? I've been at this a day and I'm at a total loss...
Thanks!
Alvin
Re: "Wrong Number of Arguments" Error in Form.copyTo()
Posted by Alvin Townsend <al...@gmail.com>.
Hi Bob,
Beat to the punch! :-)
To that point then, my tests indicate that the bug is resolved.
Thanks!
Alvin
On Mon, Oct 20, 2008 at 5:00 PM, Bob Schellink <sa...@gmail.com> wrote:
> Thanks Alvin, there is already a JIRA opened:
> http://www.avoka.com/jira/browse/CLK-461 :)
>
> Was waiting for your confirmation before closing this against 1.5.
>
>
> Alvin Townsend wrote:
>>
>> Hi Bob,
>>
>> Perfect. Would it be useful for me to report a bug in JIRA so the
>> patch can be applied to a known issue and more easily reported when
>> building?
>>
>> Thanks,
>>
>> Alvin
>>
>> On Mon, Oct 20, 2008 at 4:48 PM, Bob Schellink <sa...@gmail.com> wrote:
>>
>>>
>>> Hi Alvin,
>>>
>>> Alvin Townsend wrote:
>>>
>>>>
>>>> Your change fixed the problem. The form values were copied to the
>>>> object correctly, nothing went BOOM, and all proceeded as expected.
>>>>
>>>
>>> Glad to hear :)
>>>
>>>
>>>>
>>>> I am assuming that the fix is *not* in RC3? If not, are you planning
>>>> on an RC4 or should I get the source for RC3, add the patch, and go
>>>> with that?
>>>>
>>>>
>>>
>>> Unfortunately this patch is not included in RC3 as that was already
>>> released
>>> last night.
>>>
>>> If things go well 1.5 final will be released in 2 weeks so you should
>>> probably patch against trunk for now.
>>>
>>> kind regards
>>>
>>> bob
>>>
>>>
>>
>>
>
>
Re: "Wrong Number of Arguments" Error in Form.copyTo()
Posted by Bob Schellink <sa...@gmail.com>.
Thanks Alvin, there is already a JIRA opened:
http://www.avoka.com/jira/browse/CLK-461 :)
Was waiting for your confirmation before closing this against 1.5.
Alvin Townsend wrote:
> Hi Bob,
>
> Perfect. Would it be useful for me to report a bug in JIRA so the
> patch can be applied to a known issue and more easily reported when
> building?
>
> Thanks,
>
> Alvin
>
> On Mon, Oct 20, 2008 at 4:48 PM, Bob Schellink <sa...@gmail.com> wrote:
>
>> Hi Alvin,
>>
>> Alvin Townsend wrote:
>>
>>> Your change fixed the problem. The form values were copied to the
>>> object correctly, nothing went BOOM, and all proceeded as expected.
>>>
>> Glad to hear :)
>>
>>
>>> I am assuming that the fix is *not* in RC3? If not, are you planning
>>> on an RC4 or should I get the source for RC3, add the patch, and go
>>> with that?
>>>
>>>
>> Unfortunately this patch is not included in RC3 as that was already released
>> last night.
>>
>> If things go well 1.5 final will be released in 2 weeks so you should
>> probably patch against trunk for now.
>>
>> kind regards
>>
>> bob
>>
>>
>
>
Re: "Wrong Number of Arguments" Error in Form.copyTo()
Posted by Alvin Townsend <al...@gmail.com>.
Hi Bob,
Perfect. Would it be useful for me to report a bug in JIRA so the
patch can be applied to a known issue and more easily reported when
building?
Thanks,
Alvin
On Mon, Oct 20, 2008 at 4:48 PM, Bob Schellink <sa...@gmail.com> wrote:
> Hi Alvin,
>
> Alvin Townsend wrote:
>>
>> Your change fixed the problem. The form values were copied to the
>> object correctly, nothing went BOOM, and all proceeded as expected.
>
> Glad to hear :)
>
>> I am assuming that the fix is *not* in RC3? If not, are you planning
>> on an RC4 or should I get the source for RC3, add the patch, and go
>> with that?
>>
>
> Unfortunately this patch is not included in RC3 as that was already released
> last night.
>
> If things go well 1.5 final will be released in 2 weeks so you should
> probably patch against trunk for now.
>
> kind regards
>
> bob
>
Re: "Wrong Number of Arguments" Error in Form.copyTo()
Posted by Bob Schellink <sa...@gmail.com>.
Hi Alvin,
Alvin Townsend wrote:
> Your change fixed the problem. The form values were copied to the
> object correctly, nothing went BOOM, and all proceeded as expected.
Glad to hear :)
> I am assuming that the fix is *not* in RC3? If not, are you planning
> on an RC4 or should I get the source for RC3, add the patch, and go
> with that?
>
Unfortunately this patch is not included in RC3 as that was already
released last night.
If things go well 1.5 final will be released in 2 weeks so you should
probably patch against trunk for now.
kind regards
bob
Re: "Wrong Number of Arguments" Error in Form.copyTo()
Posted by Alvin Townsend <al...@gmail.com>.
Hi Bob,
Your change fixed the problem. The form values were copied to the
object correctly, nothing went BOOM, and all proceeded as expected.
I am assuming that the fix is *not* in RC3? If not, are you planning
on an RC4 or should I get the source for RC3, add the patch, and go
with that?
Thank you!
Alvin
On Mon, Oct 20, 2008 at 1:40 PM, Alvin Townsend
<al...@gmail.com> wrote:
> Bob,
>
> I will download and test and let you know the results.
>
> Thank you much.
>
> Alvin
>
> On Mon, Oct 20, 2008 at 12:40 PM, Bob Schellink <sa...@gmail.com> wrote:
>> Hi Alvin,
>>
>> I've checked in some code today which might resolve your issue.
>>
>> If you have multiple overloaded getters (e.g. getters with same name but
>> different args) in your class, it seems that Click might pick the wrong
>> getter which accepts arguments. This could lead to the error you experience.
>>
>> You can test this by replacing your copy of net.sf.click.util.ContainerUtils
>> with this one:
>> http://click.svn.sourceforge.net/viewvc/click/trunk/click/framework/src/net/sf/click/util/ContainerUtils.java?revision=3540
>>
>> Let us know if that resolves the issue.
>>
>> Thanks.
>>
>> bob
>>
>> Bob Schellink wrote:
>>>
>>> Hmm nasty. Are you using JDK 1.4 or 1.5?
>>>
>>> Perhaps you have a getter which accepts an argument? That would certainly
>>> throw IllegalArgumentException too.
>>>
>>> Anyway I think we need to improve the exception handling a bit to provide
>>> more information for debugging.
>>>
>>> Below is my proposed change to ContainerUtils#ensureObjectPathNotNull.
>>>
>>> If you can replace the method with the one below it should provide better
>>> info on which method with what parameter
>>> is giving problems.
>>>
>>> Let me know if this shed some light on the issue.
>>>
>>>
>>> private static void ensureObjectPathNotNull(Object object, String path) {
>>>
>>> final int index = path.indexOf('.');
>>>
>>> if (index == -1) {
>>> return;
>>> }
>>>
>>> String value = path.substring(0, index);
>>> String getterName = ClickUtils.toGetterName(value);
>>> String isGetterName = ClickUtils.toIsGetterName(value);
>>>
>>> Method foundMethod = null;
>>> Method[] methods = object.getClass().getMethods();
>>> for (int i = 0; i < methods.length; i++) {
>>> String name = methods[i].getName();
>>> if (name.equals(getterName)) {
>>> foundMethod = methods[i];
>>> break;
>>>
>>> } else if (name.equals(isGetterName)) {
>>> foundMethod = methods[i];
>>> break;
>>> }
>>> }
>>>
>>> if (foundMethod == null) {
>>> String msg =
>>> "Getter method not found on class : " + object.getClass()
>>> + " for path value : " + value;
>>> throw new RuntimeException(msg);
>>> }
>>>
>>> try {
>>> Object result = foundMethod.invoke(object, new Object[0]);
>>>
>>> if (result == null) {
>>> result = foundMethod.getReturnType().newInstance();
>>>
>>> String setterName = ClickUtils.toSetterName(value);
>>> Class[] classArgs = { foundMethod.getReturnType() };
>>>
>>> Method setterMethod =
>>> object.getClass().getMethod(setterName, classArgs);
>>>
>>> Object[] objectArgs = { result };
>>>
>>> setterMethod.invoke(object, objectArgs);
>>> }
>>>
>>> String remainingPath = path.substring(index + 1);
>>>
>>> ensureObjectPathNotNull(result, remainingPath);
>>>
>>> } catch (Exception e) {
>>> HtmlStringBuffer buffer = new HtmlStringBuffer();
>>> Class[] parameterTypes = foundMethod.getParameterTypes();
>>> buffer.append("(");
>>> if (parameterTypes != null) {
>>> for (int i = 0; i < parameterTypes.length; i++) {
>>> buffer.append(parameterTypes[i].getName());
>>> if (i < parameterTypes.length - 1) {
>>> buffer.append(", ");
>>> }
>>> }
>>> }
>>> buffer.append(")");
>>> String msg = "Error occurred while ensuring path is not null
>>> for"
>>> + " class : " + object.getClass() + ", method : "
>>> + foundMethod.getName() + buffer.toString() + " and return
>>> type : "
>>> + foundMethod.getReturnType();
>>> throw new RuntimeException(msg, e);
>>> }
>>> }
>>>
>>>
>>>
>>>
>>> Alvin Townsend wrote:
>>>>
>>>> Hi Bob,
>>>>
>>>> That largely is the behavior I observe everywhere else in the
>>>> application. For reasons unknown, just in this one place, we get this
>>>> error. (Even odder is that I cannot replicate the error in my IDE,
>>>> (Ganymede) only when packaged and deployed to Tomcat.)
>>>>
>>>> Thank you much for the help!
>>>>
>>>> Alvin
>>>>
>>>> On Sun, Oct 19, 2008 at 3:42 PM, Bob Schellink <sa...@gmail.com> wrote:
>>>>
>>>>>
>>>>> Alvin Townsend wrote:
>>>>>
>>>>>>
>>>>>> Hi Bob,
>>>>>>
>>>>>> That makes a lot of sense. Many of our objects cannot be instantiated
>>>>>> without arguments to the Constructors, so I've made sure that all of
>>>>>> them were set up previously and that the Form.copyTo wouldn't come
>>>>>> across anything null.
>>>>>>
>>>>>>
>>>>>
>>>>> Here is some more info. Click calls the getter method of the path to
>>>>> figure
>>>>> out whether to instantiate
>>>>> a new instance or not.
>>>>>
>>>>> field = new TextField("address.street");
>>>>> form.copyTo(client);
>>>>>
>>>>> From the above Click will tokenize the field path into "address" and
>>>>> "street". Next it will try and check if
>>>>> address is null through reflection by invoking the address getter:
>>>>>
>>>>> client.getAddress();
>>>>>
>>>>> If client.getAddress returns null Click tries and instantiates the
>>>>> Address.
>>>>>
>>>>> If you use a debugger you can place a breakpoint roughly on line 595 of
>>>>> class net.sf.click.util.ContainerUtils#ensureObjectPathNotNull.
>>>>> If your breakpoint is hit, it means Click tries to instantiate a
>>>>> object...
>>>>>
>>>>> kind regards
>>>>>
>>>>> bob
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
Re: "Wrong Number of Arguments" Error in Form.copyTo()
Posted by Alvin Townsend <al...@gmail.com>.
Bob,
I will download and test and let you know the results.
Thank you much.
Alvin
On Mon, Oct 20, 2008 at 12:40 PM, Bob Schellink <sa...@gmail.com> wrote:
> Hi Alvin,
>
> I've checked in some code today which might resolve your issue.
>
> If you have multiple overloaded getters (e.g. getters with same name but
> different args) in your class, it seems that Click might pick the wrong
> getter which accepts arguments. This could lead to the error you experience.
>
> You can test this by replacing your copy of net.sf.click.util.ContainerUtils
> with this one:
> http://click.svn.sourceforge.net/viewvc/click/trunk/click/framework/src/net/sf/click/util/ContainerUtils.java?revision=3540
>
> Let us know if that resolves the issue.
>
> Thanks.
>
> bob
>
> Bob Schellink wrote:
>>
>> Hmm nasty. Are you using JDK 1.4 or 1.5?
>>
>> Perhaps you have a getter which accepts an argument? That would certainly
>> throw IllegalArgumentException too.
>>
>> Anyway I think we need to improve the exception handling a bit to provide
>> more information for debugging.
>>
>> Below is my proposed change to ContainerUtils#ensureObjectPathNotNull.
>>
>> If you can replace the method with the one below it should provide better
>> info on which method with what parameter
>> is giving problems.
>>
>> Let me know if this shed some light on the issue.
>>
>>
>> private static void ensureObjectPathNotNull(Object object, String path) {
>>
>> final int index = path.indexOf('.');
>>
>> if (index == -1) {
>> return;
>> }
>>
>> String value = path.substring(0, index);
>> String getterName = ClickUtils.toGetterName(value);
>> String isGetterName = ClickUtils.toIsGetterName(value);
>>
>> Method foundMethod = null;
>> Method[] methods = object.getClass().getMethods();
>> for (int i = 0; i < methods.length; i++) {
>> String name = methods[i].getName();
>> if (name.equals(getterName)) {
>> foundMethod = methods[i];
>> break;
>>
>> } else if (name.equals(isGetterName)) {
>> foundMethod = methods[i];
>> break;
>> }
>> }
>>
>> if (foundMethod == null) {
>> String msg =
>> "Getter method not found on class : " + object.getClass()
>> + " for path value : " + value;
>> throw new RuntimeException(msg);
>> }
>>
>> try {
>> Object result = foundMethod.invoke(object, new Object[0]);
>>
>> if (result == null) {
>> result = foundMethod.getReturnType().newInstance();
>>
>> String setterName = ClickUtils.toSetterName(value);
>> Class[] classArgs = { foundMethod.getReturnType() };
>>
>> Method setterMethod =
>> object.getClass().getMethod(setterName, classArgs);
>>
>> Object[] objectArgs = { result };
>>
>> setterMethod.invoke(object, objectArgs);
>> }
>>
>> String remainingPath = path.substring(index + 1);
>>
>> ensureObjectPathNotNull(result, remainingPath);
>>
>> } catch (Exception e) {
>> HtmlStringBuffer buffer = new HtmlStringBuffer();
>> Class[] parameterTypes = foundMethod.getParameterTypes();
>> buffer.append("(");
>> if (parameterTypes != null) {
>> for (int i = 0; i < parameterTypes.length; i++) {
>> buffer.append(parameterTypes[i].getName());
>> if (i < parameterTypes.length - 1) {
>> buffer.append(", ");
>> }
>> }
>> }
>> buffer.append(")");
>> String msg = "Error occurred while ensuring path is not null
>> for"
>> + " class : " + object.getClass() + ", method : "
>> + foundMethod.getName() + buffer.toString() + " and return
>> type : "
>> + foundMethod.getReturnType();
>> throw new RuntimeException(msg, e);
>> }
>> }
>>
>>
>>
>>
>> Alvin Townsend wrote:
>>>
>>> Hi Bob,
>>>
>>> That largely is the behavior I observe everywhere else in the
>>> application. For reasons unknown, just in this one place, we get this
>>> error. (Even odder is that I cannot replicate the error in my IDE,
>>> (Ganymede) only when packaged and deployed to Tomcat.)
>>>
>>> Thank you much for the help!
>>>
>>> Alvin
>>>
>>> On Sun, Oct 19, 2008 at 3:42 PM, Bob Schellink <sa...@gmail.com> wrote:
>>>
>>>>
>>>> Alvin Townsend wrote:
>>>>
>>>>>
>>>>> Hi Bob,
>>>>>
>>>>> That makes a lot of sense. Many of our objects cannot be instantiated
>>>>> without arguments to the Constructors, so I've made sure that all of
>>>>> them were set up previously and that the Form.copyTo wouldn't come
>>>>> across anything null.
>>>>>
>>>>>
>>>>
>>>> Here is some more info. Click calls the getter method of the path to
>>>> figure
>>>> out whether to instantiate
>>>> a new instance or not.
>>>>
>>>> field = new TextField("address.street");
>>>> form.copyTo(client);
>>>>
>>>> From the above Click will tokenize the field path into "address" and
>>>> "street". Next it will try and check if
>>>> address is null through reflection by invoking the address getter:
>>>>
>>>> client.getAddress();
>>>>
>>>> If client.getAddress returns null Click tries and instantiates the
>>>> Address.
>>>>
>>>> If you use a debugger you can place a breakpoint roughly on line 595 of
>>>> class net.sf.click.util.ContainerUtils#ensureObjectPathNotNull.
>>>> If your breakpoint is hit, it means Click tries to instantiate a
>>>> object...
>>>>
>>>> kind regards
>>>>
>>>> bob
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: "Wrong Number of Arguments" Error in Form.copyTo()
Posted by Bob Schellink <sa...@gmail.com>.
Hi Alvin,
I've checked in some code today which might resolve your issue.
If you have multiple overloaded getters (e.g. getters with same name
but different args) in your class, it seems that Click might pick the
wrong getter which accepts arguments. This could lead to the error you
experience.
You can test this by replacing your copy of
net.sf.click.util.ContainerUtils with this one:
http://click.svn.sourceforge.net/viewvc/click/trunk/click/framework/src/net/sf/click/util/ContainerUtils.java?revision=3540
Let us know if that resolves the issue.
Thanks.
bob
Bob Schellink wrote:
> Hmm nasty. Are you using JDK 1.4 or 1.5?
>
> Perhaps you have a getter which accepts an argument? That would
> certainly throw IllegalArgumentException too.
>
> Anyway I think we need to improve the exception handling a bit to
> provide more information for debugging.
>
> Below is my proposed change to ContainerUtils#ensureObjectPathNotNull.
>
> If you can replace the method with the one below it should provide
> better info on which method with what parameter
> is giving problems.
>
> Let me know if this shed some light on the issue.
>
>
> private static void ensureObjectPathNotNull(Object object, String path) {
>
> final int index = path.indexOf('.');
>
> if (index == -1) {
> return;
> }
>
> String value = path.substring(0, index);
> String getterName = ClickUtils.toGetterName(value);
> String isGetterName = ClickUtils.toIsGetterName(value);
>
> Method foundMethod = null;
> Method[] methods = object.getClass().getMethods();
> for (int i = 0; i < methods.length; i++) {
> String name = methods[i].getName();
> if (name.equals(getterName)) {
> foundMethod = methods[i];
> break;
>
> } else if (name.equals(isGetterName)) {
> foundMethod = methods[i];
> break;
> }
> }
>
> if (foundMethod == null) {
> String msg =
> "Getter method not found on class : " + object.getClass()
> + " for path value : " + value;
> throw new RuntimeException(msg);
> }
>
> try {
> Object result = foundMethod.invoke(object, new Object[0]);
>
> if (result == null) {
> result = foundMethod.getReturnType().newInstance();
>
> String setterName = ClickUtils.toSetterName(value);
> Class[] classArgs = { foundMethod.getReturnType() };
>
> Method setterMethod =
> object.getClass().getMethod(setterName, classArgs);
>
> Object[] objectArgs = { result };
>
> setterMethod.invoke(object, objectArgs);
> }
>
> String remainingPath = path.substring(index + 1);
>
> ensureObjectPathNotNull(result, remainingPath);
>
> } catch (Exception e) {
> HtmlStringBuffer buffer = new HtmlStringBuffer();
> Class[] parameterTypes = foundMethod.getParameterTypes();
> buffer.append("(");
> if (parameterTypes != null) {
> for (int i = 0; i < parameterTypes.length; i++) {
> buffer.append(parameterTypes[i].getName());
> if (i < parameterTypes.length - 1) {
> buffer.append(", ");
> }
> }
> }
> buffer.append(")");
> String msg = "Error occurred while ensuring path is not null
> for"
> + " class : " + object.getClass() + ", method : "
> + foundMethod.getName() + buffer.toString() + " and
> return type : "
> + foundMethod.getReturnType();
> throw new RuntimeException(msg, e);
> }
> }
>
>
>
>
> Alvin Townsend wrote:
>> Hi Bob,
>>
>> That largely is the behavior I observe everywhere else in the
>> application. For reasons unknown, just in this one place, we get this
>> error. (Even odder is that I cannot replicate the error in my IDE,
>> (Ganymede) only when packaged and deployed to Tomcat.)
>>
>> Thank you much for the help!
>>
>> Alvin
>>
>> On Sun, Oct 19, 2008 at 3:42 PM, Bob Schellink <sa...@gmail.com> wrote:
>>
>>> Alvin Townsend wrote:
>>>
>>>> Hi Bob,
>>>>
>>>> That makes a lot of sense. Many of our objects cannot be instantiated
>>>> without arguments to the Constructors, so I've made sure that all of
>>>> them were set up previously and that the Form.copyTo wouldn't come
>>>> across anything null.
>>>>
>>>>
>>> Here is some more info. Click calls the getter method of the path to
>>> figure
>>> out whether to instantiate
>>> a new instance or not.
>>>
>>> field = new TextField("address.street");
>>> form.copyTo(client);
>>>
>>> From the above Click will tokenize the field path into "address" and
>>> "street". Next it will try and check if
>>> address is null through reflection by invoking the address getter:
>>>
>>> client.getAddress();
>>>
>>> If client.getAddress returns null Click tries and instantiates the
>>> Address.
>>>
>>> If you use a debugger you can place a breakpoint roughly on line 595 of
>>> class net.sf.click.util.ContainerUtils#ensureObjectPathNotNull.
>>> If your breakpoint is hit, it means Click tries to instantiate a
>>> object...
>>>
>>> kind regards
>>>
>>> bob
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
Re: "Wrong Number of Arguments" Error in Form.copyTo()
Posted by Bob Schellink <sa...@gmail.com>.
Hmm nasty. Are you using JDK 1.4 or 1.5?
Perhaps you have a getter which accepts an argument? That would
certainly throw IllegalArgumentException too.
Anyway I think we need to improve the exception handling a bit to
provide more information for debugging.
Below is my proposed change to ContainerUtils#ensureObjectPathNotNull.
If you can replace the method with the one below it should provide
better info on which method with what parameter
is giving problems.
Let me know if this shed some light on the issue.
private static void ensureObjectPathNotNull(Object object, String path) {
final int index = path.indexOf('.');
if (index == -1) {
return;
}
String value = path.substring(0, index);
String getterName = ClickUtils.toGetterName(value);
String isGetterName = ClickUtils.toIsGetterName(value);
Method foundMethod = null;
Method[] methods = object.getClass().getMethods();
for (int i = 0; i < methods.length; i++) {
String name = methods[i].getName();
if (name.equals(getterName)) {
foundMethod = methods[i];
break;
} else if (name.equals(isGetterName)) {
foundMethod = methods[i];
break;
}
}
if (foundMethod == null) {
String msg =
"Getter method not found on class : " + object.getClass()
+ " for path value : " + value;
throw new RuntimeException(msg);
}
try {
Object result = foundMethod.invoke(object, new Object[0]);
if (result == null) {
result = foundMethod.getReturnType().newInstance();
String setterName = ClickUtils.toSetterName(value);
Class[] classArgs = { foundMethod.getReturnType() };
Method setterMethod =
object.getClass().getMethod(setterName, classArgs);
Object[] objectArgs = { result };
setterMethod.invoke(object, objectArgs);
}
String remainingPath = path.substring(index + 1);
ensureObjectPathNotNull(result, remainingPath);
} catch (Exception e) {
HtmlStringBuffer buffer = new HtmlStringBuffer();
Class[] parameterTypes = foundMethod.getParameterTypes();
buffer.append("(");
if (parameterTypes != null) {
for (int i = 0; i < parameterTypes.length; i++) {
buffer.append(parameterTypes[i].getName());
if (i < parameterTypes.length - 1) {
buffer.append(", ");
}
}
}
buffer.append(")");
String msg = "Error occurred while ensuring path is not null
for"
+ " class : " + object.getClass() + ", method : "
+ foundMethod.getName() + buffer.toString() + " and
return type : "
+ foundMethod.getReturnType();
throw new RuntimeException(msg, e);
}
}
Alvin Townsend wrote:
> Hi Bob,
>
> That largely is the behavior I observe everywhere else in the
> application. For reasons unknown, just in this one place, we get this
> error. (Even odder is that I cannot replicate the error in my IDE,
> (Ganymede) only when packaged and deployed to Tomcat.)
>
> Thank you much for the help!
>
> Alvin
>
> On Sun, Oct 19, 2008 at 3:42 PM, Bob Schellink <sa...@gmail.com> wrote:
>
>> Alvin Townsend wrote:
>>
>>> Hi Bob,
>>>
>>> That makes a lot of sense. Many of our objects cannot be instantiated
>>> without arguments to the Constructors, so I've made sure that all of
>>> them were set up previously and that the Form.copyTo wouldn't come
>>> across anything null.
>>>
>>>
>> Here is some more info. Click calls the getter method of the path to figure
>> out whether to instantiate
>> a new instance or not.
>>
>> field = new TextField("address.street");
>> form.copyTo(client);
>>
>> From the above Click will tokenize the field path into "address" and
>> "street". Next it will try and check if
>> address is null through reflection by invoking the address getter:
>>
>> client.getAddress();
>>
>> If client.getAddress returns null Click tries and instantiates the Address.
>>
>> If you use a debugger you can place a breakpoint roughly on line 595 of
>> class net.sf.click.util.ContainerUtils#ensureObjectPathNotNull.
>> If your breakpoint is hit, it means Click tries to instantiate a object...
>>
>> kind regards
>>
>> bob
>>
>>
>>
>>
>>
>
>
Re: "Wrong Number of Arguments" Error in Form.copyTo()
Posted by Alvin Townsend <al...@gmail.com>.
Hi Bob,
That largely is the behavior I observe everywhere else in the
application. For reasons unknown, just in this one place, we get this
error. (Even odder is that I cannot replicate the error in my IDE,
(Ganymede) only when packaged and deployed to Tomcat.)
Thank you much for the help!
Alvin
On Sun, Oct 19, 2008 at 3:42 PM, Bob Schellink <sa...@gmail.com> wrote:
> Alvin Townsend wrote:
>>
>> Hi Bob,
>>
>> That makes a lot of sense. Many of our objects cannot be instantiated
>> without arguments to the Constructors, so I've made sure that all of
>> them were set up previously and that the Form.copyTo wouldn't come
>> across anything null.
>>
>
> Here is some more info. Click calls the getter method of the path to figure
> out whether to instantiate
> a new instance or not.
>
> field = new TextField("address.street");
> form.copyTo(client);
>
> From the above Click will tokenize the field path into "address" and
> "street". Next it will try and check if
> address is null through reflection by invoking the address getter:
>
> client.getAddress();
>
> If client.getAddress returns null Click tries and instantiates the Address.
>
> If you use a debugger you can place a breakpoint roughly on line 595 of
> class net.sf.click.util.ContainerUtils#ensureObjectPathNotNull.
> If your breakpoint is hit, it means Click tries to instantiate a object...
>
> kind regards
>
> bob
>
>
>
>
Re: "Wrong Number of Arguments" Error in Form.copyTo()
Posted by Bob Schellink <sa...@gmail.com>.
Alvin Townsend wrote:
> Hi Bob,
>
> That makes a lot of sense. Many of our objects cannot be instantiated
> without arguments to the Constructors, so I've made sure that all of
> them were set up previously and that the Form.copyTo wouldn't come
> across anything null.
>
Here is some more info. Click calls the getter method of the path to
figure out whether to instantiate
a new instance or not.
field = new TextField("address.street");
form.copyTo(client);
From the above Click will tokenize the field path into "address" and
"street". Next it will try and check if
address is null through reflection by invoking the address getter:
client.getAddress();
If client.getAddress returns null Click tries and instantiates the Address.
If you use a debugger you can place a breakpoint roughly on line 595 of
class net.sf.click.util.ContainerUtils#ensureObjectPathNotNull.
If your breakpoint is hit, it means Click tries to instantiate a object...
kind regards
bob
Re: "Wrong Number of Arguments" Error in Form.copyTo()
Posted by Alvin Townsend <al...@gmail.com>.
Hi Bob,
That makes a lot of sense. Many of our objects cannot be instantiated
without arguments to the Constructors, so I've made sure that all of
them were set up previously and that the Form.copyTo wouldn't come
across anything null.
Form.copyTo() should only be coming across simple single-argument
setters. The object graph (past the Constructors) is very
straightforward. For the life of me I cannot see what's choking
Form.copyTo()...
If I come up with something brilliant, I'll let you know. :-)
Thanks again!
Alvin
On Sun, Oct 19, 2008 at 2:58 PM, Bob Schellink <sa...@gmail.com> wrote:
> Hi Alvin,
>
> Alvin Townsend wrote:
>>
>> java.lang.IllegalArgumentException: wrong number of arguments
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:585)
>> at
>> net.sf.click.util.ContainerUtils.ensureObjectPathNotNull(ContainerUtils.java:592)
>> at
>> net.sf.click.util.ContainerUtils.copyContainerToObject(ContainerUtils.java:318)
>> at
>> net.sf.click.util.ContainerUtils.copyContainerToObject(ContainerUtils.java:355)
>> at net.sf.click.control.Form.copyTo(Form.java:1710)
>>
>
> This normally happens when an object is instantiated which does not have a
> default empty constructor.
> When you specify a path for your field e.g. new TextField("address.price"),
> Form.copyTo will navigate the
> object graph according to the path. Say you have the following:
>
> field = new TextField("address.price")
> ...
> form.copyTo(client);
>
> the copy logic will try and navigate to the Address from Client. But if
> Address is null on Client Click
> attempts to create a new Address. But the only way this works is if Address
> has a default no arg constructor:
>
> public class Address {
> public Address() {}
> }
>
> If your Address cannot have a no-arg constructor the best way to resolve
> this is to ensure your domain
> objects are valid before invoking form.copyTo(). You could do this by
> overriding Form.copyTo:
>
> public void onInit() {
> ...
> form.copyTo(client) {
> if (client.getAddress() == null) {
> client.setAddress(createAddress());
> }
> super.copyTo(client);
> };
> }
>
> Does this help?
>
> kind regards
>
> bob
>
>
Re: "Wrong Number of Arguments" Error in Form.copyTo()
Posted by Bob Schellink <sa...@gmail.com>.
Hi Alvin,
Alvin Townsend wrote:
> java.lang.IllegalArgumentException: wrong number of arguments
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at net.sf.click.util.ContainerUtils.ensureObjectPathNotNull(ContainerUtils.java:592)
> at net.sf.click.util.ContainerUtils.copyContainerToObject(ContainerUtils.java:318)
> at net.sf.click.util.ContainerUtils.copyContainerToObject(ContainerUtils.java:355)
> at net.sf.click.control.Form.copyTo(Form.java:1710)
>
This normally happens when an object is instantiated which does not have
a default empty constructor.
When you specify a path for your field e.g. new
TextField("address.price"), Form.copyTo will navigate the
object graph according to the path. Say you have the following:
field = new TextField("address.price")
...
form.copyTo(client);
the copy logic will try and navigate to the Address from Client. But if
Address is null on Client Click
attempts to create a new Address. But the only way this works is if
Address has a default no arg constructor:
public class Address {
public Address() {}
}
If your Address cannot have a no-arg constructor the best way to resolve
this is to ensure your domain
objects are valid before invoking form.copyTo(). You could do this by
overriding Form.copyTo:
public void onInit() {
...
form.copyTo(client) {
if (client.getAddress() == null) {
client.setAddress(createAddress());
}
super.copyTo(client);
};
}
Does this help?
kind regards
bob