Details
-
Bug
-
Status: Closed
-
Minor
-
Resolution: Not A Problem
-
2.0.11
-
None
-
None
-
Tomcat5.5 winxp eclipse3.3 - struts2.11 with default interceptor stack, spring ioc and jdbc, dead simple crud system
Description
I had a major problem figuring out why I got this error:
ERROR http-8180-Processor25 com.opensymphony.xwork2.interceptor.ParametersInterceptor - ParametersInterceptor - [setParameters]: Unexpected Exception caught setting 'model.user.username' on 'class com.mycompany.actions.UserAction: Error setting expression 'model.user.username' with value '[Ljava.lang.String;@12dcb8c'
*slightly renamed vars/obj
The model, had these functions:
public User getUser()
public void setUser( User u )
{ this.user = u; }public boolean isUser()
{ return ( this.user == null ? false : true ); }In my jsp:
<s:textfield id="username" name="model.user.username" size="8" />
I have wasted alot of time on this stupid issue. How on earth does the expression confuse model.user.username with getModel().isUser()??? Once the isUser() was removed - everything worked like charm.
Struts is full of shitty undebuggable stufs like this, and retarded error msg. I have searched the net all over the place, struts guides, this jira, mailing lists - nothing.
- The guide needs an update on the matter of NOT POSSIBLE WHAT SO EVER to have a isXXX method.
- The error message should output what struts/ognl tried to evaluate the string as since it failed. "I failed, sry" doesn't quite help. It would be alot more helpful to see something like "the expression model.user.username was evaluated as getModel().isUser().." and I would maybe easier seen the problem.
- Add a tiny "if devmodus && foundMessySetGetIsCode() - then println "that isUser() function is maybe messing up stuffs??"
- Add a setting for dumping stacktraces - a line that says "exception occured" is so not helpfull.
- Also add functionality to type the method names completely or partially like name="getModel().getUser().setName()" or "model.getUser().name"
The expressions should only evaluate to set/get methods (unless the last one maybe) since there is alot of focus on that. I can't see any logic behind to go for an isXXX method.
Attachments
Issue Links
- is related to
-
WW-2723 Provide debug information about which methods where matched/invoked by OGNL
- Closed