Sorry Frank, but I don't see anything. I suspect there is nothing happening to the session object down in the AccountFB constructor. You probably already checked that.
Since it is not an easy to duplicate bug, I'd probably scatter some debug print statements throughout that snippet of code that checks the state of the session variable and outputs it to the console. Then hammer away, or let users hammer away. Sometimes something like this isn't possible to do, though, esp., if it only happens on a production box. Let us know what the fix is if you are able to find it. Good luck. -----Original Message----- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Monday, November 08, 2004 4:40 PM To: Struts Users Mailing List Subject: Re: Session invalidation problem Can do... Remember, this is an inherited app, so don't kill me for things done here :) 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
