PS
In that case, forward to another JSP on that file userInfo information
should not be used.
(2012/06/15 9:10), Takanori Hayashi wrote:
Hello Anjib,
Assumed that you made the distinction on validate method,
then if forwarded JSP page is using userInfo session like
<logic:empty name="userInfo" property="firstName">
${userInfo.userName}
</logic:empty>
the same error is shown.
[Caused by: javax.servlet.jsp.JspException: Cannot find bean:
"userInfo" in any scope ]
Because you are using "not existing userInfo" at the JSP. The problem
is JSP using userInfo being there.
Takanori
(2012/06/14 22:29), Dave Newton wrote:
On Thu, Jun 14, 2012 at 9:18 AM, Anjib Mulepati<anji...@hotmail.com>
wrote:
I don't think problem is mapping correct page from Action class. If you
look into my initial code posting /changepassword need form
validation so
it calls the validate() method and since there is no data it fails.
I have
input="changePasswordPage" which takes to the tile where it look for
the
session variable.
My problem I don't a mechanism where if some one POST the empty data
validation fail must lead to not login message or invalid access
message.
How can I make such distinction from normal form submission?
You don't *need* to make that distinction, although you *may*.
You still have the same options as before:
1. A userInfo object in session, or
2. Don't read userInfo properties if it's *not* in session.
For (1), you *could* just keep a dummy/default "not-logged-in"
userInfo in
session, and replace it with a real on on login (and go back to the
dummy/default one on logout). This is sort-of a NullObject pattern
implementation, except that it represents a dummy/default user.
For (2), you can use conditional logic around property access.
Or just don't go to any pages that require a userInfo, likely by
redirecting to a login page on "protected" pages. That could be
handled by
a filter, a custom request processor, etc.
It seems like you're over-thinking this instead of just using any of the
suggestions already provided or coming up with something better--this
is a
straight-forward problem, with relatively straight-forward solution.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
