Re: [Discussion]Problem passing parameters to a Method ( Looking for incorrect argument Type )
Thanks for your input! I've actually figured out what I was missing. I had to also pull in the following fix: https://issues.apache.org/bugzilla/show_bug.cgi?id=50790 With the above fix everything works as it does on Tomcat 7.0.23 ( I was able to successfully execute my test on Tomcat). Regards, Paul Nicolucci Konstantin Kolinko knst.kolinko@gma To il.com Tomcat Users List users@tomcat.apache.org 12/22/2011 12:16 cc AM Subject Re: [Discussion]Problem passing Please respond to parameters to a Method ( Looking Tomcat Users for incorrect argument Type ) List us...@tomcat.apa che.org 2011/12/22 Paul Nicolucci pnico...@us.ibm.com: Thanks for the response, I'll try to clarify as best I can and can provide a test case directly if needed ( since the mailing list strips attachments, sorry about that I was unaware ). -We are experiencing this problem on Websphere Application Server V8 which included a snap shot of the org.apache.el code. - This problem only seems to happen after we pulled in the following fix for org.apache.el code : https://issues.apache.org/bugzilla/show_bug.cgi?id=51177 - It seems that if we try to pass a parameter using JSF to a method using the EL when using a value stored in a Map then we always look for a method signature having Object type parameters since the MapELResolver.getType() always returns Object.class now. What further information can I provide? Should I open a JIRA issue with more details and attach a test case there ? 1. If you can provide a simple sample application that demonstrates the issue on a clean installation of Tomcat 7.0.23, then please open an issue in Bugzilla and attach it there. (So that we can fix it and a test to our testsuite). http://tomcat.apache.org/bugreport.html 2. Regarding BZ 51177 fix as far as I remember (without looking at commit logs), the old code was looking up the actual type of element contained in the map or in the list, which is just plainly wrong. There is specification fragment cited in https://issues.apache.org/bugzilla/show_bug.cgi?id=51177#c0 Regarding your use case where target class contains no foo(Object) method, from pure logic I would expect foo(String) to be found (if it is the only candidate) and then a classcast to be attempted, but I would like to see some quote from specification (from PDFs or from Javadoc) to support that. A close match is from page #34 (48 of 130) of expression_language-2_2-mrel-spec.pdf regarding BeanELResolver [quote] For method resolution, the method string is the name of the method in the bean. The parameter types can be optionally specified to identify the method. If the parameter types are not specified, the parameter objects are used in the method resolution. [/quote] and page #38 (52 of 130) [quote] The provided method object will first be coerced to a String. The methods in the bean is then examined and an attempt will be made to select one for invocation. If no suitable can be found, a MethodNotFoundException is thrown. If the given paramTypes is not null, select the method with the given name and parameter types. Else select the method with the given name that has the same number of parameters. If there are more than one such method, the method selection process is undefined. (...) [/quote] So the method name and the count of parameters is what matters. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[Discussion]Problem passing parameters to a Method ( Looking for incorrect argument Type )
I'm just following up on this issue as I did not see any responses from the community. Can anyone help out here? (See attached file: JSF20EL.war) Instructions for reproducing this issue are in the previous email attached below. Thanks for your time and help, Regards, Paul Nicolucci __ Hello All, After The following update to the EL: https://issues.apache.org/bugzilla/show_bug.cgi?id=51177 I am having a problem when getting values from the RequestParameterMap and sending them to a method using the EL. For example: Page1 - use f:param to set some query string parameters: h:form id=form1 prependId=false h:outputScript name=jsf.js library=javax.faces target=head / h:commandButton id=button1 value=AddMessage action=#{elOperator.addFacesMessage}/ br/ br/ h:link id=link1 outcome=ELMethodExpression2 value=Link with Parameters f:param name=param1 value=param1/ f:param name=param2 value=param2/ /h:link h:messages/ /h:form Navigates to Page2: Page2 - access param1,param2 from param (RequestParameterMap) and send them to a bean method as arguments: h:form id=form1 prependId=false h:outputScript name=jsf.js library=javax.faces target=head / !-- Test method expressions while passing parameters -- h:outputText id=out1 value=#{elOperator.generateStringWithParameters (param.param1,param.param2)}/ /h:form Bean Method: public String generateStringWithParameters(String param1, String param2) { return (param1 + : + param2); } When we try to call elOperator.generateStringWithParameters (param.param1,param.param2) I'm getting the following exception: javax.faces.FacesException: java.lang.NoSuchMethodException: com.ibm.ws.jsf.beans.ELOperatorBean.generateStringWithParameters (java.lang.Object, java.lang.Object) at org.apache.myfaces.shared_impl.context.ExceptionHandlerImpl.wrap (ExceptionHandlerImpl.java:241) at org.apache.myfaces.shared_impl.context.ExceptionHandlerImpl.handle (ExceptionHandlerImpl.java:156) at org.apache.myfaces.lifecycle.LifecycleImpl.render (LifecycleImpl.java:258) at javax.faces.webapp.FacesServlet.service (FacesServlet.java:191) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service (ServletWrapper.java:1188) at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest (ServletWrapper.java:763) at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest (ServletWrapper.java:454) at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest (ServletWrapperImpl.java:178) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters (WebAppFilterManager.java:1020) at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest (CacheServletWrapper.java:87) at com.ibm.ws.webcontainer.WebContainer.handleRequest (WebContainer.java:895) at com.ibm.ws.webcontainer.WSWebContainer.handleRequest (WSWebContainer.java:1662) at com.ibm.ws.webcontainer.channel.WCChannelLink.ready (WCChannelLink.java:195) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination (HttpInboundLink.java:452) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest (HttpInboundLink.java:511) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest (HttpInboundLink.java:305) at com.ibm.ws.http.channel.inbound.impl.HttpICLReadCallback.complete (HttpICLReadCallback.java:83) at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted (AioReadCompletionListener.java:165) at com.ibm.io.async.AbstractAsyncFuture.invokeCallback (AbstractAsyncFuture.java:217) at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions (AsyncChannelFuture.java:161) at com.ibm.io.async.AsyncFuture.completed (AsyncFuture.java:138) at com.ibm.io.async.ResultHandler.complete (ResultHandler.java:204) at com.ibm.io.async.ResultHandler.runEventProcessingLoop (ResultHandler.java:775) at com.ibm.io.async.ResultHandler$2.run (ResultHandler.java:905) at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1659) Caused by: java.lang.NoSuchMethodException: com.ibm.ws.jsf.beans.ELOperatorBean.generateStringWithParameters (java.lang.Object, java.lang.Object) at java.lang.Class.throwNoSuchMethodException(Class.java:282) at java.lang.Class.getMethod(Class.java:853) at javax.el.BeanELResolver.invoke(BeanELResolver.java:406) at javax.el.CompositeELResolver.invoke (CompositeELResolver.java:137) at
Re: [Discussion]Problem passing parameters to a Method ( Looking for incorrect argument Type )
On 21/12/2011 18:05, Paul Nicolucci wrote: I'm just following up on this issue as I did not see any responses from the community. Can anyone help out here? Please don't cross post. (See attached file: JSF20EL.war) The list strips attachments. Instructions for reproducing this issue are in the previous email attached below. Thanks for your time and help, It's not in any way clear which version of the code in org.apache.el this might be attributed to as it appears that you're using something other than Tomcat and you don't provide any version numbers for anything else. p Regards, Paul Nicolucci __ Hello All, After The following update to the EL: https://issues.apache.org/bugzilla/show_bug.cgi?id=51177 I am having a problem when getting values from the RequestParameterMap and sending them to a method using the EL. For example: Page1 - use f:param to set some query string parameters: h:form id=form1 prependId=false h:outputScript name=jsf.js library=javax.faces target=head / h:commandButton id=button1 value=AddMessage action=#{elOperator.addFacesMessage}/ br/ br/ h:link id=link1 outcome=ELMethodExpression2 value=Link with Parameters f:param name=param1 value=param1/ f:param name=param2 value=param2/ /h:link h:messages/ /h:form Navigates to Page2: Page2 - access param1,param2 from param (RequestParameterMap) and send them to a bean method as arguments: h:form id=form1 prependId=false h:outputScript name=jsf.js library=javax.faces target=head / !-- Test method expressions while passing parameters -- h:outputText id=out1 value=#{elOperator.generateStringWithParameters (param.param1,param.param2)}/ /h:form Bean Method: public String generateStringWithParameters(String param1, String param2) { return (param1 + : + param2); } When we try to call elOperator.generateStringWithParameters (param.param1,param.param2) I'm getting the following exception: javax.faces.FacesException: java.lang.NoSuchMethodException: com.ibm.ws.jsf.beans.ELOperatorBean.generateStringWithParameters (java.lang.Object, java.lang.Object) at org.apache.myfaces.shared_impl.context.ExceptionHandlerImpl.wrap (ExceptionHandlerImpl.java:241) at org.apache.myfaces.shared_impl.context.ExceptionHandlerImpl.handle (ExceptionHandlerImpl.java:156) at org.apache.myfaces.lifecycle.LifecycleImpl.render (LifecycleImpl.java:258) at javax.faces.webapp.FacesServlet.service (FacesServlet.java:191) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service (ServletWrapper.java:1188) at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest (ServletWrapper.java:763) at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest (ServletWrapper.java:454) at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest (ServletWrapperImpl.java:178) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters (WebAppFilterManager.java:1020) at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest (CacheServletWrapper.java:87) at com.ibm.ws.webcontainer.WebContainer.handleRequest (WebContainer.java:895) at com.ibm.ws.webcontainer.WSWebContainer.handleRequest (WSWebContainer.java:1662) at com.ibm.ws.webcontainer.channel.WCChannelLink.ready (WCChannelLink.java:195) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination (HttpInboundLink.java:452) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest (HttpInboundLink.java:511) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest (HttpInboundLink.java:305) at com.ibm.ws.http.channel.inbound.impl.HttpICLReadCallback.complete (HttpICLReadCallback.java:83) at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted (AioReadCompletionListener.java:165) at com.ibm.io.async.AbstractAsyncFuture.invokeCallback (AbstractAsyncFuture.java:217) at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions (AsyncChannelFuture.java:161) at com.ibm.io.async.AsyncFuture.completed (AsyncFuture.java:138) at com.ibm.io.async.ResultHandler.complete (ResultHandler.java:204) at com.ibm.io.async.ResultHandler.runEventProcessingLoop (ResultHandler.java:775) at com.ibm.io.async.ResultHandler$2.run (ResultHandler.java:905) at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1659) Caused by: java.lang.NoSuchMethodException:
Re: [Discussion]Problem passing parameters to a Method ( Looking for incorrect argument Type )
Thanks for the response, I'll try to clarify as best I can and can provide a test case directly if needed ( since the mailing list strips attachments, sorry about that I was unaware ). -We are experiencing this problem on Websphere Application Server V8 which included a snap shot of the org.apache.el code. - This problem only seems to happen after we pulled in the following fix for org.apache.el code : https://issues.apache.org/bugzilla/show_bug.cgi?id=51177 - It seems that if we try to pass a parameter using JSF to a method using the EL when using a value stored in a Map then we always look for a method signature having Object type parameters since the MapELResolver.getType() always returns Object.class now. What further information can I provide? Should I open a JIRA issue with more details and attach a test case there ? Thanks again! My apologies for cross posting I just wanted to reach as broad of an audience as possible. Respectfully, Paul Nicolucci Pid p...@pidster.com To 12/21/2011 02:00 Tomcat Users List PMusers@tomcat.apache.org cc Please respond to Subject Tomcat Users Re: [Discussion]Problem passing List parameters to a Method ( Looking us...@tomcat.apa for incorrect argument Type ) che.org On 21/12/2011 18:05, Paul Nicolucci wrote: I'm just following up on this issue as I did not see any responses from the community. Can anyone help out here? Please don't cross post. (See attached file: JSF20EL.war) The list strips attachments. Instructions for reproducing this issue are in the previous email attached below. Thanks for your time and help, It's not in any way clear which version of the code in org.apache.el this might be attributed to as it appears that you're using something other than Tomcat and you don't provide any version numbers for anything else. p Regards, Paul Nicolucci __ Hello All, After The following update to the EL: https://issues.apache.org/bugzilla/show_bug.cgi?id=51177 I am having a problem when getting values from the RequestParameterMap and sending them to a method using the EL. For example: Page1 - use f:param to set some query string parameters: h:form id=form1 prependId=false h:outputScript name=jsf.js library=javax.faces target=head / h:commandButton id=button1 value=AddMessage action=#{elOperator.addFacesMessage}/ br/ br/ h:link id=link1 outcome=ELMethodExpression2 value=Link with Parameters f:param name=param1 value=param1/ f:param name=param2 value=param2/ /h:link h:messages/ /h:form Navigates to Page2: Page2 - access param1,param2 from param (RequestParameterMap) and send them to a bean method as arguments: h:form id=form1 prependId=false h:outputScript name=jsf.js library=javax.faces target=head / !-- Test method expressions while passing parameters -- h:outputText id=out1 value=#{elOperator.generateStringWithParameters (param.param1,param.param2)}/ /h:form Bean Method: public String generateStringWithParameters(String param1, String param2) { return (param1 + : + param2); } When we try to call elOperator.generateStringWithParameters (param.param1,param.param2) I'm getting the following exception: javax.faces.FacesException: java.lang.NoSuchMethodException: com.ibm.ws.jsf.beans.ELOperatorBean.generateStringWithParameters (java.lang.Object, java.lang.Object) at org.apache.myfaces.shared_impl.context.ExceptionHandlerImpl.wrap (ExceptionHandlerImpl.java:241) at org.apache.myfaces.shared_impl.context.ExceptionHandlerImpl.handle (ExceptionHandlerImpl.java:156) at org.apache.myfaces.lifecycle.LifecycleImpl.render (LifecycleImpl.java:258)
Re: [Discussion]Problem passing parameters to a Method ( Looking for incorrect argument Type )
2011/12/22 Paul Nicolucci pnico...@us.ibm.com: Thanks for the response, I'll try to clarify as best I can and can provide a test case directly if needed ( since the mailing list strips attachments, sorry about that I was unaware ). -We are experiencing this problem on Websphere Application Server V8 which included a snap shot of the org.apache.el code. - This problem only seems to happen after we pulled in the following fix for org.apache.el code : https://issues.apache.org/bugzilla/show_bug.cgi?id=51177 - It seems that if we try to pass a parameter using JSF to a method using the EL when using a value stored in a Map then we always look for a method signature having Object type parameters since the MapELResolver.getType() always returns Object.class now. What further information can I provide? Should I open a JIRA issue with more details and attach a test case there ? 1. If you can provide a simple sample application that demonstrates the issue on a clean installation of Tomcat 7.0.23, then please open an issue in Bugzilla and attach it there. (So that we can fix it and a test to our testsuite). http://tomcat.apache.org/bugreport.html 2. Regarding BZ 51177 fix as far as I remember (without looking at commit logs), the old code was looking up the actual type of element contained in the map or in the list, which is just plainly wrong. There is specification fragment cited in https://issues.apache.org/bugzilla/show_bug.cgi?id=51177#c0 Regarding your use case where target class contains no foo(Object) method, from pure logic I would expect foo(String) to be found (if it is the only candidate) and then a classcast to be attempted, but I would like to see some quote from specification (from PDFs or from Javadoc) to support that. A close match is from page #34 (48 of 130) of expression_language-2_2-mrel-spec.pdf regarding BeanELResolver [quote] For method resolution, the method string is the name of the method in the bean. The parameter types can be optionally specified to identify the method. If the parameter types are not specified, the parameter objects are used in the method resolution. [/quote] and page #38 (52 of 130) [quote] The provided method object will first be coerced to a String. The methods in the bean is then examined and an attempt will be made to select one for invocation. If no suitable can be found, a MethodNotFoundException is thrown. If the given paramTypes is not null, select the method with the given name and parameter types. Else select the method with the given name that has the same number of parameters. If there are more than one such method, the method selection process is undefined. (...) [/quote] So the method name and the count of parameters is what matters. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org