I did a quick walkthrough the Struts code and it *looks* like nothing in the code should create a session for a simple request. Manually setting the locale will do it, as will having beans in session-scope, and probably a few other places, but a simple request shouldn't.
I would suggest simply grabbing the source for the version your using a doing a global search for getSession(true) or getSession() and see if any of those calls will affect you. Alternatively, hook up a debugger and walk through it starting from ActionServlet.process() and see what you see. However, as another posted pointed out, accessing a JSP will create a session too, unless you specify that you do not want that. To do so, add: <%@ page language="java" session="false" %> ...to the top of the JSPs where you do not want a session created (like your login page for instance). See if that does the trick for you. I agree with others that there is probably a better way to deal with your core problem, but this might help you do what your trying to do none the less. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] On Wed, December 7, 2005 12:25 pm, James Harig said: > Hi Russ, > >>No, sorry if I was being vague. > > No problem. > >>I don't want Struts to create a session simply by accessing an action; I >> want to control >> the number of sessions being handed out. > > I don't believe that this is possible. The session creation happens at > the servlet container level(in your case Weblogic); and sessions(if they > dont exist), implicitly for each request. > >>A session is created by virtue of them just getting to the login page. > > Yes, this is true. > >>Weblogic is telling me that there are active sessions, even though I >>have invalidated the session once the user logs out. So I don't know if >>a person is still logged in, or if it is those extra sessions that are >>being handed out by Struts. > > It sounds like you need to implement the concept of "LoginSession", to > count the number of users that are logged in. > > > > > -----Original Message----- > From: Baker, Russ A [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 07, 2005 12:10 PM > To: Struts Users Mailing List > Subject: RE: Re: Session problem > > > No, sorry if I was being vague. I don't want Struts to create a session > simply by accessing an action; I want to control the number of sessions > being handed out. All of my pages are using Tiles, so to call for > instance the login page, which doesn't create a session; I have to call > an action so that the page is rendered using the Tiles framework. > > A session is created by virtue of them just getting to the login page. > If the user logs in successfully to the system they now have 2 sessions > instead the desired result having only one that is assigned to them when > they successful login. That is a waste of memory! > > So what I was getting at with the "I don't want to piss off the users by > shutting down the system while they are still on it..." was that > Weblogic is telling me that there are active sessions, even though I > have invalidated the session once the user logs out. So I don't know if > a person is still logged in, or if it is those extra sessions that are > being handed out by Struts. > > Capiche? > > -----Original Message----- > From: James Harig [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 07, 2005 9:53 AM > To: Struts Users Mailing List > Subject: RE: Re: Session problem > > Hi, > > Here's my take on the subject.... > > The key here is that you want the users to finish what they are doing > before you let the server shut down. This means a few things: > > 1. If the webapp uses the concept of logging in, new "login sessions" > shouldn't be allowed. Attempts to login should be responded to with > some sort of error: "The server is being shutdown..." > > 2. Existing sessions should be invalidated as soon as their next request > has been submitted, and the response should be redirected to an error > message "The server is being shutdown". For example, the when user > clicks: "check mail", a request is generated to the server(which calls a > Struts action); respond to this request by invalidating the session, and > redirecting to an error page. > > 2.a. There is an exception to this case: What if the user is in the > middle of a multi-step process. For example step 2 of the shopping cart > checkout process. In this case, you would want to postpone calling > session.invalidate() until after the checkout transaction is complete. > We will call these "multi-step transactions". > > To facilitate these items, you will need some method of informing your > webapplication that the server is going to be shutdown. One way to do > this would be to set a flag in the application context; another way is > to create a lock file; yet another way is to set a flag in a database. > > Once the webapp has been informed that the server is going to be > shutdown, wait until all the user sessions have been invalidated, and > shut it down. > > > I have thought about this subject on a number of occasions, but have > never implemented it. I would be glad to hear of any feedback. > > Thanks, > > James > > > -----Original Message----- > From: Ed Griebel [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 07, 2005 10:09 AM > To: Struts Users Mailing List > Subject: Re: Re: Session problem > > > The key is to not put anything in your session. Actions are the > obvious place to look for things being stuffed into the session (via > request.getSession().get/setAttribute()), but you might have a filter > that creates a session as part of what it does, or an action that has > a session-scoped form in struts-config.xml. > > If you want to only test for the existance of a session in your > action, don't forget to call request.getSession(false) and then check > the return for null. See the javadoc: > > http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/http/HttpSer > vletRequest.html#getSession(boolean) > > Also, if you have other webapps on the web server, they might be using > sessions in their webapps, so anything you do in yours will be for > naught. > > -ed > > On 12/6/05, Baker, Russ A <[EMAIL PROTECTED]> wrote: >> It is Weblogic. I am using a "graceful" shutdown so that if people > still >> have open sessions, they can complete what they are doing. The other >> alternative is to force shutdown, but I am afraid I will make enemies > if >> I do that... >> >> -----Original Message----- >> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Laurie Harper >> Sent: Tuesday, December 06, 2005 3:53 PM >> To: user@struts.apache.org >> Subject: Re: Session problem >> >> Baker, Russ A wrote: >> > Hello, >> > >> > I am trying to figure out how to stop Struts from creating a > session. >> > What seems to happen is that once I call an action, a session is >> > created. This is a problem because when I want to gracefully shut > down >> > my server, it complains that I still have an active session. Is > there >> a >> > way to configure Struts so that it does not create a session when an >> > action is called? >> >> A session is created the first time something accesses it. Since > Struts >> stores various things in session scope, I don't think you can avoid >> having one created. >> >> What container are you using? It seems like an odd behaviour to refuse >> to shut down if there are any active sessions... Are you sure it's >> referring to an HTTP session (as opposed, for example, to a Hibernate >> session or something)? >> >> L. >> >> >> --------------------------------------------------------------------- >> 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
