Hi Nate, I was invalidating the session when the user sends a logout request. It's a bit belt and braces but it insures that the session is destroyed and gets the user back to known state i.e. as though they were first visiting the site.
Steve -----Original Message----- From: Nathan Bubna [mailto:[EMAIL PROTECTED] Sent: 11 February 2005 01:18 To: [EMAIL PROTECTED] Cc: Velocity Users List Subject: Re: VelocityViewServlet Differences with VelocityServlet On Fri, 11 Feb 2005 01:09:10 -0000, Steve O'Hara <[EMAIL PROTECTED]> wrote: > Hi Nate, > > Thanks for your explanation, it makes sense, but it does raise a couple of > questions. > > a) It sounds as though the search for any Velocity variables that are not > defined in a template will cause this error i.e. #if ($blahblah). Surely > this is a problem in most apps where they are checking for the existence of > a variable? no. this is only a problem when a invalidated session object exists and Velocity is looking for an undefined variable (or one defined only in the servlet context attributes). most of the time in most apps, the session object either doesn't exist or is still valid. otherwise, this would have popped up long ago. :) > b) Your explanation points to a performance degradation over the original > VelocityServlet - is this, or could it be, significant? doubtful. when it comes to finding reference values, the only degradation in direct comparison to the VelocityServlet should be when looking for references that are undefined. if the app is designed ideally, this should rarely happen, and even when it does, the extra cost of looking up values further down the "chain" is quite negligible in comparison to the rest of what's happening during the processing of a servlet request and rendering of a template. > I've coded round the problem by only invalidating the session in the > requestCleanup method. so you're doing the session invalidation during the processing of the view? hmm. ok, if that works best for you, but just so you know, that's not very MVC. :) and out of curiousity, where were you doing that before? > Steve > > -----Original Message----- > From: Nathan Bubna [mailto:[EMAIL PROTECTED] > Sent: 10 February 2005 18:56 > To: [EMAIL PROTECTED] > Subject: Re: VelocityViewServlet Differences with VelocityServlet > > the quick answer to your question (re: differences between the > servlets) is that the VelocityViewServlet uses a chained context. the > ChainedContext looks for references in the toolbox, current (normal) > context, request attributes, session attributes, and servlet context > attributes. when looking for a reference in a template, it searches > those in that order until the matching key is found. > > so the problem is, that in the template being rendered at the end of > the request which is invalidating the session, there is a reference > within the block of an #if statement that is not being found in the > toolbox, normal context, or request attributes. so, the > ChainedContext being used by the VelocityViewServlet continues on to > check the session attributes for that reference. of course, it's > smart enough to make sure the session isn't null before trying that, > but it doesn't have a way to check if the session is valid or not. > so, it tries to find the reference in the session and triggers the > IllegalStateException. > > so, how to fix? the servlet API provides no way (that i can see) to > tell if a particular session object is valid or not (except perhaps > via HttpSessionActivationListener, but that's awkward in this > situation). so i guess the only real option is to catch the exception > if it happens. i'm not excited about that though. if anyone has a > better idea for a robust solution to this, that'd be great. > > in the immediate, however, i see only a few options for you: > > 1. extend ChainedContext and the VelocityViewServlet. in your > ChainedContext subclass, you'll want to override the getAttribute() > method to make it catch this exception. in your VelocityViewServlet > subclass, you'll want to override createContext() to use your new > ChainedContext subclass. > > 2. track down the reference(s) that are causing the problem and > remove them from your post-logout template. since you are probably > not putting things in the session or servlet context attributes > (judging by your question), i'm guessing those references in this > post-logout template are value-less and probably unnecessary. > removing them (or making sure they are available in a higher spot in > the "chain") will prevent the ChainedContext from searching down into > the session attributes and triggering the exception. > > 3. wait for this to get fixed (or fix it yourself) in the SVN > repository and using that code instead of one of the released > versions. > > best i can offer you at the moment. > > -nate > > On Thu, 10 Feb 2005 11:13:05 -0000, Steve O'Hara > <[EMAIL PROTECTED]> wrote: > > Hi Nathan, > > > > Here's the trace:- > > > > java.lang.IllegalStateException: getAttribute: Session already invalidated > > at > > > org.apache.catalina.session.StandardSession.getAttribute(StandardSession.jav > > a:900) > ... > > > org.apache.velocity.tools.view.context.ChainedContext.getAttribute(ChainedCo > > ntext.java:194) > ... > > > org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.jav > > a:220) > > at > > org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:55) > > at > > > org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement > > .java:70) > ... > > > org.apache.velocity.tools.view.servlet.VelocityViewServlet.mergeTemplate(Vel > > ocityViewServlet.java:592) > ... > > > > Steve > > > > -----Original Message----- > > From: Nathan Bubna [mailto:[EMAIL PROTECTED] > > Sent: 09 February 2005 17:14 > > To: Velocity Users List; [EMAIL PROTECTED] > > Subject: Re: VelocityViewServlet Differences with VelocityServlet > > > > hmm. i've not had problems with invalidated sessions before. can you > > give us some of that stack trace? i wanna see where this is > > happening. > > > > On Wed, 9 Feb 2005 11:11:38 -0000, Steve O'Hara > > <[EMAIL PROTECTED]> wrote: > > > > > > I've taken the advice offered by everyone to switch to using the > > > VelocityViewServlet but I've got a strange error occurring which didn't > > > happen with VelocityServlet (or if it did, it was caught). > > > > > > When I log out from my application I clear the session object by doing a > > > session().invalidate() > > > Now, when the template for the logout screen is merged by Velocity. I > get > > > the following error; > > > > > > java.lang.IllegalStateException: getAttribute: Session already > invalidated > > > > > > I can't understand this, I don't refer to the session object in my > > template > > > so why is the VelocityViewServlet checking the session object? Also, > why > > > doesn't it catch this error gracefully? > > > > > > Steve > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
