Paul Clapham wrote:I have no idea. You said that JSP includes a lot of other JSPs. Perhaps you are making an incorrect assumption about the order in which the compiled code will be executed. I don't know whether you are or not, and I don't really care to know anyway because I wouldn't write code where it mattered. And if I were brought in to fix that problem in your code I would just refactor it as per my earlier post.
Bear Bibeault wrote:Paul is spot on, it would be best to remove all this code from the JSP. In fact, in 2011, there should never be Java code of any kind in a JSP -- that's a poor practice that has been discredited for almost 10 years now.
Paul Clapham wrote:My theory was that the processing went in two steps:
(1) Invalidate the session
(2) Try to use data from the session
I'm pretty sure that both of these steps are in the code somewhere, and I'm pretty sure people have asked this already, but do you try to do (2) after (1)? Even after all these posts I can't figure out the answer to that question.
Bear Bibeault wrote:Why would the JVM not try to "do things" after a session invalidation?
Campbell Ritchie wrote:Class casts are nasty evil things. They are error-prone and should be avoided as much as possible.
I pointed it out because I have had so many myself
You need to decide what is being returned, and what you want.
How do you get eUser? Does its class implement the IMember interface? (By the way, it looks more like C# coding conventions than Java™, starting interface names with I.) What is the return type of the method you get eUser from? What methods are there in the IMember interface? Do you need any more methods?
Campbell Ritchie wrote:. . . with the complication that at Runtime, you may be mistaken about its being an IMember, in which case you see one of these
Jesper de Jong wrote: . . . The only thing that a cast does, is tell the compiler "look, I have this object here, and I want you to treat it as if it is of type IMember". . . .