You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Paul Nicolucci <pn...@us.ibm.com> on 2011/12/21 19:05:23 UTC
[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 org.apache.el.parser.AstValue.getValue(AstValue.java:159)
at org.apache.el.ValueExpressionImpl.getValue
(ValueExpressionImpl.java:283)
at
org.apache.myfaces.view.facelets.el.TagValueExpression.getValue
(TagValueExpression.java:85)
at javax.faces.component._DeltaStateHelper.eval
(_DeltaStateHelper.java:243)
at javax.faces.component.UIOutput.getValue(UIOutput.java:71)
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.getValue
(RendererUtils.java:343)
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.getStringValue
(RendererUtils.java:295)
at
org.apache.myfaces.shared_impl.renderkit.html.HtmlTextRendererBase.renderOutput
(HtmlTextRendererBase.java:92)
at
org.apache.myfaces.shared_impl.renderkit.html.HtmlTextRendererBase.encodeEnd
(HtmlTextRendererBase.java:79)
at javax.faces.component.UIComponentBase.encodeEnd
(UIComponentBase.java:519)
at javax.faces.component.UIComponent.encodeAll
(UIComponent.java:626)
at javax.faces.component.UIComponent.encodeAll
(UIComponent.java:622)
at javax.faces.component.UIComponent.encodeAll
(UIComponent.java:622)
at javax.faces.component.UIComponent.encodeAll
(UIComponent.java:622)
at
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView
(FaceletViewDeclarationLanguage.java:1320)
at org.apache.myfaces.application.ViewHandlerImpl.renderView
(ViewHandlerImpl.java:263)
at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute
(RenderResponseExecutor.java:85)
at org.apache.myfaces.lifecycle.LifecycleImpl.render
(LifecycleImpl.java:239)
... 22 more
Since the MapELResolver.java in the EL Implementation always returns
"Object.class" from getType() and the parameters are stored in the
RequestParameterMap we are now looking for a method signature using Object
instead of the expected type String. This worked before the change in the
above mentioned bug, we had the same JSF application and we were calling
the correct method signature method(String param1, String param2), because
before the change, the MapELResolver.getType( ) would return the type of a
the value in the Map rather than Object.class
Has an issue already been opened for this? Suggestions on how to go about
fixing this? I've attached a simpleJSF test case that reproduces ->
Navigate to the ELMethodExpression.jsf page and then press the link -> the
exception appears. I've debugged through the EL
code and It looks as though the type of the parameters comes from the
MapELResolver (will always return Object.class), so that then when we reach
"javax.el.BeanELResolver.invoke()" we can't find the method due to the fact
we are looking for method(Object param1, Object param2), rather than method
(String param1, String param2).
Thanks for the help!
Regards,
Paul Nicolucci
Re: [Discussion]Problem passing parameters to a Method ( Looking for
incorrect argument Type )
Posted by Paul Nicolucci <pn...@us.ibm.com>.
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
<us...@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"
<users@tomcat.apa
che.org>
2011/12/22 Paul Nicolucci <pn...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [Discussion]Problem passing parameters to a Method ( Looking for
incorrect argument Type )
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/12/22 Paul Nicolucci <pn...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [Discussion]Problem passing parameters to a Method ( Looking for
incorrect argument Type )
Posted by Paul Nicolucci <pn...@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 ?
Thanks again! My apologies for cross posting I just wanted to reach as
broad of an audience as possible.
Respectfully,
Paul Nicolucci
Pid
<pi...@pidster.com>
To
12/21/2011 02:00 Tomcat Users List
PM <us...@tomcat.apache.org>
cc
Please respond to Subject
"Tomcat Users Re: [Discussion]Problem passing
List" parameters to a Method ( Looking
<users@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)
> 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 org.apache.el.parser.AstValue.getValue
(AstValue.java:159)
> at org.apache.el.ValueExpressionImpl.getValue
> (ValueExpressionImpl.java:283)
> at
> org.apache.myfaces.view.facelets.el.TagValueExpression.getValue
> (TagValueExpression.java:85)
> at javax.faces.component._DeltaStateHelper.eval
> (_DeltaStateHelper.java:243)
> at javax.faces.component.UIOutput.getValue
(UIOutput.java:71)
> at
> org.apache.myfaces.shared_impl.renderkit.RendererUtils.getValue
> (RendererUtils.java:343)
> at
> org.apache.myfaces.shared_impl.renderkit.RendererUtils.getStringValue
> (RendererUtils.java:295)
> at
>
org.apache.myfaces.shared_impl.renderkit.html.HtmlTextRendererBase.renderOutput
> (HtmlTextRendererBase.java:92)
> at
>
org.apache.myfaces.shared_impl.renderkit.html.HtmlTextRendererBase.encodeEnd
> (HtmlTextRendererBase.java:79)
> at
javax.faces.component.UIComponentBase.encodeEnd
> (UIComponentBase.java:519)
> at javax.faces.component.UIComponent.encodeAll
> (UIComponent.java:626)
> at javax.faces.component.UIComponent.encodeAll
> (UIComponent.java:622)
> at javax.faces.component.UIComponent.encodeAll
> (UIComponent.java:622)
> at javax.faces.component.UIComponent.encodeAll
> (UIComponent.java:622)
> at
>
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView
> (FaceletViewDeclarationLanguage.java:1320)
> at
org.apache.myfaces.application.ViewHandlerImpl.renderView
> (ViewHandlerImpl.java:263)
> at
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute
> (RenderResponseExecutor.java:85)
> at
org.apache.myfaces.lifecycle.LifecycleImpl.render
> (LifecycleImpl.java:239)
> ... 22 more
>
>
> Since the MapELResolver.java in the EL Implementation always returns
> "Object.class" from getType() and the parameters are stored in the
> RequestParameterMap we are now looking for a method signature using
Object
> instead of the expected type String. This worked before the change in the
> above mentioned bug, we had the same JSF application and we were calling
> the correct method signature method(String param1, String param2),
because
> before the change, the MapELResolver.getType( ) would return the type of
a
> the value in the Map rather than Object.class
>
> Has an issue already been opened for this? Suggestions on how to go
about
> fixing this? I've attached a simpleJSF test case that reproduces ->
> Navigate to the ELMethodExpression.jsf page and then press the link ->
the
> exception appears. I've debugged through the EL
> code and It looks as though the type of the parameters comes from the
> MapELResolver (will always return Object.class), so that then when we
reach
> "javax.el.BeanELResolver.invoke()" we can't find the method due to the
fact
> we are looking for method(Object param1, Object param2), rather than
method
> (String param1, String param2).
>
> Thanks for the help!
>
> Regards,
>
> Paul Nicolucci
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
--
[key:62590808]
(See attached file: signature.asc)
Re: [Discussion]Problem passing parameters to a Method ( Looking
for incorrect argument Type )
Posted by Pid <pi...@pidster.com>.
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:
> 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 org.apache.el.parser.AstValue.getValue(AstValue.java:159)
> at org.apache.el.ValueExpressionImpl.getValue
> (ValueExpressionImpl.java:283)
> at
> org.apache.myfaces.view.facelets.el.TagValueExpression.getValue
> (TagValueExpression.java:85)
> at javax.faces.component._DeltaStateHelper.eval
> (_DeltaStateHelper.java:243)
> at javax.faces.component.UIOutput.getValue(UIOutput.java:71)
> at
> org.apache.myfaces.shared_impl.renderkit.RendererUtils.getValue
> (RendererUtils.java:343)
> at
> org.apache.myfaces.shared_impl.renderkit.RendererUtils.getStringValue
> (RendererUtils.java:295)
> at
> org.apache.myfaces.shared_impl.renderkit.html.HtmlTextRendererBase.renderOutput
> (HtmlTextRendererBase.java:92)
> at
> org.apache.myfaces.shared_impl.renderkit.html.HtmlTextRendererBase.encodeEnd
> (HtmlTextRendererBase.java:79)
> at javax.faces.component.UIComponentBase.encodeEnd
> (UIComponentBase.java:519)
> at javax.faces.component.UIComponent.encodeAll
> (UIComponent.java:626)
> at javax.faces.component.UIComponent.encodeAll
> (UIComponent.java:622)
> at javax.faces.component.UIComponent.encodeAll
> (UIComponent.java:622)
> at javax.faces.component.UIComponent.encodeAll
> (UIComponent.java:622)
> at
> org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView
> (FaceletViewDeclarationLanguage.java:1320)
> at org.apache.myfaces.application.ViewHandlerImpl.renderView
> (ViewHandlerImpl.java:263)
> at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute
> (RenderResponseExecutor.java:85)
> at org.apache.myfaces.lifecycle.LifecycleImpl.render
> (LifecycleImpl.java:239)
> ... 22 more
>
>
> Since the MapELResolver.java in the EL Implementation always returns
> "Object.class" from getType() and the parameters are stored in the
> RequestParameterMap we are now looking for a method signature using Object
> instead of the expected type String. This worked before the change in the
> above mentioned bug, we had the same JSF application and we were calling
> the correct method signature method(String param1, String param2), because
> before the change, the MapELResolver.getType( ) would return the type of a
> the value in the Map rather than Object.class
>
> Has an issue already been opened for this? Suggestions on how to go about
> fixing this? I've attached a simpleJSF test case that reproduces ->
> Navigate to the ELMethodExpression.jsf page and then press the link -> the
> exception appears. I've debugged through the EL
> code and It looks as though the type of the parameters comes from the
> MapELResolver (will always return Object.class), so that then when we reach
> "javax.el.BeanELResolver.invoke()" we can't find the method due to the fact
> we are looking for method(Object param1, Object param2), rather than method
> (String param1, String param2).
>
> Thanks for the help!
>
> Regards,
>
> Paul Nicolucci
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
--
[key:62590808]