You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Konstantin Kolinko <kn...@gmail.com> on 2010/05/25 21:26:05 UTC
Re: EL 2.2 in Tomcat 7 RC1/RC2 does not fully support method
invocation, such as "#{helloWorldController.doSomething(helloWorldModel)}"
2010/5/25 John Wu <Jo...@gmail.com>:
>
> I tried to use JSF 2.0 + Facelets (no JSP at all) in Tomcat 6 with EL 2.2
> (extracted from Tomcat 7 RC2), and failed.
You cannot cut some random part of Tomcat 7,
drop it into Tomcat 6 and expect it to work.
Regardless of what Tomcat 7 version you are using as a donor. You are
like a surgeon in some horror story.
Run Tomcat 7 as a whole and it should work.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
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 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 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
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,
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 26/05/2010 01:22, Mark Thomas wrote:
> On 25/05/2010 20:35, John Wu wrote:
>> Same failure observed on Tomcat 7 RC1 and RC2.
>
> I can now reproduce this. The fix is next on my todo list.
>
> Note I echo Konstantin's comments about trying to get EL 2.2 working in
> Tomcat 6. If it works, great - but it will be by luck rather than
> design. If it doesn't, it isn't going to get fixed. Tomact 6 supports EL
> 2.1. EL 2.2 support requires Tomcat 7.
I have fixed in this in trunk.
The old implementation used getType() to determine the types for each of
the parameters. This ultimately called:
org.apache.myfaces.el.unified.resolver.ScopedAttributeResolver.getType()
which is hard-coded to return java.lang.Object for all input. This
triggered the problem since the EL could not find a
doSomething(java.lang.Object) method. While this behaviour does seem a
little odd at first glance, I think it is correct since the JavaDoc says
for getType(ELContext, Object, Object):
<quote>
For a given base and property, attempts to identify the most general
type that is acceptable for an object to be passed as the value
parameter in a future call to the setValue(ELContext, Object, Object,
Object)66 method.
</quote>
In this case, scoped attributes can be of any class so returning Object
is correct.
I have modified Tomcat to derive the type directly from the value which
will always return the actual type. This fixes the provided test case
which now works as expected with Tomact 7 trunk.
Thanks for the test case. It made getting to the bottom of this a lot
easier.
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 25/05/2010 20:35, John Wu wrote:
> Same failure observed on Tomcat 7 RC1 and RC2.
I can now reproduce this. The fix is next on my todo list.
Note I echo Konstantin's comments about trying to get EL 2.2 working in
Tomcat 6. If it works, great - but it will be by luck rather than
design. If it doesn't, it isn't going to get fixed. Tomact 6 supports EL
2.1. EL 2.2 support requires Tomcat 7.
Mark
>
>
> Konstantin Kolinko wrote:
>>
>> 2010/5/25 John Wu <Jo...@gmail.com>:
>>>
>>> I tried to use JSF 2.0 + Facelets (no JSP at all) in Tomcat 6 with EL 2.2
>>> (extracted from Tomcat 7 RC2), and failed.
>>
>> You cannot cut some random part of Tomcat 7,
>> drop it into Tomcat 6 and expect it to work.
>>
>> Regardless of what Tomcat 7 version you are using as a donor. You are
>> like a surgeon in some horror story.
>>
>> Run Tomcat 7 as a whole and it should work.
>>
>> 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: 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>.
Same failure observed on Tomcat 7 RC1 and RC2.
Konstantin Kolinko wrote:
>
> 2010/5/25 John Wu <Jo...@gmail.com>:
>>
>> I tried to use JSF 2.0 + Facelets (no JSP at all) in Tomcat 6 with EL 2.2
>> (extracted from Tomcat 7 RC2), and failed.
>
> You cannot cut some random part of Tomcat 7,
> drop it into Tomcat 6 and expect it to work.
>
> Regardless of what Tomcat 7 version you are using as a donor. You are
> like a surgeon in some horror story.
>
> Run Tomcat 7 as a whole and it should work.
>
> Best regards,
> Konstantin Kolinko
>
> ---------------------------------------------------------------------
> 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-tp28671969p28672549.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