You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by John Wu <Jo...@gmail.com> on 2010/06/10 15:42:53 UTC
Re: EL 2.2 in Tomcat 7 RC1/RC2 does not fully support method
invocation, such as "#{helloWorldController.doSomething(helloWorldModel)}"
Hi Mark,
The fix of "to derive the type directly from the value which ..." sounds not
a solution. In a slightly more complex scenario, the fix still fails.
Say the method signature is "public * theMethod(TheSupperType o)" and
calling the method in EL like
"#{theClassInstance.theMethod(theDerivedTypeInstance)}", where the supper
type can be a supper class or an interface, your fix fails.
Example project attached.
My suggestion as to the solution of resolving which method to call:
. Retrieve all methods of *theClassInstance*, and put them into the
CANDIDATES collection;
// Search a match by method name
. For each method in CANDIDATES,
. if the name is not *theMethod*, remove it from CANDIDATES
. If CANDIDATES is empty, then NOT-FOUND;
. else if only one is left, then FOUND;
// Search a match by params count
. else, count the number of actual params,
. For each method in CANDIDATES,
. if the number of formal params does not match that of actual params,
remove it from CANDIDATES
. // Optoional, handle cases of "method has variable number of arguments"
. If CANDIDATES is empty, then NOT-FOUND;
. else if only one is left, then FOUND;
// Search a match by param types
. else, evaluate all actual params;
. For each method in CANDIDATES,
. if NOT( for-each formalParamType.isAssignableFrom(actualParamType) ),
remove it from CANDIDATES
. // Optoional, handle cases of "method has variable number of arguments"
. If CANDIDATES is empty, then NOT-FOUND;
. else if only one is left, then FOUND;
. else, AMBIGUOUS
John Wu
http://old.nabble.com/file/p28843317/jsf-2.0-el-2.2.testcase-v2.zip
jsf-2.0-el-2.2.testcase-v2.zip
--
View this message in context: http://old.nabble.com/EL-2.2-in-Tomcat-7-RC1-RC2-does-not-fully-support-method-invocation%2C-such-as-%22-%7BhelloWorldController.doSomething%28helloWorldModel%29%7D%22-tp28671969p28843317.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: EL 2.2 in Tomcat 7 RC1/RC2 does not fully support method invocation,
such as "#{helloWorldController.doSomething(helloWorldModel)}"
Posted by Mark Thomas <ma...@apache.org>.
On 30/06/2010 09:15, Mark Thomas wrote:
> On 29/06/2010 22:32, Mark Thomas wrote:
>> On 21/06/2010 15:16, John Wu wrote:
>>>
>>> Hi Mark,
>>>
>>> I just got a chance to test it on the Beta release. It's still broken,
>>> with
>>> a slightly different exception message.
>>
>> Confirmed. I'm pretty sure JSF is doing the right thing here and that I
>> need to read the spec more carefully. I'll post an update when I have a
>> fix.
>
> It looks like we are going to have to go with your original proposal. I
> was trying to avoid the complexity it adds but I can't see a way around it.
Done. The method identification code now works in a similar manner
(there are a few edge case differences) to how the Java compiler
identifies methods.
Will be in 7.0.1. No firm date for 7.0.1 but given the issues that are
being raised, my current thinking is to start the release process in a
couple of weeks or so.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: EL 2.2 in Tomcat 7 RC1/RC2 does not fully support method invocation,
such as "#{helloWorldController.doSomething(helloWorldModel)}"
Posted by Mark Thomas <ma...@apache.org>.
On 29/06/2010 22:32, Mark Thomas wrote:
> On 21/06/2010 15:16, John Wu wrote:
>>
>> Hi Mark,
>>
>> I just got a chance to test it on the Beta release. It's still broken,
>> with
>> a slightly different exception message.
>
> Confirmed. I'm pretty sure JSF is doing the right thing here and that I
> need to read the spec more carefully. I'll post an update when I have a
> fix.
It looks like we are going to have to go with your original proposal. I
was trying to avoid the complexity it adds but I can't see a way around it.
There is minor tweak to your suggested algorithm I intend making:
>>>> My suggestion as to the solution of resolving which method to call:
>>>> . Retrieve all methods of *theClassInstance*, and put them into the
>>>> CANDIDATES collection;
>>>>
>>>> // Search a match by method name
>>>> . For each method in CANDIDATES,
>>>> . if the name is not *theMethod*, remove it from CANDIDATES
>>>> . If CANDIDATES is empty, then NOT-FOUND;
>>>> . else if only one is left, then FOUND;
>>>>
>>>> // Search a match by params count
>>>> . else, count the number of actual params,
>>>> . For each method in CANDIDATES,
>>>> . if the number of formal params does not match that of actual params,
>>>> remove it from CANDIDATES
>>>> . // Optoional, handle cases of "method has variable number of
>>>> arguments"
>>>> . If CANDIDATES is empty, then NOT-FOUND;
>>>> . else if only one is left, then FOUND;
>>>>
>>>> // Search a match by param types
>>>> . else, evaluate all actual params;
>>>> . For each method in CANDIDATES,
>>>> . if NOT( for-each formalParamType.isAssignableFrom(actualParamType)
>>>> ),
>>>> remove it from CANDIDATES
>>>> . // Optoional, handle cases of "method has variable number of
>>>> arguments"
>>>> . If CANDIDATES is empty, then NOT-FOUND;
>>>> . else if only one is left, then FOUND;
else if exactly one CANDIDATE has more formal parameters that exactly
match the types of the actual parameters than all other CANDIDATES, then
FOUND;
>>>> . else, AMBIGUOUS
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: EL 2.2 in Tomcat 7 RC1/RC2 does not fully support method invocation,
such as "#{helloWorldController.doSomething(helloWorldModel)}"
Posted by Mark Thomas <ma...@apache.org>.
On 21/06/2010 15:16, John Wu wrote:
>
> Hi Mark,
>
> I just got a chance to test it on the Beta release. It's still broken, with
> a slightly different exception message.
Confirmed. I'm pretty sure JSF is doing the right thing here and that I
need to read the spec more carefully. I'll post an update when I have a fix.
Mark
>
> javax.faces.el.MethodNotFoundException: javax.el.MethodNotFoundException:
> /helloWorld.xhtml @15,85
> action="#{helloWorldController.doSomething(helloWorldModel)}": Method not
> found: org.wjh.experiment.jsf.HelloWorldController@c5122f.doSomething()
>
> The previous attached project is still valid as a test case.
>
> John Wu
>
>
> markt-2 wrote:
>>
>> On 10/06/2010 14:42, John Wu wrote:
>>>
>>> Hi Mark,
>>>
>>> The fix of "to derive the type directly from the value which ..." sounds
>>> not
>>> a solution. In a slightly more complex scenario, the fix still fails.
>>>
>>> Say the method signature is "public * theMethod(TheSupperType o)" and
>>> calling the method in EL like
>>> "#{theClassInstance.theMethod(theDerivedTypeInstance)}", where the supper
>>> type can be a supper class or an interface, your fix fails.
>>
>> super has one p, not two.
>>
>> I looked at the current code and the spec again. There is no need for
>> any of this complexity. The exact types are defined when the method
>> expression is created. I'm not sure why I was trying to derive them at
>> invocation time when they were already available.
>>
>> I have added a test case, modified the implementation and checked the
>> new code with the EL TCK and all looks to be OK.
>>
>> Mark
>>
>>>
>>> Example project attached.
>>>
>>> My suggestion as to the solution of resolving which method to call:
>>> . Retrieve all methods of *theClassInstance*, and put them into the
>>> CANDIDATES collection;
>>>
>>> // Search a match by method name
>>> . For each method in CANDIDATES,
>>> . if the name is not *theMethod*, remove it from CANDIDATES
>>> . If CANDIDATES is empty, then NOT-FOUND;
>>> . else if only one is left, then FOUND;
>>>
>>> // Search a match by params count
>>> . else, count the number of actual params,
>>> . For each method in CANDIDATES,
>>> . if the number of formal params does not match that of actual params,
>>> remove it from CANDIDATES
>>> . // Optoional, handle cases of "method has variable number of
>>> arguments"
>>> . If CANDIDATES is empty, then NOT-FOUND;
>>> . else if only one is left, then FOUND;
>>>
>>> // Search a match by param types
>>> . else, evaluate all actual params;
>>> . For each method in CANDIDATES,
>>> . if NOT( for-each formalParamType.isAssignableFrom(actualParamType)
>>> ),
>>> remove it from CANDIDATES
>>> . // Optoional, handle cases of "method has variable number of
>>> arguments"
>>> . If CANDIDATES is empty, then NOT-FOUND;
>>> . else if only one is left, then FOUND;
>>>
>>> . else, AMBIGUOUS
>>>
>>>
>>> John Wu
>>> http://old.nabble.com/file/p28843317/jsf-2.0-el-2.2.testcase-v2.zip
>>> jsf-2.0-el-2.2.testcase-v2.zip
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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: EL 2.2 in Tomcat 7 RC1/RC2 does not fully support method
invocation, such as "#{helloWorldController.doSomething(helloWorldModel)}"
Posted by John Wu <Jo...@gmail.com>.
Hi Mark,
I just got a chance to test it on the Beta release. It's still broken, with
a slightly different exception message.
javax.faces.el.MethodNotFoundException: javax.el.MethodNotFoundException:
/helloWorld.xhtml @15,85
action="#{helloWorldController.doSomething(helloWorldModel)}": Method not
found: org.wjh.experiment.jsf.HelloWorldController@c5122f.doSomething()
The previous attached project is still valid as a test case.
John Wu
markt-2 wrote:
>
> On 10/06/2010 14:42, John Wu wrote:
>>
>> Hi Mark,
>>
>> The fix of "to derive the type directly from the value which ..." sounds
>> not
>> a solution. In a slightly more complex scenario, the fix still fails.
>>
>> Say the method signature is "public * theMethod(TheSupperType o)" and
>> calling the method in EL like
>> "#{theClassInstance.theMethod(theDerivedTypeInstance)}", where the supper
>> type can be a supper class or an interface, your fix fails.
>
> super has one p, not two.
>
> I looked at the current code and the spec again. There is no need for
> any of this complexity. The exact types are defined when the method
> expression is created. I'm not sure why I was trying to derive them at
> invocation time when they were already available.
>
> I have added a test case, modified the implementation and checked the
> new code with the EL TCK and all looks to be OK.
>
> Mark
>
>>
>> Example project attached.
>>
>> My suggestion as to the solution of resolving which method to call:
>> . Retrieve all methods of *theClassInstance*, and put them into the
>> CANDIDATES collection;
>>
>> // Search a match by method name
>> . For each method in CANDIDATES,
>> . if the name is not *theMethod*, remove it from CANDIDATES
>> . If CANDIDATES is empty, then NOT-FOUND;
>> . else if only one is left, then FOUND;
>>
>> // Search a match by params count
>> . else, count the number of actual params,
>> . For each method in CANDIDATES,
>> . if the number of formal params does not match that of actual params,
>> remove it from CANDIDATES
>> . // Optoional, handle cases of "method has variable number of
>> arguments"
>> . If CANDIDATES is empty, then NOT-FOUND;
>> . else if only one is left, then FOUND;
>>
>> // Search a match by param types
>> . else, evaluate all actual params;
>> . For each method in CANDIDATES,
>> . if NOT( for-each formalParamType.isAssignableFrom(actualParamType)
>> ),
>> remove it from CANDIDATES
>> . // Optoional, handle cases of "method has variable number of
>> arguments"
>> . If CANDIDATES is empty, then NOT-FOUND;
>> . else if only one is left, then FOUND;
>>
>> . else, AMBIGUOUS
>>
>>
>> John Wu
>> http://old.nabble.com/file/p28843317/jsf-2.0-el-2.2.testcase-v2.zip
>> jsf-2.0-el-2.2.testcase-v2.zip
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
--
View this message in context: http://old.nabble.com/EL-2.2-in-Tomcat-7-RC1-RC2-does-not-fully-support-method-invocation%2C-such-as-%22-%7BhelloWorldController.doSomething%28helloWorldModel%29%7D%22-tp28671969p28948402.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: EL 2.2 in Tomcat 7 RC1/RC2 does not fully support method
invocation, such as "#{helloWorldController.doSomething(helloWorldModel)}"
Posted by John Wu <Jo...@gmail.com>.
That sounds even better. I'm looking forward to test the modified impl in the
next RC/release.
Mark Thomas wrote:
>
> On 10/06/2010 14:42, John Wu wrote:
>>
>> Hi Mark,
>>
>> The fix of "to derive the type directly from the value which ..." sounds
>> not
>> a solution. In a slightly more complex scenario, the fix still fails.
>>
>> Say the method signature is "public * theMethod(TheSupperType o)" and
>> calling the method in EL like
>> "#{theClassInstance.theMethod(theDerivedTypeInstance)}", where the supper
>> type can be a supper class or an interface, your fix fails.
>
> super has one p, not two.
>
> I looked at the current code and the spec again. There is no need for
> any of this complexity. The exact types are defined when the method
> expression is created. I'm not sure why I was trying to derive them at
> invocation time when they were already available.
>
> I have added a test case, modified the implementation and checked the
> new code with the EL TCK and all looks to be OK.
>
> Mark
>
>>
>> Example project attached.
>>
>> My suggestion as to the solution of resolving which method to call:
>> . Retrieve all methods of *theClassInstance*, and put them into the
>> CANDIDATES collection;
>>
>> // Search a match by method name
>> . For each method in CANDIDATES,
>> . if the name is not *theMethod*, remove it from CANDIDATES
>> . If CANDIDATES is empty, then NOT-FOUND;
>> . else if only one is left, then FOUND;
>>
>> // Search a match by params count
>> . else, count the number of actual params,
>> . For each method in CANDIDATES,
>> . if the number of formal params does not match that of actual params,
>> remove it from CANDIDATES
>> . // Optoional, handle cases of "method has variable number of
>> arguments"
>> . If CANDIDATES is empty, then NOT-FOUND;
>> . else if only one is left, then FOUND;
>>
>> // Search a match by param types
>> . else, evaluate all actual params;
>> . For each method in CANDIDATES,
>> . if NOT( for-each formalParamType.isAssignableFrom(actualParamType)
>> ),
>> remove it from CANDIDATES
>> . // Optoional, handle cases of "method has variable number of
>> arguments"
>> . If CANDIDATES is empty, then NOT-FOUND;
>> . else if only one is left, then FOUND;
>>
>> . else, AMBIGUOUS
>>
>>
>> John Wu
>> http://old.nabble.com/file/p28843317/jsf-2.0-el-2.2.testcase-v2.zip
>> jsf-2.0-el-2.2.testcase-v2.zip
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
--
View this message in context: http://old.nabble.com/EL-2.2-in-Tomcat-7-RC1-RC2-does-not-fully-support-method-invocation%2C-such-as-%22-%7BhelloWorldController.doSomething%28helloWorldModel%29%7D%22-tp28671969p28850494.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: EL 2.2 in Tomcat 7 RC1/RC2 does not fully support method invocation,
such as "#{helloWorldController.doSomething(helloWorldModel)}"
Posted by Mark Thomas <ma...@apache.org>.
On 10/06/2010 14:42, John Wu wrote:
>
> Hi Mark,
>
> The fix of "to derive the type directly from the value which ..." sounds not
> a solution. In a slightly more complex scenario, the fix still fails.
>
> Say the method signature is "public * theMethod(TheSupperType o)" and
> calling the method in EL like
> "#{theClassInstance.theMethod(theDerivedTypeInstance)}", where the supper
> type can be a supper class or an interface, your fix fails.
super has one p, not two.
I looked at the current code and the spec again. There is no need for
any of this complexity. The exact types are defined when the method
expression is created. I'm not sure why I was trying to derive them at
invocation time when they were already available.
I have added a test case, modified the implementation and checked the
new code with the EL TCK and all looks to be OK.
Mark
>
> Example project attached.
>
> My suggestion as to the solution of resolving which method to call:
> . Retrieve all methods of *theClassInstance*, and put them into the
> CANDIDATES collection;
>
> // Search a match by method name
> . For each method in CANDIDATES,
> . if the name is not *theMethod*, remove it from CANDIDATES
> . If CANDIDATES is empty, then NOT-FOUND;
> . else if only one is left, then FOUND;
>
> // Search a match by params count
> . else, count the number of actual params,
> . For each method in CANDIDATES,
> . if the number of formal params does not match that of actual params,
> remove it from CANDIDATES
> . // Optoional, handle cases of "method has variable number of arguments"
> . If CANDIDATES is empty, then NOT-FOUND;
> . else if only one is left, then FOUND;
>
> // Search a match by param types
> . else, evaluate all actual params;
> . For each method in CANDIDATES,
> . if NOT( for-each formalParamType.isAssignableFrom(actualParamType) ),
> remove it from CANDIDATES
> . // Optoional, handle cases of "method has variable number of arguments"
> . If CANDIDATES is empty, then NOT-FOUND;
> . else if only one is left, then FOUND;
>
> . else, AMBIGUOUS
>
>
> John Wu
> http://old.nabble.com/file/p28843317/jsf-2.0-el-2.2.testcase-v2.zip
> jsf-2.0-el-2.2.testcase-v2.zip
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org