You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Bill <bh...@collaborativefusion.com> on 2002/11/11 17:30:20 UTC
LoginUser trouble with extended user
Has anyone ever had a problem using the stock LoginUser class after
extending TurbineUser?
The first conditional block in doPerform gets a non-null user and causes
LoginUser to return:
// This prevents a db hit on second Action call during page
// generation. Turbine removes everything from the Session
// before calling this method, so in this case we should
// continue on with the Login procedure.
if (data.getUserFromSession() != null)
{
return;
}
No matter what, that conditional always seems to be true even though I
have not successfully logged in with that block included in the class.
If I comment that block out I seem to login fine (I have not gone very
far in testing this but it does go to the correct page and I've
successfully pulled info from the resulting user object).
In the comment it mentions Turbine removing 'everything from the
Session' before it calls this method...what method is being referred to
here? Does this mean that Turbine removes everything from the Session
before running doPerform or getUserFromSession?
Obviously removing that block will add a performance burden if it
unnecessarily hits the db a second time, but does anyone know of any
other pitfalls that I might be opening up by removing it?
-b
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: LoginUser trouble with extended user
Posted by Mitch Christensen <mi...@informatixinc.com>.
I had this same problem (exactly) recently because the test in the Turbine
servlet (line #497 in 2.2b3) was failing becuase the value of
data.getAction() did not equal TurbineResources.getString("action.login").
For me, this was becuase I had subclassed LoginUser.java to do custom login
logic. My Login.vm set the action to "LocalLoginUser" and TRP.action.login
was set to "LoginUser". As such, the session wasn't cleaned prior to
calling LocalLoginUser.doPerform(). Changing TRP.action.login to
"LocalLoginUser" fixed the problem as the session was now cleaned out prior
to calling LoginUser.doPerform().
...though not directly applicable, maybe this info will help in some way.
-Mitch
-----Original Message-----
From: Bill [mailto:bhalpin@collaborativefusion.com]
Sent: Monday, November 11, 2002 8:30 AM
To: turbine-user
Subject: LoginUser trouble with extended user
Has anyone ever had a problem using the stock LoginUser class after
extending TurbineUser?
The first conditional block in doPerform gets a non-null user and causes
LoginUser to return:
// This prevents a db hit on second Action call during page
// generation. Turbine removes everything from the Session
// before calling this method, so in this case we should
// continue on with the Login procedure.
if (data.getUserFromSession() != null)
{
return;
}
No matter what, that conditional always seems to be true even though I
have not successfully logged in with that block included in the class.
If I comment that block out I seem to login fine (I have not gone very
far in testing this but it does go to the correct page and I've
successfully pulled info from the resulting user object).
In the comment it mentions Turbine removing 'everything from the
Session' before it calls this method...what method is being referred to
here? Does this mean that Turbine removes everything from the Session
before running doPerform or getUserFromSession?
Obviously removing that block will add a performance burden if it
unnecessarily hits the db a second time, but does anyone know of any
other pitfalls that I might be opening up by removing it?
-b
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>