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]
