What we are doing is (not very efficient, but easy and quick to program), we have a class that gets the session and path as parameter. Then this class checks to see what attributes are absolutely required for a path and it removes the rest. We are then calling this class from the processPreprocess hook of ActionServlet. So now by default this class is called for each request and thus session gets cleaned up (at the cost of a little extra processing).
-----Original Message----- From: Joe Barefoot [mailto:[EMAIL PROTECTED] Sent: Friday, March 07, 2003 2:44 PM To: Struts Users Mailing List Subject: RE: How do you keep your session junk free? Interesting. We are less concerned about work flow that being able to create wizards using session objects, and have them cleaned up in a timely fashion. I think it's nice to be able to manage extra parameters via the actionMapping as you are doing, but to be honest managing everything via request objects in workflows/wizards is a real pain in the ass, I've found. I would much rather be able to store things on the session from actions and have them reliably cleaned up in some fashion, hence the 1-per-session notions I cooked up. The reason you have to have the member Hashtable: The WizardBag (or whatever you call it) needs to have the wizard's logical name stored as a field. One would use a separate, static name as the key to store the bag on the session ("WizardBag", or whatever). That way you only have one wizard object as opposed to many session objects on the session. If you just use the session, it is impossible to know what objects have been placed there by sub-classes, and defeats the purpose of automatic session management for a 1-per-session wizard. This way, you only look up the WizardBag object, check it's logical name, yada-yada, and keep, delete, or create it depending on your actionmapping's parameter value. Sub-classes would use inherited methods to store objects in the WizardBag's Hashtable and retrieve them. Using this or a similar framework, it would be fairly easy to store session objects in a 1-wizard-allowed-per-session model and expect those objects to be cleaned up. I haven't been able to come up with anything else. peace, Joe > -----Original Message----- > From: Sloan Seaman [mailto:[EMAIL PROTECTED] > Sent: Friday, March 07, 2003 12:07 PM > To: Struts Users Mailing List > Subject: Re: How do you keep your session junk free? > > > The 1-per-session stuff, you might as well just use the > session object to do > the storage otherwise you are just adding overhead by putting > a Hashtable > into a Hashtable just to do get/put. I name all my variable > that go into my > session object com.symbol.mobilecommerce.so on to make sure I > don't clobber > anything else. > > You could also do the storage based on something like > javax.xml.namespace.QName to be real unique... > > The extension idea is not bad. But defining by number can be > a pain. If > you have 50 steps (1-50) and you have to insert a new one a > 2, then you have > to renumber the rest. I'd come up with some sort of linked > list if I were > you. > > I've got an open source business rules engine that I wrote > that someone is > supposed to be making into a work flow manager for struts... > that may be > good as well.... I'll have to see how far it has come along.... > > I don't have anything for session mgmt as of yet myself but > it has crossed > my mind that it could be an issue. > > One of the things my ChainAction inherits from a HelperAction > I have is the > ability to do a <set-property property="REMOVE_BEAN" value="bean/form > name"/> > That helps in keeping things out of the action that may be coming in. > > Another thing I do to make it more flexible is that I wrote a > class that > extends HttpServletRequestWrapper that allows me to put my > own parameters in > so that the request object going to the action actually has parameters > inserted in from my ActionChain. > > This way the action being chained to can act like it was just taking a > normal http request when in fact the ChainAction may be > inserting things (as > directed from the struts-config) to help it out. > > Works rather nicely and I have had no session related issues > as of yet. > > I have been thinking about implementing something that would > do session > storage based on where you are in a "package" and would make > the session > variables accessible only if you were in that package. Think > private/protected variables like in Java... > > Now I'm working on a generic action that will use different > forwarders based > on the calling action. > > This is because right now I have an ADD and an EDIT action path in my > struts-config.xml because if something fails it has to climb > back the chain > properly for the user. > > With the new class I am writing if going to an EDIT action fails (say > because the db bean didn't exist) it flips over to the ADD. > Then, when the > user clicks the Next it flips back to the EDIT path, and if that edit > doesn't work, flips to ADD, and so on. > > Lets the user go down an application path in a nice failover manner... > Anyway.. that was off topic... but I figured it might be of > interest to > someone... > -- > Sloan > > > ----- Original Message ----- > From: "Joe Barefoot" <[EMAIL PROTECTED]> > To: "Struts Users Mailing List" <[EMAIL PROTECTED]> > Sent: Friday, March 07, 2003 2:00 PM > Subject: RE: How do you keep your session junk free? > > > Does this model include a means of managing the session > objects (I would > assume yes, but didn't see anything to that effect)? That is the real > problem with wizards or wizard-like control flows. > > I had cooked up a similar idea, but haven't implemented it > yet, because all > the wizards already had been built here using hidden fields > to pass along > values before I started. I'll prolly test it out if we have > another wizard > come along. > > In the idea outlined below, I'm using the single "parameter" > attribute, but > you could use the "set-property" attribs as well I guess...do > these only > exist in Struts 1.1? Note that the part at the bottom, > "Extension", is > something that I would definitely do...I just haven't > reformated these notes > yet. > > In a nutshell: > > > Notes for a 1-per-session wizard framework: > 1. Use a single "wizard bag" in session, just an object that > contains a > hashtable plus identifying logical name for the wizard for > which we are > storing objects. > 2. Use the "parameter" attribute in action mapping to give > logical name of > wizard that this action is a part of, if it is a wizard > action. Action > classes that are used both in and out of wizards should have multiple > mappings-a mapping with a wizard parameter should be used > only inside a > wizard flow. > 3. In abstract action superclass, test to see if > actionmapping's parameter > has a value. > 4. If parameter has no value, remove the wizard bag from the > session if it > exists, as we are no longer in a wizard. > 5. If parameter has a value: If no wizard bag exists in > session, create one > with the parameter's value as the logical name. If the > wizard bag does > exist in the session, see if it's logical name matches the parameter > value-if it doesn't, remove the wizard bag and create a new > one with the > current parameter value, as we have jumped to a new wizard. > 6. Our abstract superclass will have protected methods to > access the wizard > bag, for use by wizard subclasses: > storeWizardObject(String key, Object o); > getWizardObject(String key); > removeWizardObject(String key); > > Extension: > Use a naming scheme for the parameter values in our wizard > actionmappings: > wizardName_step#. For example: createEmployee_1, > createEmployee_2, etc. > We would use the same rules as above, except we would always > create a new > wizard bag in step one of the wizard (and drop the current > one even if it > already exists). We would also verify that the wizard bag > with our current > wizard's logical name already exists in subsequent steps, and > if it doesn't, > forward to an exception page (because this means we either > lost the wizard > bag in the middle of the process due to another client > browser's request (in > the same session), or we jumped into the middle of the wizard > somehow - see > #2 above). Having the step number may be useful for other > purposes as well. > > > > --joe > > > -----Original Message----- > > From: Sloan Seaman [mailto:[EMAIL PROTECTED] > > Sent: Friday, March 07, 2003 8:33 AM > > To: Struts Users Mailing List > > Subject: Re: How do you keep your session junk free? > > > > > > I kinda have a class that does that if you want. > > > > I have an Action called ChainAction that can call N number of > > actions in a > > row and passes the same form and request info through all > the actions. > > > > The last action in the chain is then used to do a foward to > whatever. > > > > This is how I control all application flow via the > struts-config file. > > > > Example: > > <action > > path="/app/campaign/promotion/type/pantryLoading/introAddChain" > > > > className="com.symbol.mobilecommerce.analysis.struts.ChainActi > > onMapping" > > type="com.symbol.mobilecommerce.analysis.struts.ChainAction" > > name="pantryLoadingIntro" > > > > > <set-property property="ROLE" value="admin"/> > > <set-property property="PROPERTY_NAME" value="action"/> > > <set-property property="CHAIN" value="Do Delete : > > /app/campaign/promotion/type/pantryLoading/introSaveMessageAdd, > > /app/campaign/promotion/type/pantryLoading/deleteBitmapAdd, > > /app/campaign/promotion/type/pantryLoading/introAddPage"/> > > <set-property property="CHAIN" value="Add Bitmap : > > /app/campaign/promotion/type/pantryLoading/introSaveMessageAdd, > > /app/campaign/promotion/type/pantryLoading/addBitmapAdd, > > /app/campaign/promotion/type/pantryLoading/introEditPage"/> > > <set-property property="CHAIN" value="Next: > > /app/campaign/promotion/type/pantryLoading/introSaveMessageAdd, > > /app/campaign/promotion/type/pantryLoading/messageTypeAddChain"/> > > <forward name="PAGE_CHAIN_ERROR" > > path="/app/campaign/promotion/type/pantryLoading/introAddPage.do"/> > > <forward name="PAGE_ACCESS_DENIED" > > path="/app/campaign/promotion/mainPage.do"/> > > </action> > > > > This action does security first (we have a custom system that > > does role > > based security down to the action level). If the user does > > not have access > > it send them up the chain one step. They continue up the > > chain till they > > hit a point where they do have access. This way we get them > > to ass deep as > > they can go (get your mind out of the gutter). Anway.. > > > > The chains work by defining a PROPERTY_NAME that relates to > > an any element > > in a form. In this case, submit buttons. If the user > > clicked "Do Delete" > > it sends them to introSaveMessageAdd and then to > > deleteBitmap, and then to > > the introAddPage. > > > > This way my actions a very modular. > > > > You can also do a DECHAIN which will run through the actions > > like normal but > > the last one is treated as a seperate request and gets a > new form and > > request object (good for going from one form to another and > > not having bean > > issues). > > > > It also does other things like you can defined a message to > > put into the > > session at the end of the chain, etc... > > > > Anyway.. I can see if I can release the code if you want. > > > > ----- Original Message ----- > > From: "julian green" <[EMAIL PROTECTED]> > > To: "Struts Users Mailing List" <[EMAIL PROTECTED]> > > Sent: Friday, March 07, 2003 11:04 AM > > Subject: Re: How do you keep your session junk free? > > > > > > > It would be neat if you could group a bunch of action definitions > > > together and have the form bean persist while the group > > remianed active. > > > > > > Julian > > > > > > David Graham wrote: > > > > > > > >> Explain how some other approach handles it in any better > > way? Use of > > > >> token to prevent duplicate submissions works for me. And > > what do you > > > >> mean by a continuation-style programming? > > > >> > > > > The token approach is an easy solution. One of the sites > > listed was a > > > > Smalltalk web framework. It's good to look at things in > > different ways > > > > but you could probably count the number of Smalltalk web > > applications on > > > > one hand :-). > > > > > > > > David > > > > > > > > > > > > > _________________________________________________________________ > > > > Help STOP SPAM with the new MSN 8 and get 2 months FREE* > > > > http://join.msn.com/?page=features/junkmail > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > 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]
