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: <mailto:turbine-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:turbine-user-help@;jakarta.apache.org> -- To unsubscribe, e-mail: <mailto:turbine-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:turbine-user-help@;jakarta.apache.org>
