Here's the execute() method of the Action...
String path = mapping.getPath();
ActionForward af = ActionHelpers.actionStart(cat, path, mapping, request);
if (af != null) { return af; }
HttpSession session = request.getSession();
String findReceiveDate = (String)request.getParameter("findReceiveDate");
String findAccountNumber = TOAHelpers.strTrim((String)request.getParameter("findAccountNumber"));
TOAFindAccountActionForm form = new TOAFindAccountActionForm();
Connection conn = DBConnectionManager.createConnection();
AccountFB acFB = new AccountFB(session, conn);
form.setFindReceiveDate(findReceiveDate);
form.setFindAccountNumber(findAccountNumber);
session.setAttribute("TOAFindAccountActionForm", form);
... More stuff follows. Just so you can follow along a bit, this app was converted from a non-Struts framework, so they took the past of least resistance and wound up not really using some Struts constructs properly. Here, they are creating a form and putting it in session because the app has a number of screens that need to be completed before a final submission page, at which point they grab all the forms from session and process them. The AccountFB is just a business delegate, that DBConnectionManager is a class that deals with everything database-related (it's actually not such a bad design when you get to know it... at least, things are nicely segregated and organized decently, which is more than I can say for many systems I've had the displeasure of dealing with).
Anyway, back to some semblence of an on-topic discussion... the exception is ocurring on that last line.
And here's the a ActionHelpers.actionStart() method...
HttpSession session = request.getSession();
if (!command.equalsIgnoreCase("/app/logon") && !command.equalsIgnoreCase("/app/changePassword")) {
if (session == null || session.getAttribute("sessionAlive") == null) {
request.setAttribute("message", "Your session timed out. Please log on again.");
session.invalidate();
return mapping.findForward("reload"); // Global forward
}
}
... Again, more stuff follows, but I think that's the pertinent piece. command is the path passed in, so they're just basically ignoring this check when logging on or changing the password, which is logical from the app's point of view. Note that as of this afternoon I added the suggested catch of IllegalStateException here, but I wind up executing the exact same code you see here in the IF block, minus the call to session.invalidate().
So, as I was pointing out before, by the time execution returns from actionStart(), I don't see a way there wouldn't be a valid session, and hence that getAttribute() call in the Action shouldn't generate an IllegalStateException (I could see getting one BEFORE that point, but if it gets that far, as near as I can tell, it shouldn't be possible).
Spot anything Brian? Thanks for your effort!
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
Barnett, Brian W. wrote:
Hmm. Can you share a bigger snippet of the code, and point out where the exception is being thrown? (the 20 lines after)
-----Original Message-----
From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Monday, November 08, 2004 4:23 PM
To: Struts Users Mailing List
Subject: Re: Session invalidation problem
Yep, I am aware of that. I in fact call it with just request.getSession(). I should have been clearer... at this point in my code, **based on what I do in the code prior to it**, I am guaranteed to have a session.
Barnett, Brian W. wrote:
You are not guaranteed to have a valid session at this point of your code. It depends on how you retrieved the session variable. If you called request.getSession() or request.getSession(true), then a session will be created for you if the request does not have a valid session. If you call request.getSession(false), a session will not be created. In this latter case, session will equal null.
-----Original Message-----
From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Monday, November 08, 2004 3:49 PM
To: Struts Users Mailing List
Subject: Re: Session invalidation problem
Another good point, and I'll add code to catch that. But, as I understand it, session would never be null (not at this point in the code anyway, which is inside an Action) because a session would have been established by now anyway.
Also, the exception wasn't in this section of code anyway, it actually happens about 20 lines after this. I'm going to take your suggestion anyway because I like adding checks that don't hurt anything, might save me a headache down the road, but I don't think this will address my initial problem.
Thanks Luiz!
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
