Thanks, Mike. It does look like that's the only decent option. I'll
commit the change to the svn head.
On Fri, 11 Feb 2005 10:50:06 -0500, Mike Kienenberger
<[EMAIL PROTECTED]> wrote:
> Steve O'Hara <[EMAIL PROTECTED]> wrote:
> > 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.
>
> I've been doing the same thing with Velocity 1.3.1 and Struts 1.1 for more
> than a year, and I haven't had this problem.
>
> My logout vm file doesn't have any unresolvable references or references
> that would cause it to need to search the session or servlet context.
>
> Steve, my suggestion is also to clean up your template (either by removing
> those references from the template, or copying your servlet context
> attributes into your request attributes in your logout action), or fix the
> code in ChainedContext.getAttribute() to skip over invalidated sessions. I
> don't think there's a lot of benefit to creating a more convoluted
> workaround that still fails to read attributes from the servlet context when
> it's easy enough to fix the problem directly in Velocity Tools.
>
> Unfortunately, the morons who came up with the HttpSession interface didn't
> bother to provide an isInvalidated() method.
>
> I've been hit by this problem before when iterating through sessions, and
> the best you can do is this:
>
> try
>
> {
>
> o = session.getAttribute(key);
>
> }
>
> catch (IllegalStateException e)
>
> {
>
> // Handle invalidated session state
> // o = null; // only here to show how it's
> handled -- should already be
> null
>
> }
>
> Sorry, Nathan, but that's really the only option for dealing with
> invalidated sessions. You can at least localize the error trapping to the
> one line, though. [And that's the patch -- replace line 194 in
> org.apache.velocity.tools.view.context.ChainedContext.java,v 1.6 from
> VelTools 1.1 final]
>
> -Mike
>
>
> > -----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]
> >
>
> ---------------------------------------------------------------------
> 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]
